Passwordless sudo, SELinux - understanding security logic

User Support General
27

The default and “normal” flavor templates (gnome/xfce4) all come with qubes-core-agent-passwordless-root, which means you can use sudo inside all of them. If you are going into dom0 to get a root shell to use apt/dnf, this is an unnecessary extra step.

This is the point of my argument. Why send users to dom0 when they can send commands inside an isolated system? dom0 is the most important part of Qubes, if something goes wrong there, it’s game over. Like I said, it’s better if users, especially beginners, stay away from dom0 as much as possible.

Where do they store the root passwords? Some users don’t want to remember 10 different password and reusing them across multiple templates/qubes is far from a good idea. What’s the point of doing it this way? It’s going to be more frustrating that the current passwordless root way.

Don’t see the benefits of passwordless root? Out of my mind:

  • Users don’t have to keep multiple passwords in a place where they can lose them.
  • Don’t waste time writing an unnecessary password to install a program on an isolated system.

I’ll say it again, this is an isolated system running inside Xen. Bare metal systems require a password protected root because you can access both data and hardware, which is not the case with Qubes. Data can be accessed at the user level and restricting root or not won’t change that

I am still waiting for a list of the benefits of enabling root inside a qube. Nobody wants something added by default that doesn’t bring any benefits. Like my previous posts, I can’t see any other benefit than wasting people’s time.

28

I wonder where to start… or whether I should stop altogether. Anyway, let’s give it one more try and see if things would get any better:

@DVM

You can’t compare the in-qube workflow with the actions done inside dom0. From a security perspective, sending users to dom0 every time they want something new in their template/qubes is not the best idea. dom0 needs to be left alone as much as possible, even more so when we are talking about beginners. What’s the point of redirecting them to dom0 when they can sudo apt/dnf in an isolated system that can’t harm anything else around it?

I was never even planning to compare anything. The comparison was necessary in the context of the usability argument which you brought in. Now, after it was shown that usability is unrelated, you switch to defending security and put yet another counter question. OK, I will “answer”:

What is the actual harm of running qvm-run --user root VMNAME command in dom0? How is running sudo command in VMNAME more secure?

Furthermore (to make this at least a little on-topic):

How exactly is sudo command in VMNAME with unrestricted root more secure than the alternative in the case of restricted root?

Excuse me, but then why is this thread there?

Are you saying you posted multiple times without understanding the reason for the thread?

You want restricted root by default

I never said that. It’s not even the topic.

and defend its use inside all qubes,

Can you differentiate between “I am not an expert and I want to understand the logic of A, because its currently documented basis is unsound” and “I am here to defend the opposite of A”?

Also, can you differentiate between “I say this should be so” and “I provide a quote by someone who thinks this should be so, after having said the opposite previously”?

but you can’t point to any benefits that might validate your concerns?

My concern is the self-contradictory reasoning in the “WTF” document. That has been pointed to in the OP.

There’s no point in adding something if there’s no benefit to the end user.

Would you agree that applies to providing beneficial and punctual answers as well? (example: @marmarek for Q4)

@fsflover

Which root-only-readable secrets do you have

/rw/config/NM-system-connections/* containing all network passwords (for example)

and why are they not compartmentalized into a dedicated vault qube?

These files are in the standard sys-net and have root:root 700 restrictions.
So: passwordless root + root:root 700 permissions. If you see any logic in that, I don’t. As you see, that has absolutely nothing to do with protecting Xen as a #1 priority.

1 Like
29

nm-cli connection show --show-secrets as normal user…
The protection is having it in a separate qube, so your facebook qube can’t see it. Not by storing it as root-only file.

5 Likes
30

It’s not different and point to the same thing. The point I make here is that it’s different on the usability standpoint. For advanced users like you and me it’s no big deal because we know what we are doing. When it comes to beginners dom0 should be left alone as much as possible, I think we both agree on that right?

I did, I was referring to your sentence. We’re talking about root restricted access in *NIX, which is generally the default, but you can’t give a list of benefits from enabling it in a qube, which would have already answered your questions about why it was done that way in this matter.

The whole point of your main post is to understand why passwordless root is the default and why the root user isn’t restricted, but it’s actually easy to understand that in Qubes you separate your workflow by creating 1 qube for everything. This means, as the documentation you linked to says, that each qube hosts different data created at the user level. You have to ask yourself, what’s the benefit of enabling a root password inside a qube? If you can find a list of benefits and that it gives the user more security then go ahead and push the idea that it should be, but in reality and based on how qubes are used within Qubes OS, it’s not necessary because everything is done at the user level and that protects nothing. You said in your main post that it allows the user to destroy their qube, including /rw, but what’s the point of a restricted root if the user data can be deleted anyway (/rw host /home so it ends up the same)? The most important thing in a qube is the data it contains, root can’t protect it in any way.

I don’t understand what is unclear here. The SELinux part is new (since Qubes 4.2), so the question is valid and needed an explanation, I never said otherwise (it was helpful for me too). As for the rootless part, it’s been documented since about 2015 (I could go back that far) and most users know why it’s there. It clearly states that there’s no point in having root since user data is accessible anyway. That’s why I asked you about the benefits in our conversation, because that’s how we find reasons why it was done this way and not the other.

Can’t you get them using nmcli without using sudo?

31

Well, I gave you the logic, but it was helpless. And now I suspect it’s because of not fully comprehending Qubes logic.

Once again - what are you trying to protect in the qube? Does Qubes provide a better way to protect it than simple password?

Yes it always does, like none of any other OS. Password only gives a false sense of security. If it’s so important, there would be no Qubes.

(Not to say, in minimal templates you have your goal already achieved).

1 Like
32

Again, you simply shouldn’t rely on root isolation as a serious security boundary, when you have a hardware virtualization at your service. This is the main reason for the current default, because inexperienced users will not understand this important difference. You can add it, but it will never be as reliable, it’s just a weak defense in depth.

Also the root partition doesn’t even belong to the App qube, it’s taken from the Template. Wipe it, reboot, it will reappear untouched.

1 Like
33

deleted…

34

@marmarek

nmcli general permissions are set to yes, i.e. the possibility to show the secrets is unrelated to passwordless root alongside the restrictive file permissions.

@DVM

because we know what we are doing.

Considering the current thread, I am starting question that too :slight_smile:

When it comes to beginners dom0 should be left alone as much as possible, I think we both agree on that right?

I would be really surprised if anyone would be able to use Qubes OS without prior experience with at least one Linux distro and virtual machines.

but you can’t give a list of benefits from enabling it in a qube, which would have already answered your questions about why it was done that way in this matter.

This is the fallacy of the inverse:

1 Like
35

What do you mean by that? I don’t like the direction it’s going.

Then you are very far from understanding what Qubes OS is. It’s not just for people who have a Linux background, it’s also for beginners. It’s very much aimed at journalists, for example, and most of them are not computer specialists. A good example is the SecureDrop project.

You are asking something that has already been answered in what you have quoted in your main post. All of my messages have attempted to direct you in that direction, and also to provide reasons why passwordless root is a thing. Qubes is very different from a traditional system, but unfortunately, you don’t see it. Since this conversation is starting to become a bit insulting for no reason, because others don’t see it the same way you do, I see no reason to continue on this when everything is included in my previous messages. Do what you want with them, your answers are there, but you obviously don’t want them.

2 Likes
36

So, I haven’t been around here that long. The logic of passwordless root made sense to me when I first read it - the security mechanisms of the guest OS are designed to protect the data within the guest, so root isn’t really an escalation. Persistence can be achieved by modifying configuration files in the user’s home directory, and if you have user privileges then you don’t need to compromise system libraries in order to steal data. For the example of web traffic, you could just add a malicious extension to the web browser.

But the point about VM escapes does seem persuasive. Looking back at the trio of VM escapes in 2017, the Xen project claims that guests have to run code in kernel mode in order to exploit (Updates on XSA-213, XSA-214 and XSA-215 - Xen Project). With root, an attacker could load an arbitrary kernel module, but without it they would need to find some bug in the legitimate kernel/modules. So that seems like a strong argument against passwordless root.

2 Likes
37

My (admittedly) limited research pointed at this too, and opinions of Whonix developers aligned with this, so I choose to protect root in AppVMs.

Joanna’s later statements did too, where she mentions restricting root to protect Xen.

I would like to emphasize that the intention of this post was to say that:

  1. I have been using authenticated sudo (not passwordless) for a long time without issue.
  2. Using qrexec to authenticate is more user-friendly than every other Linux distribution out there.

I do not have to remember a password, and it cannot be cracked. AppVMs cannot easily get root. Unless there’s a hole somewhere that I’m missing. :slightly_smiling_face:

3 Likes
38

@DVM

You are asking something that has already been answered

No. You are just answering something that has not been asked.

@skyvine

For the example of web traffic, you could just add a malicious extension to the web browser.

Yes, if you look at the case of a web browser. My example was more generic, not specific to web traffic but traffic in general, so decryption could affect also mail or even curl in a qube based on a minimal template, in which one assumes everything is safer.

I suppose a more sophisticated attack may probably involve deanonymizing by using e.g. info from system logs (which is normally root accessible only).

@anon22772651

Except for protection from own mistakes, how does using authenticated root in dom0 help you?

2 Likes
39

Yeah, there’s definitely a usability tradeoff. And it’s true that Xen exploits are hecking expensive to develop. Personally, I don’t need to drop into root all that often and I’ve had some sketchy things happen recently so I’m uninstalling it. But to each their own.

40

If sudo is passwordless, it seems to provide no added security benefit, just the aggravation of having to remember to start almost every command with the word “sudo.” Why not just be root in the first place?

1 Like
41

Why not just be root in the first place?

Exactly.

When you have to run something as root, just become root and do it. Prefixing many command lines with “sudo” has zero usability benefit, just the opposite.

1 Like
42

Sudo protects user from herself, not from externals. Or, as suggested it is easier to remember when and what to do as a root (especially in /home/user directory), then to use sudo when needed.

I think this is the most obvious miscomprehension of the security threat levels and abilities to enforce them.

For the future novices to Linux and Qubes, I will again answer with a banal analogy:
Someone who created nuclear weapon will be prevented to threaten my house by the lock on my door.

Really? Someone can escape VM and cannot escape root?

2 Likes
43

I use passwordless sudo in dom0. DomUs create a prompt in Dom0 asking for permission to run as root.

Dom0 Prompt

No password, simply hit enter or cancel.

2 Likes
44

Someone who created nuclear weapon will be prevented to threaten my house by the lock on my door.

An assertoric statement with a hyperbole is still not an apodictic one.

If the secret codes for firing the nuclear weapon are inside that same house, the door lock will actually prevent from using it.

Here is another set of analogies:

(A) Clothes do not protect from nuclear weapons, therefore we should not wear clothes at all (for better usability)

(B) Clothes protect from weather, therefore they protect from nuclear weapons too.

(C) A slight sunburn should be considered equal to a nuclear weapon. If it happens, proceed with euthanasia.

Replace:

  • “clothes” with “restricted root”
  • “weather” with “malware”
  • “slight sunburn” with “partial damage”
  • “nuclear weapons” with “total data destruction”
  • “euthanasia” with “AppVM destruction”

The “WTF” claims (A) and (C). Through (B), proponents of the “WTF” try to ridicule everyone who questions any of that. This is rebuttal, not reasoning. By starting this thread I was hoping for reasoning.

2 Likes
45

@anon22772651

What kind of operation creates this dialog box?

How is it even possible a domU to do something against dom0? Or did you configure any special policies?

2 Likes
46

If you did, you didn’t act as one, honestly. It looks more like you were trying (or it turned out to be as that) to impose your idea, looking for approval of majority of other participants in the topic.

You didn’t answer any crucial counter-questions so we could better understand why it was more important than not, to have password. Instead, you are responding ad hominem, or on trivial statements.

At the end, one last question (you to answer to yourself): do you really think that the dev’s of such an OS like Qubes is misconsidered such a default setting like password for root is?

Simple adding a line to correspondent RPC policy, resolves this, for example

… or any other way that suits you.

I too will not participate anymore because it looks it is obvious no reasoning can change your mind.

1 Like