On Monday, August 28, 2017 at 10:46:22 PM UTC-7, Eric wrote: > 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?"
this wasnt specifically because of the passwordless sudo. its a general access control and hardening thing. i see firejail as complementary to qubes-os. ssh shouldnt access the x server. firefox shouldnt write outside of its own folder and Downloads. neither should shell out and call sudo. when they do, or try to, id really like to know about it. firejail can log such access, and you can have another process follow that log to alert you. but having firejail do that, and watching that log, are more processes, more attack surface. to add to extremely unlikely, ive only known of one ssh client exploit in the wild, and i think it was over 10 years ago. > > 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. subgraph was a neat idea. looked at it for a friend whos laptop lacked hypervisor extensions, but couldnt get it to work. > > 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?) looked over that out of curiosity since it seemed like a neat idea, but never tried it. > > > 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ab05b325-683f-417d-9862-1833fe867678%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
