Passwordless sudo, SELinux - understanding security logic

User Support General
21

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?

Excuse me, but then why is this thread there? You want restricted root by default and defend its use inside all qubes, but you can’t point to any benefits that might validate your concerns? There’s no point in adding something if there’s no benefit to the end user.

22

These are good questions, since they allow to clarify the security approach of Qubes OS. Qubes provides security through compartmentalization, with very strong guarantees based on hardware virtualization, which AFAIK last time was broken in 2006 by Joanna herself. Compared to this level of security, root permission restrictions are nothing. You should not rely on them at all in order to achieve a reasonable security; check how many CVEs this approach has every year and compare it to the number of serious QSBs. Compartmentalize your sensitive data with offline qubes (where you never run any software!) instead of using root directories in an easily compromizable, networked qube.

There should be no problem with damaging the whole App qube: it’s root partition is reset every reboot.

Which root-only-readable secrets do you have and why are they not compartmentalized into a dedicated vault qube?

2 Likes
23

The documentation is a Community effort; It would be good to have GUI instructions there. Please help if you can.

Concerning GUI software installation:

24

I’m using a Dom0 prompt for root. I don’t see why it’s not the default, there are zero usability issues and makes it harder for AppVMs to obtain root.

I type my command, or run my program and a prompt shows up asking if I want to authorize the action and I hit enter and it’s done.

Preventing malware from gaining root is vital to prevent malware from breaking out of a VM, spreading to dom0 or other VMs. Many attacks aren’t possible with root and/or kernel level compromise.

Quoted from Whonix Forums. I see no reason to not have the user simpy hit enter if that’s true.

1 Like
25

There are times, working in dom0, where I am having to preface every single command line with sudo. Particularly when I am working with the policy files, or /etc/qubes-rpc. It starts to get aggravating after a while and I eventually do sudo su.

1 Like
26

Yeah. Thanks for the course-correct.

What do you mean by this? I already use dom0 terminal for installing new software from debian package repos. I use qvm-run --pass-io --user root debian-12-xfce 'apt install <PACKAGE-NAME> in order to install some new package.

If I wasn’t using dom0 terminal, I would still have to start the template of that qube first, then, go to the template terminal, and type in sudo apt instlal <PACKAGE-NAME> anyways. I just don’t understand how your example is relevant and supportive to the arguing in favor of having passwordless root in qubes in the context of individual qube security.

They can simply enter their root password, or user password when they want to use sudo in their template terminals. You know, like all other linuxes require one to do that way. Again, having a password for sudo doesn’t prevent one to “use sudo apt/dnf in an isolated system”.

So, in this case, I really don’t see/understand the added benefit to the end user that passwordless sudo brings when the user is operating inside the individual qubes. Again, is typing one’s own sudo password such a hassle that we completely throw it away? In a decade of my Linux use, I never wished for a passwordless sudo before.

I simply do not understand how you can handwave-away “damaging the WHOLE App qube.” I mean, this includes my coding work in my home directory that gets wiped away when the whole app qube gets wrecked. For example, I use Emacs for my code editor in one “coding” qube. I use various Emacs packages for extending my Emacs use. Let’s say one day, I add a new Emacs package. And without my knowledge, it tries to do something like sudo rm -rf /. Nevermind the reasons for doing such a thing for an Emacs packages, the possibility of no-checks-applied sudo commands are a factor for concern to me. If the Emacs package example sounds ridiculous, apply the same logic to Neovim users extending their tool use with various Lua scripts, or some users downloading and executing some bash scripts. I mean, I would definitely appreciate a password prompt when some new script that I downloaded without paying much attention (which is limited per person per task anyways), attempts to do some sudo stuff in the background.

Don’t get me wrong, but I am having trouble understanding your point in the context of this thread’s topic.

1 Like
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