search

tasket / Qubes-VM-hardening

Fend off malware at Qubes VM startup
GNU General Public License v3.0
73 stars 10 forks source link

mount /tmp /var/tmp /dev/shm with nodev nosuid noexec #42

Open adrelanos opened 5 years ago

adrelanos commented 5 years ago

These folders are user writable.

Similar to

tasket commented 5 years ago

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?

adrelanos commented 5 years ago

These folders

are user writable.

Similar to

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.

adrelanos commented 5 years ago

Reported against Qubes too: https://github.com/QubesOS/qubes-issues/issues/5329