Hardening Qubes OS?

sadja · July 7, 2021, 10:21am

I was wondering whether anyone has any tips on how to further ‘harden’ Qubes OS. I am currently running all my sys-* as disposable vm’s. These sys* vm’s are all based on fedora-33-minimal. I also use 1 appvm/standalone per program. Any further tips would be appreciated!

fiftyfourthparallel · July 7, 2021, 11:22am

I think beyond Qubes-specific measures, like using sys-disps, using minimal VMs, restarting VMs frequently, segregating VMs with different trust levels, and updating, everything else is plain Linux hardening (assuming a pure-Linux system).

I wouldn’t mind seeing a Qubes-centered Linux hardening guide here and don’t think it should be considered an ‘All around Qubes’ topic since Linux is so core to the overall system. Maybe start with a ‘tips and tricks’ thread that can then be compiled into a guide.

^{^{Not technically trained; consume advice with salt.}}

fsflover · July 7, 2021, 1:39pm

A few interesting hardening tips here: "Now You're Thinking with Qubes".

Using different operating systems may also improve your security through isolation (depending on your threat model). Qubes provides quite a few different OSs: Documentation | Qubes OS and minimal templates: Documentation | Qubes OS.

Use OpenBSD as NetVM

opened 12:29PM - 04 Sep 19 UTC

tetrahedras

T: enhancement C: other security P: default

**The problem you're addressing (if any)** The NetVM is exposed to a wide varie…ty of attacks, and it's the first line of defense in hostile local network environments. (e.g there is evidence certain Middle Eastern countries have been building infrastructure to automatically attempt exploiting every device connected to public WLAN networks) There is demand (see #4551) for running OpenBSD as a VM but efforts are stalled due to OpenBSD's lack of PV support. Since the NetVM is run in HVM mode, PV support is not necessary in this application. **Describe the solution you'd like** OpenBSD offers well-reviewed driver code, high code quality, innovative exploit mitigations, excellent hardware support, low resource consumption, and a much smaller attack surface than Linux. OpenBSD also offers a [much simpler](https://www.openbsd.org/faq/faq6.html#Wireless) approach to connecting to wireless networks than does Linux. **Where is the value to a user, and who might that user be?** Adding it as a NetVM would likely increase resistance to attackers on the local network, and increase the diversity of the system (from the current-best MirageFW+Linux to OpenBSD+MirageFW+Linux). **Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues** https://github.com/QubesOS/qubes-issues/issues/4551

github.com/QubesOS/qubes-issues

domU hardening

opened 08:13PM - 21 Aug 18 UTC

DemiMarie

T: enhancement C: core security P: default

### Qubes OS version:  R4.0 ### Affected component(s): domU kernel and userland --- ### Steps to reproduce the behavior:  Note that Qubes VMs run with SELinux disabled, and without any major measures to protect the kernel. ### Expected behavior: Qubes VMs are hardened by various measures. These might include, but are not limited to: - blocking historically vulnerable system calls (such as `ptrace(2)`, `perf_event_open(2)`, and `modify_ldt(2)` with seccomp - using SELinux to disable ioctls and socket options that are almost never needed in practice - using a hardened kernel - strict kernel module signing (no loading of unsigned modules) - deny user-mode programs, even ones running as `root`, access to kernel memory ### Actual behavior: No such hardening ### General notes: Like #4232, this is another case of defense in depth. We should aim to make life as hard for an attacker as possible. Most Xen vulnerabilities need kernel privilege to exploit. --- ### Related issues: #4232

deeplow · July 8, 2021, 4:33pm

tip: use the in-forum search Search results for 'harden' - Qubes OS Forum