WTF?! Passwordless Root Access in VMs?

General Discussion
1

In Qubes we have passworldess sudo by default. This is a discussion about it.

Quoting from Joanna Rutkowska:

WTF?! Have you lost your mind?!

In Qubes VMs there is no point in isolating the root account from
the user account. This is because all the user data is already
accessible from the user account, so there is no direct benefit for
the attacker if she could escalate to root (there is even no benefit
in trying to install some persistent rootkits, as the VM’s root
filesystem modifications are lost upon each start of a VM).

2 Likes
2

Joanna’s “WTF” rant

I’d agree with every single word of it.

It’s easy to rely on magic thinking. That goes for this topic, just like
for the firewalls and all the other hardening stuff (or even forum
policies :wink:

If you know what you are doing: great! If not, just installing it and
then “feeling” better isn’t really helpful.

2 Likes
3

“Rant” was the wrong word to use and I regret using it.

That being said, I read through the whole text again and found its reasoning wanting.

I understand that she’s saying that Xen exploits are rare and ones executable from VMs are even rarer, but as I’ve said elsewhere recently, I believe security cannot be guaranteed for sufficiently complex systems, and Xen is sufficiently complex.

The past few years have shown us that we cannot take security for granted in even the most fundamental of systems (Spectre, Meltdown, RowHammer), and that what we know of is only what is discovered and disclosed. It’s a matter of preparing for unknown unknowns, and the idea that a critical VM-to-Xen exploit is out there, somewhere --perhaps already discovered (or created) but not disclosed-- isn’t that farfetched in this context.

By the way, Joanna mentioned that:

as of 2016, there have been only three publicly disclosed exploitable bugs in the Xen hypervisor from a VM

I lack the knowledge to confidently update this number and I’m sure at least someone reading this has been keeping track; so can anyone shed some light on how this is holding up half a decade later? What is the tally now?

 

Also, while it seems true that someone with access to a Xen exploit that’d allow a hypervisor attack from a VM would very likely have access to root escalation, that isn’t really an excuse to keep the door open. You shouldn’t uninstall the lock on your front door just because a person who can crack open your one-ton safe is unlikely to be hampered by that lock.

We should be striving to place as many obstacles in the attackers’ paths, as per the Swiss cheese model (attached again below). We should raise the number of hurdles an attacker must saunter over as long as they’re not adding to a high UX cost.

Joanna’s points of non-passwordless root making VM updates a chore is solved by using Tasket’s qubes4-multi-update script–that was what I did after experiencing that for myself. If I remember correctly, it sidesteps the problem by running updates using qvm-run -u root ....

1024×473 38.8 KB

It’s not a matter of making users (or maybe just me) feel good, as no one has yet been able to make an argument to convince me that the costs of sudo prompt (UX or otherwise) outweigh the security benefits. I’ve been told to “agree to differ” by one of the more technical and respected members of the community, but that’s hard to swallow especially when it comes from someone with his level of knowledge.

Would this be a good point to split the thread and make a poll?

4 Likes
4

Done! Thanks for pointing out. To get out attention I guess you can also flag and suggest on the flagging message that the thread be split. Or mention me. Otherwise I may miss it.

2 Likes
5

Hi, is this by default in some template?

In any case, can you clarify if this is the root account of the Hypervisor or the root account of the VM? (I still don’t try Qube, quite new here…)
In both cases in very bad, in the first one it’s a zero day :smiley:

1 Like
6
2 Likes
7

Passwordless root is default in all domUs (VMs) but not dom0. Minimal templates do not have passwordless root since they’re minimal and lack the package for it.

Security theater

I mean, I get that sudo prompt may be like airport security, but can anyone tell me why that is instead of just slapping a label on it and never elaborating? I’m not asking for a thesis, just something more than just calling it a ‘feel good solution’, ‘security theater’, or saying we should ‘agree to disagree’.

If I’m missing something fundamental since I’m a non-technical person, just let me know what that is.

3 Likes
8

“Rant” was the wrong word to use and I regret using it.

That being said, I read through the whole text again and found its reasoning wanting.

I understand that she’s saying that Xen exploits are rare and ones executable from VMs are even rarer, but as I’ve said elsewhere recently, I believe security cannot be guaranteed for sufficiently complex systems, and Xen is sufficiently complex.

The past few years have shown us that we cannot take security for granted in even the most fundamental of systems (Spectre, Meltdown, RowHammer), and that what we know of is only what is discovered and disclosed. It’s a matter of preparing for unknown unknowns, and the idea that a critical VM-to-Xen exploit is out there, somewhere --perhaps already discovered (or created) but not disclosed-- isn’t that farfetched in this context.

By the way, Joanna mentioned that:

as of 2016, there have been only three publicly disclosed exploitable bugs in the Xen hypervisor from a VM

I lack the knowledge to confidently update this number and I’m sure at least someone reading this has been keeping track; so can anyone shed some light on how this is holding up half a decade later? What is the tally now?

Disclosed exploitable bugs in the Xen hypervisor as of 2021 come to
41(top of my head - worth checking in the morning).
Now before you get excited about that number, it includes all Xen
bugs where there is a theoretical possibility of escalation - it doesn’t
include DOS or (generally) information leaks. In most cases, an exploit
would require precise timing attacks or particular configurations. Most
of these bugs are not exploitable in Qubes at all because of the design
decisions taken in Qubes, and some of the others require specific
non-standard configurations.

 

Also, while it seems true that someone with access to a Xen exploit that’d allow a hypervisor attack from a VM would very likely have access to root escalation, that isn’t really an excuse to keep the door open. You shouldn’t uninstall the lock on your front door just because a person who can crack open your one-ton safe is unlikely to be hampered by that lock.

You appear to think that root escalation in a VM is a precondition for
escalation from the VM - it is not.

We should be striving to place as many obstacles in the attackers’ paths, as per the Swiss cheese model (attached again below). We should raise the number of hurdles an attacker must saunter over as long as they’re not adding to a high UX cost.

Joanna’s points of non-passwordless root making VM updates a chore is solved by using Tasket’s qubes4-multi-update script–that was what I did after experiencing that for myself. If I remember correctly, it sidesteps the problem by running updates using qvm-run -u root ....

The VM updates issue is solved, I think, using the GUI tool. No need
for any extra script there.

1024×473 38.8 KB

It’s not a matter of making users (or maybe just me) feel good, as no one has yet been able to make an argument to convince me that the costs of sudo prompt (UX or otherwise) outweigh the security benefits. I’ve been told to “agree to differ” by one of the more technical and respected members of the community, but that’s hard to swallow especially when it comes from someone with his level of knowledge.

“Agree to differ” - I was trying to be polite.

Would this be a good point to split the thread and make a poll?

I think this polling is misplaced. Consider the readership here - new
users, people with little experience of Linux or security issues, people
who don’t use Qubes, people who wont use Qubes, people who oppose
Qubes, etc etc
And even where you are dealing with people with a background in security
they bring to Qubes assumptions about how things are best done, and
why. I have a long standing argument about the Qubes signing key with
someone who generally I defer to on all matters security, for just this
reason. (There’s a thread on this in he Forums)
What’s the value in getting the input from this mess in a poll?
Many new users struggle with the Qubes interVM clipboard - if you polled
many people would want it replaced so you could just copy/paste as
normal and have data transferred between Qubes - we wouldn’t do it.

If there is a new thread perhaps someone could copy my comments in to it.

3 Likes
9

“I mean, I get that sudo prompt may be like airport security, but can anyone tell me why that is instead of just slapping a label on it and never elaborating? I’m not asking for a thesis, just something more than just
calling it a ‘feel good solution’, ‘security theater’, or saying we should ‘agree to disagree’.”

Fair enough:
If you build an airport where each passenger is checked individually for 3+ hours for “security reasons” you shouldn’t wonder if people stop using
your airport.

sudo in VMs is a similar example where a minimal security gain is gained at the expense of user annoyance. Having multiple VMs in Qubes OS can already cause some annoyance, but at least leads to a major security gain.

Why is the security gain of sudo minimal?

  • An attacker already has access to all your data in that VM.
  • Privilege escalation tends to be trivial in most cases.
  • Privilege escalation is not necessarily required to attack dom0.
  • Privilege escalation will not allow the attacker to modify the template
    data.

Security circus / security theater / snake oil is very common nowadays - e.g. some people seem to put a lot of effort in buying some high-quality lock for their door (“I use Qubes OS”), but then always keep their door open (“I only use a single VM. The other stuff is just too inconvenient.”).
It just indicates that you could use your time more effectively. Btw that’s why I hadn’t elaborated initially… :wink:

2 Likes
10

can you clarify if this is the root account of the Hypervisor or the
root account of the VM?

root account of the VM and the point is that due to the way qubes is
architected it has very little impact (all changes to the root file
system are lost upon shutdown of the qube).

So: don’t panic and follow the discussion :wink:

1 Like
11

Sven’s respose from a locked thread:

Starting a new thread, bases on this reply:
https://forum.qubes-os.org/t/intrustion-detectors-in-dom0-bad-idea/3461/16

@fiftyfourthparallel:

as many obstacles in the attackers’ paths

The entire point was that for an attacker commanding a Xen 0-day
obtaining root privileges is not an obstacle. And that’s the only form
of attack where the whole discussion about passwordless root even makes
sense.

Think about it:

  • the attacker is already executing code on your machine
  • can already persist in your home directory
  • any changes that attacker could make through root privileges DO NOT
    persist

So giving the attacker passwordless root access in a standard qube
doesn’t change a thing. Hence all it really is at that point is a UX
hurdle.

Standalone qubes are a different topic, as are templates in which you
are hopefully never execute anything besides ‘apt’ or ‘dnf’.

It’s not a matter of making users (or maybe just me) feel good, as no
one has yet been able to make an argument to convince me that the
costs of sudo prompt (UX or otherwise) outweigh the security
benefits.

Ok, I am up for that discussion. Please tell me which security benefits
sudo prompt affords you in a standard AppVM qube setup. My goal will be
to prove to you that there are none, and hence it’s just a hurdle.

I’ve been told to “agree to differ” by one of the more technical and
respected members of the community, but that’s hard to swallow
especially when it comes from someone with his level of knowledge.

Only if you assume that you are right. Could it be that the “more
technical and respected members of the community” understands something
that you don’t? I’d at least consider it.

Would this be a good point to split the thread

Done. I just see @deeplow made a new thread here:

So feel free to answer there. I’ll lock this one to avoid duplicate threads.

and make a poll?

About? The root thing? It’s not up for vote: it’s a technical question
not a matter of opinion.

This was a helpful response.

To paraphrase for others like me: An attacker who is already in position to escalate privileges can already attack Xen, provided she has an exploit. Otherwise, she is trapped by the compartmentalization of Qubes, and what she has access to is ultimately the user’s responsibility. Therefore, sudo prompt offers no benefits in that scenario–it isn’t a beachhead for an attack on Xen, since someone who can escalate already has a functionally identical beachhead. However, this doesn’t apply to standalones since they lack both disposability and often compartmentalization.

I wasn’t thinking with Qubes and was so focused on the traditional model that I kept seeing PE as a common gateway to arbitrary code execution and maybe even remote code execution. I did some light reading around the issue (time constraints) and what I found agreed with this understanding (e.g. This csoonline article), but the focus of these articles are obviously not Qubes, with its radically different architecture.

 

About a poll: I wasn’t trying to bring change to Qubes through something like a binding referendum, but rather wanted to see what other users thought about the issue and prompt some debates (pun not intended)–sudo prompt is one of the first things I enable on new systems, and it’s a short process (especially with scripts), so not having it as the default doesn’t really affect me.

I completely understand that one doesn’t engineer systems based on popular votes–that’d be a recipe for disaster. If the US had people vote on technical specifications of space shuttle parts we’d end up with spacecraft that aren’t even fit for the Kerbal Space Program, with all given variants of the name ‘Launchy McLaunchFace’. However, one shouldn’t completely discount the use of a poll on a forum that has self-selected a group of interested people, so this isn’t exactly a poll of the whole internet. The arguments for and against might also yield insights, like in some democratic debates, and so shouldn’t be waved off. Others also had good points, but I want to mention that the mindset of waving off something as it’s “not necessarily required to attack dom0” or Xen is dangerous. Even though I concede that I was wrong, I do want to say that the history of exploits should show that it is often the seemingly unimportant that morph and combine into disasters (or opportunities, depending on where you stand).

 

Since we’re on the topic of VM security, what do you make of Qubes-VM-hardening, which is bundled with an configure-sudo-prompt script? It seems widely used, but does it really provide more protection given the logic that an attacker who could execute code is in position to do much worse?

2 Likes
12

Here’s another perspective:

myuser ALL=(ALL) NOPASSWD:ALL
Look familiar?
Wait, what’s that “myuser”?
It’s a standard config on Microsoft Azure.

And, it’s not just Microsoft.
ec2-user ALL=(ALL) NOPASSWD:ALL
That’s a standard config on Amazon EC2.

%google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL
That’s GCP

SO 2 of the 3 public cloud providers ship a standard config with
unrestricted sudo privileges.
Surely there must be tens or hundreds of thousands of compromised VMs
flooding the internet with garbage because of this?
Dont seem to be.

So given that security professionals running public clouds are happy
with this configuration, you might like to consider your evaluation of
risk.
To anyone who is used to provisioning VMs on public clouds, the Qubes
position looks unexceptional.

7 Likes
13

Didn’t know about this. Thanks for the insight.

1 Like
14

About a poll: […] wanted to see what other users thought about the
issue and prompt some debates (pun not intended)

My concerns is that a poll would stand as a snapshot in time and not
reflect any consensus reached, thus it might do more harm than good.

I want to mention that the mindset of waving off something as it’s
“not necessarily required to attack dom0” or Xen is dangerous.

I didn’t read it as “waving off” but a specific answer to the assumption
root privileges would somehow enable or ease a Xen compromise earlier in
the thread.

@deeplow wisely quoted Joanna’s post when starting this thread:

In Qubes VMs there is no point in isolating the root account from
the user account. This is because all the user data is already
accessible from the user account, so there is no direct benefit for
the attacker if she could escalate to root (there is even no benefit
in trying to install some persistent rootkits, as the VM’s root
filesystem modifications are lost upon each start of a VM).

Maybe her post would have been less misunderstood if it would have
been limited to the above, which says it all.

what do you make of Qubes-VM-hardening

I have no opinion about it specifically, but about it’s place in my
priority list:

  1. compartmentalize … limit possible damage

  2. intrusion detection … know early, so you can react/adjust

  3. OpSec … minimize opportunity / “hardening” me not the tool :wink:

  4. hardening … make it more difficult

Hardening my qubes is last on the list, because there is some hard to
define benefit with potentially limitless effort. Successful defense
means you have to be right all of the time, while successful offense
means you have to be right once.

That means no matter how good your defense is, ultimately it can and
will be penetrated. So before I spend a lot of energy on defense, I want
to make sure I did all I can to limit the possible damage and know about
a compromise as soon as possible.

Once I get to 4) I’ll certainly look at qubes-vm-hardening first.

7 Likes
15

i am standing in the middle for polling. lesser ux type question could provide better ideas of what beginner qubes user struggle about. technically inclined questions surely should not be left to public voting. the qubes survery has accomplished this in good faith.

is there a possibile benefit to add a root password to vm i continually use for more than 1 sessions? what would be the best approach to harden vm root capabilties? i understand this may be insignificant against an adversary that can exploit Xen but it may be more efficient to contain potentially evil executables, downloads, applications, etcetera within that vm. does qubes have a vm hardening guide? i cant seem to locate an issuance.

1 Like
16

I think this picture says all:
https://xkcd.com/1200/
:slight_smile:

7 Likes
17

It won’t be long before XKCD does everything and posting comics becomes the new “Simpsons did it!” of the geek world.

1 Like
18

Where would you start or is there a guide for this? Thanks,

1 Like
19

Where would you start

2 Likes
20

Qubes ticket:

Especially this comment by Joanna where she refined/updated her opinion is highly interesting and recommended:

Automate vm sudo authorization setup · Issue #2695 · QubesOS/qubes-issues · GitHub

//cc @tasket

2 Likes