just remembered, a couple other ssh exploits, and googled for them, found a couple others. so that does come up once in a while.
On Tue, Aug 29, 2017 at 12:54 AM pixel fairy <pixelfa...@gmail.com> wrote: > 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 a topic in the > Google Groups "qubes-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/qubes-users/RnKRH0lIP_c/unsubscribe. > To unsubscribe from this group and all its topics, 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/ab05b325-683f-417d-9862-1833fe867678%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CACr%3DtZdi_du%3D82Ym0wwqVSLg5Hzw8PwzsVHXKdV23Nd3RJDgjA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.