On Sat, Mar 11, 2017 at 01:10:08PM +0100, 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). > > >> > >> 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. >
Is this actually true? I dont think that root in a qube has any "easier access" to the Xen communication devices.Exploits may require root, but they need not. Anyway, it's a argument that could go on. I dont agree that "the chance for improved security comes for free". It's absolutely clear that Qubes aims to balance security with usability - some of the compromises that have been made seem wrong to me, this isnt one of them. I take steps to mitigate changes I dont like - you should do the same if you want a password on root access. But for most users (particulary new users) there is a cost to introducing passwrd access, and it's convenience. Joanna refers to this in the explanation. It's clear from the forums that many users struggle with the Qubes ideas anyway - I cant see that this change would make things easier for them. (Presumably you would need to have different password across different templates.) > > > 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. The answer to this is encouraging users to make good use of isolation, qube use and Qubes features. That isnt irresponsible. It's a way of dealing with the problem. I think you would need to develop a much more detailed argument to convince me that the answer to malware infections is putting a password on root access. As far as I can see most people, particularly new users with some linux background, just dont like the idea of passwordless root. That's fine. That's why there's a page devoted to it, and a solution. > > > > 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?" > Well put Alex I'd suggest another TL:DR Qubes allows passwordless root access for convenience. There's no real security advantage in enabling it but if you want to you can. -- 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/20170311131055.GB22253%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
