Git-Mirrors/Qubes-VM-hardening
1
0
Fork 0
mirror of https://github.com/tasket/Qubes-VM-hardening.git synced 2024-10-01 06:35:42 -04:00
Code Issues Packages Projects Releases Wiki Activity

Readme updates pending...

Browse Source
This commit is contained in:
Christopher Laprise 2018-04-02 10:38:47 -04:00
parent 7bd9667c08
commit 15f6570028
No known key found for this signature in database
GPG Key ID: 448568C8B281C952
1 changed files with 13 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
README.md
View File

@ -1,21 +1,21 @@
# Qubes-VM-hardening
## *README under construction*
Fend off malware at VM startup: Lock-down and remove scripts in /rw private storage that affect the execution environment.
Fend off malware at VM startup: Lock-down and remove scripts in /rw private storage that affect the execution environment.
Leverage Qubes template non-persistence to enhance the guest operating system's own defenses.
## vm-boot-protect.service
* Protect /home (user) executable files as immutable
* Deactivate /rw (root) executables
* Whitelisting for specifying persistent files
* Quarrantine /rw (root) configs & scripts, with Whitelisting
* SHA256 checksumming guards against unwanted changes
* Deploy custom defaut files
* Re-deploy custom 'default' files to /rw on each boot
* Runs at VM start before /rw mounts
* Provides rescue shell with non-persistent /home
## Installing
1. In a template VM, install the two service files
1. In a template VM, install the service files
```
cd Qubes-VM-hardening
sudo sh ./install
@ -25,7 +25,7 @@ Fend off malware at VM startup: Lock-down and remove scripts in /rw private stor
- `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 **removes** dirs specified in $privdirs; Default is /rw/config, /rw/usrlocal and /rw/bind-dirs.
CAUTION: The root option **removes** dirs /rw/config, /rw/usrlocal and /rw/bind-dirs.
3. Disabling the Qubes default passwordless-root is necessary for the above measures to work effectively. Here are two recommended ways (choose one):
- [Enabling auth prompt for sudo](https://www.qubes-os.org/doc/vm-sudo/#replacing-password-less-root-access-with-dom0-user-prompt) configures a simple yes/no prompt that appears in dom0.
@ -37,26 +37,26 @@ Fend off malware at VM startup: Lock-down and remove scripts in /rw private stor
Operation is automatic, although particular configuration options such as hash checks are possible.
At the basic 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 prevents normal-privilege 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.
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.
### Configuration
Add files to /etc/default/vms in the template to enable the following features...
Files can be added to /etc/default/vms in the template to enable the following features...
**Hashes/Checksums** are checked in ../vms/vms.all.SHA and ../vms/$vmname.SHA files. File paths contained in them must be absolute. See 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/`.
**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
**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 .
### Limitations
The `vm-boot-protect` concept relies mostly on the guest operating system's own defenses, with one added advantage of root volume non-persistence provided by the Qubes template system. This means that attacks which damage/exploit the private filesystem itself or quickly re-exploit network vulnerabilities could conceivably still persist at startup. Otherwise, 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 malware has not escalated to root (admittedly, a big 'if').
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').
Repeated running of some apps such as Firefox, Chrome, LibreOffice, PDF viewers, online games, etc. may allow malware to persist in a VM; this is not only because of the complexity of the formats handled by such apps, but also because of settings contained in javascript or which specify shell commands to be executed by the app.
Conversely, attacks which damage/exploit the private filesystem itself or quickly re-exploit network vulnerabilities could conceivably still persist at startup. Repeated running of some apps such as Firefox, Chrome, LibreOffice, PDF viewers, online games, etc. may allow malware to persist in a VM; this is not only because of the complexity of the formats handled by such apps, but also because of settings contained in javascript or which specify commands to be executed by the app. Therefore, setting apps to autostart can diminish protection of the startup environment.
### Notes
@ -71,6 +71,3 @@ Repeated running of some apps such as Firefox, Chrome, LibreOffice, PDF viewers,
- v0.2.0 Protects /home/user files and dirs
## See also:
[AppArmor Profiles](https://github.com/tasket/AppArmor-Profiles)