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). >> >> 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?" -- Alex -- 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/a8c0e60b-90ef-9504-99ae-f4ed01c1c46a%40gmx.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
