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? -- 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/ocgkev%24rpd%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
