On 03/11/2017 07:10 AM, 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.
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.
At those moments when malware has an opportunity to take hold or
escalate, labels don't matter and you probably won't know. Neither you
nor the attacker has perfect knowledge, and the attacker may find the
anticipated vuln to be patched.
In that case, Linux has at least bought you some time.
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.
You seem to be going in the direction where a user does not / cannot use
storage in a normal way... everything is transient. Definitely not a
personal computing model, which is what Qubes aims for.
To put it another way, Qubes is not TAILS.
range from "is having to remember several different root/sudo passwords
really safer?
It doesn't work that way. Auth is channeled through a dom0 Yes/No prompt
(like copying between VMs), not a password prompt.
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?"
The client OS already has experience with that issue and struck a
balance. In the case of Debian and Fedora, the authorization persists
for a certain amount of time during a session so you are not prompted
often. The frequency is a bit more (due to separate VMs) but you only
have to hit Enter.
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?"
IMO its simple and doesn't change user focus at all.
--
Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
--
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/c1ac57d0-3cfa-52e3-28b1-31543121d931%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
