Qubes-VM-hardening
Qubes-VM-hardening copied to clipboard
tasket
mount /tmp /var/tmp /dev/shm with nodev nosuid noexec
These folders are user writable.
Similar to
- https://github.com/QubesOS/qubes-issues/issues/5263
- https://github.com/tasket/Qubes-VM-hardening/issues/41
What is the threat model for this?
Since these are based on tmpfs, their contents will not persist across vm reboots. So I think an unprivileged malware would have to wait for a legitimate root process to place a suid file or node there?
These folders
- /tmp
- /var/tmp
- /dev/shm
are user writable.
Similar to
- https://github.com/QubesOS/qubes-issues/issues/5263
- https://github.com/tasket/Qubes-VM-hardening/issues/41
Quote Joanna (founder of Qubes OS):
I've been recently talking about this with Solar Designer of Openwall (a person who probably knows more about Linux security model than most of us together)
Quote solar:
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.)
Therefore I concluded: SUID has to go away. At least user (speak: possibly malware) created SUID should be prevented form being easily executed.
Getting rid of SUID binaries which are installed by default is worthwhile too but less trivial.
Reported against Qubes too: https://github.com/QubesOS/qubes-issues/issues/5329