Mount /rw and /home with nosuid + nodev

[tasket]

The problem you're addressing (if any) When a template has been configured to enforce internal user permissions, malware that gains a temporarily useful privilege escalation may continue as root user indefinitely in AppVMs by setting up executables in /home that have +s SUID bit set. The effect is that an OS patch for the initial vulnerability will not de-privilege malware that exploited it.

Similarly, the ability to create device node files in /home can permit privilege escalation, and such nodes normally don't belong in /home.

Describe the solution you'd like Change the /rw and /home entries in /etc/fstab to use the nosuid and nodev options. This works even with bind mounts.

Where is the value to a user, and who might that user be? Users who do not want malware to persist indefinitely or easily gain root privileges may remove the 'qubes-core-agent-passwordless-root' package, or reconfigure templates according to the 'vm-sudo' doc or Qubes-VM-hardening.

Mounting /rw and /home with nosuid + nodev bolsters security in such template configurations by giving OS security patches a chance to de-privilege malware.

Relevant documentation you've consulted https://www.qubes-os.org/doc/vm-sudo/ https://github.com/tasket/Qubes-VM-hardening

[tasket]

Updated description to include nodev along with nosuid, as the risks (and solution) are similar.

[tasket]

Also want to point out that '/rw/usrlocal' may be an issue, since it has a separate mountpoint in fstab. Not sure if that can be treated the same way as /rw and /home.

[v6ak]

I am afraid that this is not enough for what you want:

• /rw/config/rc.local
• bind mounts – you can modify anything, including sudoers or various other config files that can effectively privilege you even without sudo.

(Last but not least, if you want to access root through a compromised user, attacker can go this way…)

There might be more, but it does not matter now. Even those two suggest it is not feasible to do it without sacrificing anything from the current features.

Well, we could sacrifice those features just for some set of VMs. This gets close to #1006 and DVMs in Qubes 4. Those approaches can also handle the user being compromised, not just root.

Another way would be opt-in for /rw/config/rc.local and bind mounts and suid+dev – it would have to be configured in properties of the VM.

[tasket]

Yes, it does mitigate in concert with other precautions.

Threat model is de-privileged process using suid to re-escalate privs. It can't alter /rw/config etc. while its still just 'user', and these dirs are easy to quarantine in most AppVMs. (Even w/o quarantine, what pct of malware will target Qubes dirs?) OTOH, /home contents have to be retained in a majority of use cases.

As for features, its not a real issue for /home. Really, suid doesn't belong there.

FYI, this feature will be added to Qubes-VM-hardening so that fstab is modified at install time when the mount options are not already present.

[v6ak]

I am still not getting the point. If a process can create a malicious SUID binary, then it probably can also alter /rw/config/rc.local. Could you be more specific about the attack scenario you have in mind?

[adrelanos]

For this to make holistic sense, https://github.com/tasket/Qubes-VM-hardening is requisite knowledge.

/rw/config/rc.local is taken care of by https://github.com/tasket/Qubes-VM-hardening

[v6ak]

Aha, thank you for pointing this out. Now, it starts making sense. However, I am not sure if this makes sense in vanilla Qubes unless whole hardening is included.

[adrelanos]

Related:

(re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security? https://forums.whonix.org/t/re-mount-home-and-other-with-noexec-and-nosuid-among-other-useful-mount-options-for-better-security/7707

quote @madaidan

There’s a RHEL hardening presentation that gives a good idea of what mount options to use and where to use them.

https://people.redhat.com/sgrubb/files/hardening-rhel5.pdf

The mount options are at page 15. Noexec on everything possible Nodev everywhere except / and chroot partitions Nosetuid everywhere except /

There is also a section on the CentOS Protection guide and Arch Linux Security guide about this. https://wiki.centos.org/HowTos/OS_Protection#head-73cf15dd0e0cdf531bfc263e6694c79664962622 https://wiki.archlinux.org/index.php/Security#Mount_options

[adrelanos]

https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301320361 @solardiz:

Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)

---

Related: Disable SUID Binaries https://forums.whonix.org/t/disable-suid-binaries/7706

[marmarek]

I'm fine with mounting /home with nosuid + nodev by default. But noexec doesn't belong to default config - will break too many legitimate use cases.

[adrelanos]

https://github.com/QubesOS/qubes-core-agent-linux/pull/180

[adrelanos]

This was merged in Qubes as per pull requested referenced in my last post. Therefore I think this can be closed.

We can think about improving mount options for other mount point but other tickets should be created for that (and then linked here as notifications for everyone interested in this).

[adrelanos]

mount /tmp /var/tmp /dev/shm with nodev nosuid https://github.com/QubesOS/qubes-issues/issues/5329

[marmarek]

nodev on /home breaks qubes-builder (specifically: /dev/null and probably other devices inside chroot). I wonder what else...

cc @pwmarcz

[tasket]

Build outside of /home?

[marmarek]

Where exactly do you propose @tasket ? Chroot (especially for devel builds) should be persistent, to avoid recreating it each time, which doesn't leave much options in AppVM. In fact, I consider another solution - mounting /dev inside chroot from somewhere else (for example use devtmpfs, or simply bind-mount real /dev). I wonder what else is broken by this change. I've checked flatpak and snap (as they use chroot/mount namespaces too) and they use separate mount for /dev.

[tasket]

I haven't noticed breakage yet.

Only other alternative I can think of atm is to remount /home without nodev when starting the build process.

[marmarek]

Only other alternative I can think of atm is to remount /home without nodev when starting the build process.

That's also an option.