On Monday, April 10, 2017 at 2:55:42 PM UTC-4, Reg Tiangha wrote: > On 04/10/2017 12:41 PM, Chris Laprise wrote: > > > > Changing something in /usr/local/bin (or I assume /rw/usrlocal/bin) > > requires privilege escalation. If sudo has no auth process, then there > > is no challenge for the attacker... they can change /rw/usrlocal in > > any case. > > > > But also, they can change /rw/config including rc.local and firewall > > scripts which run as root! > > > > BTW, my "better question" above really referred to the non-home areas > > of /rw. > > > > Ah, got it. Well, that's something, I suppose. > > >> > >> While my versions do exactly what you would expect them to do, the > >> difference is that each time you launch one of my versions, it starts up > >> a key logging service (no root required!) in the background that > >> persists even after you close the app that launched it. So for that > >> entire session (assuming that AppVM is connected to the Internet), I can > >> capture all of your keystrokes. And because /usr/local is persistent and > >> you probably don't constantly check /usr/local for changes (because > >> again, you're not paranoid), those programs will stick around and launch > >> the next time you access the VM. > > > > But this is a problem for things like ~/.bashrc as well. Using PATH= > > or alias, attacker could divert you to a phony `git` command that logs > > your github password before executing the intended operation. > > > > That's why I suggest people consider enabling sudo auth and securing > > shell init scripts in /home (see my post "Protect AppVM init startup > > scripts"). You could even have an in-template startup script that > > resets most of /rw (root-owner bits) to defaults.... really shouldn't > > be hard. > > > > In that case, your attack scenario hinges on having a Linux escalation > > exploit, and even then it might not last long enough for you to > > collect valuable info (e.g. resets or updates occur that patch the > > vulnerability). > > > > > > Still, though, let's say such Linux escalation exploit exists and a > malicious person can access the AppVM's (let's set aside TemplateVMs for > a moment) file system. They can't stick anything in most places in / > because they'll disappear when the VM shuts down. Changes in /home/user > could work, but because users interact with /home on a daily basis > through shells or file browsers, the likelihood of them noticing changes > there might be a bit higher so that might not be the smartest move. But > how many here on this list regularly check their app/sys VMs for > modifications to /usr/local? I'm doubting it's very many, and that I > guess is my main concern. > > Some people may not even be aware that it *is* persistent, so people who > use something like Whonix who've been targeted might even have stuff > living in /usr/local right now and may not even know it (since privilege > escalation exploits in tor-browser seem to be found every so often). > > I'm definitely going to apply your scripts to my TemplateVMs soon now > that I've been made aware, but I wish there were a way to turn off > persistent /usr/local and to make AppVMs use the TemplateVM's version > instead. I don't use the feature, so I would prefer that /usr/local gets > wiped every time like everything else in the root file system since > that's the behaviour I expected to happen when I first started using > Qubes (I only discovered for myself that it wasn't the case when I was > trying to figure out why a custom-compiled version of Wine that I had > made and installed in my TemplateVM wasn't showing up in my AppVM; its > default prefix is /usr/local, which is why). Is there a way to turn off > persistent /usr/local? Or is it something that's baked-in?
absolutely! great discussion! -- 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/3cfb5ea6-a88a-44f4-a364-a7d19b34e22e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
