On 03/11/2017 12:10 PM, Alex wrote: > On 03/11/2017 12:14 PM, Chris Laprise wrote: >> On 03/11/2017 04:20 AM, Alex wrote: >>> the only really read-write directories (their changes are actually >>> persisted) are /home and /usr/local. >> That is enough to be able to persist. > Yes, and that doesn't even need root :) So, both having root or not, > there is some degree of persistence attainable. > > Installing via DNF or any other package manager is an easy route to put > files in the relevant "system" directories, but since these are not > persisted, it's actually more convenient, from a malware point of view, > to just place them in the home of the user and set up some kind of > autostart (eg bashrc, or systemd user units, or gnome autostarts).
Yep! And ISTM this is an argument for using dispvms to handle mail (or any other WAN-exposed client/server): start a dispvm; copy mail client and mail "file" into it; do your mail; copy out and save the updated mail file (which is text); flush away the dispvm - all handled by a script(s). Don't retain potentially infect-able user files; stop, flush, and restart frequently. Paranoids accessing dangerous mail servers can run multiple mail clients in multiple dispvms so that if one is compromised, only that correspondence is lost - one could also run Samhain to monitor unusual behavior. > >>> As the others already stated there could be problems for the >>> actually running session, i.e. the rogue command could siphon all >>> your data to a remote location, but it would be only able to access >>> data in that AppVM and not the others. This action would not need >>> any root access, because all data is from the very same user that >>> downloaded/started the rogue program in the first place, so it >>> already has access. >>> >>> The only advantage that root access would give could arguably be >>> persistance (i.e. installation, as you suggested with DNF), but >>> that advantage is fake and will vanish on AppVM reboot. >> Disagree there. Root access would bestow greater ability to launch >> attacks against VM isolation. That would be rare in of itself, but >> the chance for improved security comes for free. > And that's the point where I agree with you, I overlooked the > exploitability of Xen virtual devices in my original answer. Software > running as root has easier access to the Xen para-vm communication > devices, and that may lead to crossing the VM isolation. > > >> There is another, much bigger issue: We don't want our systems to >> become a zoo of infected VMs with malware thrashing about in them >> (and on our networks!) with us as zookeepers. That would be >> irresponsible. >> >> Qubes' abilities should not be framed in a way that would encourage >> that. Even if isolation works 100% of the time, we should view that >> as the opportunity to remove and prevent malware---preferably with >> some help from the guest OS. >> >> Put another way: If VMs were teeth, would you prefer to have one >> cavity this year, or seven? > That's a gross oversimplification of the situation. In Qubes there are > several AppVM that are "all created equal", but to the user there MUST > be some difference, and he is advised to make use of the colored labels > to emphasize and remind these differences. > > While I don't certainly want to have all red-labeled VMs (i.e. the > malware zoo situation you propose), I'm pretty sure I will not trust > some VMs because they are used with dangerous websites/software. I will > consider them dangerous even with passwordless sudo disbled, because > there may be some 0-day that has been exploited for a local privilege > escalation that makes sudo a non-problem. > > I make sure to periodically purge those VMs (which I named dump-0, > dump-1, etc to even remember that they are not to be trusted and because > when I forget why they are here (hence, the cryptic name) they can be > safely deleted), and because of the periodic update restart cycles all > other AppVMs are not always on, so malware cannot rely on system level > persistence there. In those "safer" appVMs, I don't open suspicious > e-mails nor visit doubtful websites; activities that I try to perform in > the unsafe AppVMs. > > TL;DR: there's no malware disadvantage if there is no passwordless sudo > in Qubes (it can persist as the user, and can still see all the files of > that user), and there's very little advantage (temporary persistence in > "system" directories) that may even become a decoy of some sort with > passwordless sudo being enabled. > > In my humble opinion, this absence of actual advantages or disadvantages > makes the whole situation irrelevant from a security standpoint. There > are other issues that should be taken into account for a more complete > answer than just security as holy grail, and they can safely be > introduced in the decision when the security outcome is the same. They > range from "is having to remember several different root/sudo passwords > really safer? What if the user fails to use different passwords?" to > "how many root actions does the user do in an AppVM? Will this impact > his usual workflow, or will it be a corner case?" passing through "what > if the user focuses on keeping the systems updated (i.e. > excluding/fixing vulnerabilities that may contain privilege escalation > that bypasses the sudo problem) instead of relying on a complex set of > keys and permissions that may be completely bypassed by some security > exploit?" > -- 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/58c4181d.8535c80a.a27bc.5440%40mx.google.com. For more options, visit https://groups.google.com/d/optout.
