From c989b8bd4ac8be5c64838bdf42ab2473e40436ee Mon Sep 17 00:00:00 2001 From: Christopher Laprise Date: Tue, 29 Jan 2019 23:09:53 -0500 Subject: [PATCH] fix install copying to subdir --- README.md | 23 +++++++++++++++++++---- install | 2 ++ 2 files changed, 21 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 7590734..34b5b73 100644 --- a/README.md +++ b/README.md @@ -39,7 +39,7 @@ Leverage Qubes template non-persistence to fend off malware at VM startup: Lock- Operation is automatic and will result in either a normal boot process with full access to the private volume at /rw, or a rescue service mode providing an xterm shell and the private volume quarantined at /dev/badxvdb. - At the `vm-boot-protect` level, certain executable files in /home will be made immutable so PATH and `alias` cannot be used to hijack commands like `su` and `sudo`, nor can impostor apps autostart whenever a VM starts. This prevents normal-privilege attacks from gaining persistence at startup. + At the `vm-boot-protect` level, certain executable files in /home will be made immutable so PATH and `alias` cannot be used to hijack commands like `su` and `sudo`, nor can impostor apps autostart whenever a VM starts. This can be added to virtually any Debian or Fedora VM and prevents unprivileged attacks from gaining persistence at startup. At the `vm-boot-protect-root` level, the $privdirs paths will be renamed as backups, effectively removing them from the VM startup. Then whitelisting, hash/checksumming and deployment are done (if configured). This protects VM startup from attacks that had previously achieved privilege escalation. @@ -54,7 +54,21 @@ Leverage Qubes template non-persistence to fend off malware at VM startup: Lock- **Whitelists** are checked in ../vms/vms.all.whitelist and ../vms/$vmname.whitelist files, and file paths contained in them must start with `/rw/`. A default is provided in ..vms/sys-net.whitelist to preserve Network Manager connections and sleep module list in sys-net. - **Deployment** files are copied _recursively_ from ../vms/vms.all/rw/ and ../vms/$vmname/rw/ dirs. Example is to place the .bashrc file in /etc/default/vms/vms.all/rw/home/user/.bashrc for deployment to /rw/home/user/.bashrc. + **Deployment** files are copied _recursively_ from ../vms/vms.all/rw/ and ../vms/$vmname/rw/ dirs. Example is to place the .bashrc file in /etc/default/vms/vms.all/rw/home/user/.bashrc for deployment to /rw/home/user/.bashrc. Once copying is complete, +the /etc/defaults/vms folder is deleted from the running VM (this has no effect on the original in the template). + +### Where to use: Basic examples + +After installing into a template, simply enable `vm-boot-protect-root` service without configuration. Recommended for the following types of VMs: + o Service VMs: sys-usb and sys-net. + o App VMs: untrusted, personal, banking, vault, etc. This assumes using regular Linux apps without tailored Qubes-specific settings in /rw such as *Firefox, Chromium, Thunderbird, KeePassX, office apps, media playback & editing*, etc. For these and many more, no configuration should be necessary. + +Examples where `vm-boot-protect-root` requires configuration: sys-vpn (see Notes), Martus and Whonix (needs testing). Note that VMs sys-vpn and sys-firewall are fairly low-risk VMs so there may not be a compelling reason to use the service with them. + +Examples where -root should *not* be enabled: + o DispVMs. Sensible option is to enable sudo security for DispVM templates; service can be installed into template and left unused. + o Standalone VMs. Plain `vm-boot-protect` makes more sense for these. + o Non-Linux VMs (currently unsupported for any mode) ### Scope and Limitations @@ -73,13 +87,14 @@ Leverage Qubes template non-persistence to fend off malware at VM startup: Lock- * Adding /home or subdirs of it to $privdirs is possible. This would quarantine everything there to set the stage for applying whitelists on /home contents. The $privdirs variable can be changed via the service file, for example adding a .conf file in /lib/systemd/system/vm-boot-protect.d. - * The sys-net VM should work 'out of the box' with the vm-boot-protect-root service via the included whitelist file. + * The sys-net VM should work 'out of the box' with the vm-boot-protect-root service via the included whitelist file. Additional network VMs may require configuration, such as `cp sys-net.whitelist sys-net2.whitelist`. * Using the -root service with a [VPN VM](https://github.com/tasket/Qubes-vpn-support) requires manual configuration in the template and can be approached different ways: Whitelist (optionally with SHA) can be made for the appropriate files. Alternately, all VPN configs can be added under /etc/default/vms/vmname/rw so they'll be automatically deployed. * Currently the service cannot seamlessly handle 'first boot' when the private volume must be initialized. If you enabled the service on a VM before its first startup, on first start the shell will display a notice telling you to restart the VM. Subsequent starts will proceed normally. - + ## Releases + - v0.8.3 Fix for install script copying to /etc/default/vms - v0.8.2 Working rescue shell. Add sys-net whitelist, sudo config, fixes. - v0.8.0 Adds protection to /rw, file SHA checksums, whitelists, deployment - v0.2.0 Protects /home/user files and dirs diff --git a/install b/install index f5930ac..cacec2b 100644 --- a/install +++ b/install @@ -1,5 +1,6 @@ #!/bin/bash # From https://github.com/tasket/Qubes-VM-hardening +# installer version 0.8.3 set -e [ `id -u` -eq 0 ] || exit @@ -15,6 +16,7 @@ systemctl daemon-reload systemctl enable vm-boot-protect.service echo "Adding defaults in /etc/default/vms..." +mkdir -p /etc/default/vms # Careful... ownership & mode are not preserved here! cp -riv default/vms/* /etc/default/vms