Home

Awesome

Qubes VM hardening

Leverage Qubes template non-persistence to fend off malware at VM startup: Lock-down, quarantine and check contents of /rw private storage that affect the execution environment.

vm-boot-protect.service

Installing

1. In dom0, enter the following commands to enable `sudo` prompts:

    sudo su -
    echo "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
    chmod +x /etc/qubes-rpc/qubes.VMAuth
    echo "@anyvm dom0 ask,default_target=dom0" >/etc/qubes-rpc/policy/qubes.VMAuth

2. In a template VM, install and configure

    cd Qubes-VM-hardening
    sudo bash install
    sudo bash configure-sudo-prompt

As an alternative, you can skip _'configure-sudo-prompt'_ and Step 1 and instead uninstall the `qubes-core-agent-passwordless-root` package from the template. After doing this, you will have to use `qvm-run -u root` from dom0 to run any VM commands as root.

3. Activate by specifying one of the following Qubes services for your VM(s)...
   - `vm-boot-protect` - Protects executables/scripts within /home/user and may be used with wide array of Qubes VMs including standalone, appVMs, netVMs, Whonix, etc.
   - `vm-boot-protect-root` -  Protects /home/user as above, automatic /rw executable deactivation, whitelisting, checksumming, deployment. Works with appVMs, netVMs, etc. that are _template-based_.

CAUTION: The -root option by default removes prior copies of /rw/config, /rw/usrlocal and /rw/bind-dirs. This can delete data!

Usage

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 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.

The special vm-boot-protect-cli level unconditionally runs an xterm rescue shell.

Configuration

Files can be added to /etc/default/vms in the template to configure the following vm-boot-protect-root features...

Hashes/Checksums are checked in ../vms/vms.all.SHA and ../vms/$vmname.SHA files. File paths contained in them must be absolute, and references to '/home' must be prefixed with '/rw/'. Hashes in $vmname.SHA will override hashes specified for the same paths in vms.all.SHA. See also man page for sha256sum -c.

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. 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).

rc files are sh script fragments sourced from ../vms/vms.all.rc and ../vms/$vmname.rc. They run near the beginning of the vm-boot-protect service before mounting /rw, and can be used to override variable definitions like privdirs as well as the vm_boot_finish function which runs near the end before dismount. Another use for rc files is to run threat detection tools such as antivirus.

Tags: Any of the above configs may be defined as tags so that you are not limited to specifying them for either all VMs or specifically-named VMs. Simply configure them as you would acccording to the above directions, but place the files under the '@tags' subdir instead. For example '/etc/default/vms/@tags/special.whitelist' defines a whitelist for the tag 'special'. A tag can be activated for one or more VMs by adding a Qubes service prefixed with vm-boot-tag- (i.e. vm-boot-tag-special) to the VMs. Also, multiple tags may be activated for a VM.

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:

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:

Example tags

Some useful configurations have been supplied in /etc/default/vms:

Scope and Limitations

The vm-boot-protect concept enhances the guest operating system's own defenses by using the root volume non-persistence provided by the Qubes template system; thus a relatively pristine startup state may be achieved if the private volume is brought online in a controlled manner. Protecting the init/autostart files should result in Qubes template-based VMs that boot 'cleanly' with much less chance of being affected by malware initially. Even if malware persists in a VM, it should be possible to run other apps and terminals without interference if the malware has not escalated to root (admittedly, a big 'if').

Conversely, attacks which damage/exploit the Ext4 private filesystem itself or quickly re-exploit network vulnerabilities could conceivably still persist at startup. Further, repeated running of complex apps, games, and programming environments may reactivate malware; this is because of the complexity of the formats and settings handled by such apps. Therefore, setting apps to autostart can diminish protection of the startup environment.

Note that as system and app vulnerabilities are patched via system updates, malware that used those vulns to gain entry may cease to function without the kind of loopholes that vm-boot-protect closes.

Efficient template re-use is another aspect of using vm-boot-protect-root features, since a single template can be customized for various roles. However, note that some customizations may not be appropriate to run during VM startup.

Notes

Links

Releases