The question as always is, what are you protecting? If it's your user data, compartmentalize differently. If it's some kind of root privilege escalation, that's a lost cause, as the vm sudo page explains. If it's some kind of malware that could get written with root privileges, well, that gets erased by rebooting the VM, unless it's persistent in your user data, but if it is, it's incredibly unlikely to be runable (at least not without explicit user action).
I raise these questions because the answer to many of the "OMGWTFBBQ passwordless sudo" threads that appear every so often, come back down to either "whatever you're proposing wouldn't make a difference read the doc again" and "are you sure you read the doc and understood why the decision was made the way it was?" I don't disagree that hardening VMs in general is good practice; I am very sad that Subgraph is MIA and grsecurity patches are no longer available, since they were a great way to harden Linux VMs. In your particular situation, a good compromise might be the dom0 escalation prompt, described at the end of the VM Sudo documenation (no additional code, really, and at least *some* peace of mind that...it would take a few more seconds of extra work to find a root privilege escalation that would get around the prompt requirement?) On Monday, August 28, 2017 at 9:22:48 PM UTC-7, pixel fairy wrote: > firejail , https://firejail.wordpress.com/ > > can be used to restrict and/or contexualize a process with namespaces. i was > thinking of restricting ssh connections with it to prevent the free privilege > escalation qubes gives malicious apps in case of an exploitable hole in ssh. > but, firejail itself is more code to exploit, and though it matters less in > qubes, setuid. > > so what thinks all of you? worth the extra attack surface? > > was also thinking of using firejails logging to flag attempts at sudo etc as > another means to flag a host with problems. this again, means extra code that > itself could be exploited. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/89f60e76-177e-42fe-ba21-2313bff42b2f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
