Passwordless sudo, SELinux - understanding security logic

User Support General
1

Hi,

I know there are many old threads in which this has been discussed. I have spent quite a few hours trying to find the answers to my own questions in them, but it seems I can’t. So, I hope it is OK to ask what interests me in particular.

Please note, I am not questioning the authority or the expertise of the author. Not at all. I am willing to understand the logic of all that, as I am not an expert.

Please also note that I have already read multiple times the well-known answers “you can disable it if you will” and that “if something reaches dom0 it is game over”, and they are not the actual depth I am looking for.

The background explains:

# 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).

The way I read this is: The user has full access to user data, so there is no point in not allowing full access to every other data as well, because that cannot damage the OS persistently. Sounds reasonable at first sight.

However, this also implies that, if a user process can damage user data, it is OK to let it damage the whole qube (/rw included, resulting in persistence as well). It is also OK to allow malware which can damage some (or all) user data, to also read root-only-readable secrets from /etc and potentially transmit them to an attacker (in case of an Internet connected qube), thus letting it reveal its full potential, rather than restricting damage as much as possible (which a restricted sudo would give).

I am also trying to relate that to each component of the InfoSec “CIA” triad, e.g:

Confidentiality
In information security, confidentiality “is the property, that information is not made available or disclosed to unauthorized individuals, entities, or processes.”

Unless I am misunderstanding this, it also means that information which is only available to privileged (root) users and processes must not be disclosed to unauthorized ones.

My essential confusion comes from the fact that the “WTF document” seems focused on the security of the OS itself, not of data, and at the same time even that is contradictory - it explains how impossible persistence is, yet facilitates it.

It is somehow assumed that a small damage should not be a reason not to have a complete in-qube disaster. IOW, security becomes all or nothing - we can’t have the perfect security inside the qube, so let’s not have any in-qube security at all, let’s make it easy to break everything, reveal everything, make it convenient to the user to break things oneself, etc.

Naturally, the questions which arise are:

1. What is the logic of that? (especially in a security focused OS)
2. How does that fit the principle of least privilege?
3. Why use GNU/Linux at all? In Windows the user is always admin anyway.

Obviously, one can easily be tricked to reveal one’s root password to a malicious party. Yet, the very prompt itself is a raised flag saying “Hey, something wants escalated privilege, so be careful”, as confirmed by one of sudo’s authors himself. Is that not a good warning? How would removing it benefit security? Or why easiness comes first?

Recently, it SELinux support in Fedora templates has been anounced. On a Fedora’s forum thread I read this question and answer:

Is there any point in SELinux on the desktop if you enable passwordless sudo?
In the default configurations not really.

So, the logical question is:

4. What configuration does the new Fedora template use? Does SELinux in it actually protect from anything (and how), considering the default passwordless sudo? What good is it at all? What about Debian (is it less secure without SELinux)?

I hope someone can shed some bright light on all these matters.

5 Likes
2

Standard Fedora’s SELinux policy is used there, with unconfined “user” account. The local “user” can still do everything, but having SELinux enabled makes it possible to use it for targeted cases (previously enabling SELinux in a template in enforcing mode made it essentially unbootable). Those targeted cases are both about specific services (there are several services shipped with SELinux policy, for example we use it also for extra sandboxing of the inter-qube file copy service), but also various sandboxing tools like bubblewrap, podman/docker etc. They can use SELinux to create stronger sandboxes.

In short: the local user still can do everything (as it already has access to all the data), but SELinux gives an extra tool to isolate some processes from becoming that all-powerful local user.

As for Debian, it doesn’t fully support SELinux out of the box. But it does support AppArmor (also under qubes) which can be used for similar purpose (although it’s a weaker tool for that…).

2 Likes
3

Thank you, @marmarek. That gives some clarity.
What about questions 1-3? Can you answer those too?

1 Like
4

Personally, I think these are based on user choice. Adding too much security to all qubes by default would lead to frustration for most users (too complicated or too many things to tweak to do a specific task). As stated on the official website, Qubes is a reasonably secure operating system, it secures things by default, but not to the extreme.

If you have not already done so, take a look at the following project:

5

@DVM

I can’t relate your answer to the questions, sorry.

The passwordless sudo is developer’s decision, not based on a community poll (user choice). My questions aim to clarify the actual logic of that decision in relation to general security principles.

1 Like
6

You quoted the answer to your own question in your main post. You have another part of your answer in my post, which brings up the fact that Qubes is a reasonably secure OS. If you want more protection, you need to apply it yourself (with the project I linked, for example).

7

there is a question at the end of the installer to ask if you want a different password for sudo

8

I don’t recall seeing that. Is this something new to 4.2 or has it just been too long since I installed and I’ve forgotten?

1 Like
9

I think it was there in 4.1 already, but it’s only for dom0 IIRC, it’s up to users to set a password to the user in the templates if they don’t want passwordless root

10

It’s in the first part of the installer where you set your user and password. There’s another option to enable the root user account, but that’s only for dom0, not the qubes.
You can see it here: Qubes OS openQA: qubesos-4.2-install-iso-x86_64-Build4.2.202311301113-install_nvme_4kn@uefi test results

1 Like
11

@DVM

You quoted the answer to your own question in your main post. You have another part of your answer in my post,

Call me stupid but I cannot guess which part of the OP you consider to be the answer to questions 1-3. Could you please clarify?

Regarding:

which brings up the fact that Qubes is a reasonably secure OS.

You keep accenting on that particular word but how is that related the actual questions? The introduction of the documentation also says:

“Qubes OS is a free and open-source, security-oriented operating system for single-user desktop computing.”

If I bold “security-oriented”, would it make it more that and less the rest?

As stated on the official website, Qubes is a reasonably secure operating system, it secures things by default, but not to the extreme.

I agree that the official website says “A reasonably secure operating system”. However, it does not bold “reasonably” and does not say the rest of your sentence. Considering all the stuff by Joanna which I have read, I am more inclined to read “reasonably secure” as a deliberately picked reminder to everyone that nothing is absolutely secure, and one should always keep one’s eyes open and think what one is doing. Additionally, it shows that a person, who understands security and is honest, would never attempt to fool others with strong marketing words but would approach it with the right attitude. Of course, interpretations are subjective and this is off-topic.

In short: the “WTF” page does not justify passwordless root with Qubes OS being less secure than it could be (as you seem to imply).

Adding too much security to all qubes by default would lead to frustration for most users (too complicated or too many things to tweak to do a specific task).

Restricted root access is a normal (expected) default (not over-hardened) security measure in all *nix systems. What is not normal is not to have it deliberately. So, I really don’t understand why the former should be frustrating to anyone willing to use a Linux distro in any way.

If you want more protection, you need to apply it yourself (with the project I linked, for example).

As stated in the OP, I have already read many times that it is possible to change it. That is not what I am asking though. Forgive me to remind.

I don’t recall seeing that.

Me neither. I don’t see it in the linked video too. Am I looking at the wrong frame?

3 Likes
12

The quoted part of the documentation is your answer. Whether root is active and password protected or not, user data is still accessible to any attacker with user-level access to the qube. Even if you restrict /rw access with the root account, you can still create malware persistence in the /home directory in various ways that will be executed every time the qube is started.

I do because that’s the important information in my answer. As for the “security-oriented” part, I don’t see what’s wrong with that? “Qubes is a reasonably secure OS”, meaning it’s security-oriented?

I agree that it’s a reminder that nothing is 100% secure. It’s also a way to consider that it’s more secure than other systems, but it doesn’t push the security aspect to the extreme.

I know all this, I never said otherwise. Understand that we’re not talking about a single system here. Of course, securing the root user is necessary in a classic *nix system scenario, but on Qubes OS it would be too much work. Imagine forcing non-advanced users to get a root password for every single qube they create (no password reuse since it’s not security oriented, right?), it will be painful for them and human error will obviously occur. That’s one of the reason why Qubes come with a passwordless root by default, because it’s not only based on security but also on usability. It’s up to advanced users to tweak their Qubes security in this regard. Everyone has a different threat model, if yours is to have a root password inside your qubes then do so, what’s stopping you from doing it on your system without making it the default for everyone?

1 Like
13

@DVM

The quoted part of the documentation is your answer.

Then, I guess, I don’t understand it.

Whether root is active and password protected or not, user data is still accessible to any attacker with user-level access to the qube.

Why is that a sufficient reason to make all data accessible at all times for all use cases?

If I may provide an analog: If you give your car keys to a friend for a weekend drive, you don’t also give him the key to your home and your bank account password.

Example: Is it not possible to have malware which relies on passwordless root to modify a system crypto library, resulting in the decryption of some or all user traffic? Then the malware can even delete itself and upon qube reboot the crypto library will be restored, thus leaving no trace. Integrity and availability of data are not affected but confidentiality is. That would not happen if the library would not be modifiable (regular restricted root).

Even if you restrict /rw access with the root account, you can still create malware persistence in the /home directory in various ways that will be executed every time the qube is started.

How exactly?

I know all this, I never said otherwise.

You call it “extreme” security. I still don’t know why. Why not call the passwordless root “extreme unsecurity” instead, as it is the actual deviation from the normal? Extreme security is, for example, to disable root login completely.

Understand that we’re not talking about a single system here. Of course, securing the root user is necessary in a classic *nix system scenario, but on Qubes OS it would be too much work. Imagine forcing non-advanced users to get a root password for every single qube they create (no password reuse since it’s not security oriented, right?), it will be painful for them and human error will obviously occur.

To run a command as root in a VM, we execute qvm-run --user root VMNAME command in dom0. We don’t type (or need to remember) any passwords, right? So, this:

# At the same time allowing for easy user-to-root escalation in a VM
# is simply convenient for users, especially for update installation.

adds no value to it. Template updates are controlled by dom0 and it does not need passwordless sudo to run a root process in any VM. If there would be any root password, that would be just one - for dom0. However, I don’t see a practical use of it, except probably protecting the user from easily breaking one’s own system. That (and not the current opposite) may actually be helpful to beginners.

To put it differently, the alternative to passwordless root, as I see it, would be restricted but still passwordless root, just accessed through qvm-run explicitly.

Everyone has a different threat model, if yours is to have a root password inside your qubes then do so, what’s stopping you from doing it on your system without making it the default for everyone?

The question is not what is stopping me from customizing things. As explained in the OP, I have read many times the answers which explain “you can disable/change/customize/harden it, etc.” That is clear. I am not discussing choice and I am not saying the current default is wrong (or right).

What I am trying to understand here is the logic of the security experts who obviously know much more than me, as I may be on a wrong track. Peri-phrased for clarity:

What is the logic of deliberately reducing security for convenience which, as shown, seems unnecessary (as it already exists even without passwordless sudo)?

Why is all that justified with, as it seems, contradictory reasons?

3 Likes
14

I always considered “passwordless root” inside qubes a weird part of QubesOS. It is certainly convenient. But when considering the security of the system, it strikes me as an odd choice. Even odd’er, is how QubesOS maintainers and the “old-guard” in the forum, justify that decision. Whenever a newcomer questions this choice, he is immediately referred to “WTF document” written by the now-mythic figure of Joanna, and the questioner is either ignored, or hushed into “reading into the WTF document better”. From my time reading the QubesOS docs, reading this forum (3 years now) the justification of passwordless root doesn’t have much logical, coherent explanations behind it.

Contrary, questioning the passwordless root decision has many logical and coherent arguments. As are being raised in this thread:

I have always wondered, if an installed software modified the /rw/config/rc.local document as well. This is an anxiety provoking consideration for me, as anything written into that document gets executed with the root privileges upon the qube’s boot-up. And without asking for a sudo password for editing that file, it occurs to me that any script that I may run on one of my qubes can add new lines to that rc.local file, and execute them as a root user upon the qube boot-up. Isn’t this nuts? Or do I have a faulty understanding of how this works?

Another good reason for questioning the “passwordless root” decision.

I consider this as a good warning.

I agree.

Wouldn’t setup a root password “per-template”? I currently have debian-12-xfce, whonix-gateway-17 and whonix-workstation-17 templates. So, in this case, wouldn’t I setup only 3 root accounts, and thus assign 3 root passwords upon my installing of QubesOS? This doesn’t sound too much work, imo. Also, a user can re-use root passwords between templates, that is upto them, it is their consideration whether use a unique password or not.

Yeah. Quite interesting attack-vector to consider, imo.

Agreed.

Totally agreed.

Yeah. That would be cool workflow.

3 Likes
15

This has already been discussed
https://forum.qubes-os.org/t/wtf-passwordless-root-access-in-vms/3517

The tldr is that you can remove the package if you don’t want passwordless root.

Future development might add a feature to disable passwordless root, making it a user choice.
https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132

16

I read that thread just now, and I can’t see answers to this:

nor to this:

Within the thread you linked, there are the following responses that I got used to from reading this frorum for a while:

  1. conflating the topic with protecting Xen itself (while the topic in this thread is focused on protecting the / filesystem of the individual qubes from unauthorized exec/modifications).

  2. not explaining the logic behind adopting passwordless root in the context of individual qube security, and instead, starting from an argumentative position that it is taken as a given, and then justifying that decision as a “convenience point.” It is always the people questioning passwordless root that have to justify their objections (which they do), and not the peope who seem like OK with the existence of passwordless root.

  3. again, not explaining hte logic behind adopting passwordless but offering the off-handed remark “if you don’t like it, remove it.”

1 Like
17

This is major misconception and a flaw. You never keep those in places accessible to anyone, but in the vault. So, you can’t give something to someone when you don’t have it with you.

If you organize everything to it’s proper place, you’d never want to keep anything sensitive in the places the one you wouldn’t want to might access it. Homebanking password? Use single dispvm, one tab browser instance and no one out of the bank can access it. If can, the bank is hacked in the first place.

And this misconception could be easier to notice if people would be more familiar with Information Security, and not Information Technology Security.

It’s all in the proper self-organizing. Use dispVMs as often as possible, compartmentalize as much as possible, do not keep in online qubes anything you wouldn’t want to expose. It’s simple as that for me and it works great for me. And the ways to achieve this are all around here (for example various split-whatever guides).

1 Like
18

For those who access the forum via email, I don’t edit, but create another post to continue the thought from previous post.

… Or if that isn’t clear enough, this is my favorite banal analogy, which is the story of Information Security itself actually.

Take the real Bank. The Bank has it’s own vault. Consider Bank as Qubes OS. Both are reasonably secure, right? Consider Bank’s vault lock key as a Qubes disk encryption password. After that, you have the key for your compartment. Consider it as a password to log on to Qubes. So when you open it it’s all at your disposable. Do you need any extra key for the content because someone might brake in the Bank’s vault? Yep, you are right! It might help. But if the robber broke into the Bank and its vault, robber will for sure more easily break into sub-compartments of your compartment, right? But that is very rare, so you’re still reasonably secure.

But, bring anything from the compartment with you to the outer world (online qube), have a gun (password) with you, you are not safe anymore… So what you can do is to carefully and meticulously plan what and why you are taking something to the outer world.

Whatever happens, you can’t blame the Bank (Qubes) for it anymore.

Now, what are you talking about with this topic is basically it will be harder to enter the Bank’s vault (Qubes) via it’s sub-compartment (qubeVM with sudo), than via compartment itself (qubeVM without sudo). Pretty unlikely, but not virtually unfeasible (side channel attacks)… but nevertheless it looks funny in its senseless to me. The Bank stuff (Qubes OS devs) are more competent to security than me. All of that while the logic says it will be easier to do it from inside, through the vault’s (Qubes OS / dom0) wall/door.

If I don’t trust to that Bank’s security concept, I move to the other Bank. I don’t persuade them how to increase their security model. To suggest is OK, but to insist is pointless.

1 Like
19

This is a bad example. These things should be separated the Qubes way. That’s why you have a personal/work and a vault qube created by the installer, because the whole point of Qubes is to be able to compartmentalize to the maximum.

This depends on what the attacker’s goal is. They could just read/get the data, or spy on the user’s actions, both of which don’t require root access in any way. I still don’t see any reason to have root enabled in a qube, since everything in these examples can be accessed/collected at the user level.

To name a few examples from my head: user level autostart and malicious .desktop file

I said “extreme” in a global sense. I never said that having a hardened root account was in itself extreme.

Not everyone is a full Linux expert, especially with Qubes specific tools. Some users don’t want to touch a terminal, or at least not too much. They just want to open their applications, do what they want to do, and be done with it.

This is added complexity for basically nothing. With this method, you’re forcing users to use dom0 more than is necessary to install new software, for example.

What are the benefits of root restricted qubes? Can you give a list of benefits you can think of? Personally, I don’t see any to be honest. User data is accessible by the user himself. Anyone who has access to that user has access to the data. Whether root is there or not, the data can be compromised. The whole point of Qubes is to separate everything, if something is compromised in 1 qube, the others are still safe. You delete the compromised qube, create a new one, and you’re done.
It all comes to the same conclusion on my end. Advanced users can remove the root passwordless package and harden their qubes if they wish, just as one can replace Debian with Kicksecure for more security. It’s all personal choice, and again, all have different life, goal and threat models.

2 Likes
20

This is getting more and more difficult. I wonder why.

Keeping it as short as possible:

@renehoj

As explained in the OP, the very fact that the current thread exists confirms that those earlier discussions are not the answer. I think @tanky0u explained it quite well.

That said, I have read the GitHub comment you linked to. It sounds like the “WTF” page and that comment were written by two different people - the later definitely lacks the ostentatious style of the former. What caught my attention was:

  1. The obvious problem with using any kind of control mechanism for sudo, such as the one proposed in this ticket, is that once we open a root console in the VM, it still runs under the same Xorg that is being used by non-root apps in that VM and these other apps can launch a number of attacks against this already opened root console, such as keystroke injection to name the most obvious. […]

So, what we have is:

  • a “WTF” page saying:
# In Qubes VMs there is no point in isolating the root account from
# the user account.
  • the author of that text contemplating how to actually have the pointless thing:

[…] However, given that our goal is currently: not allowing attackers to get root in the VM, we need something else…

  1. Still it might be worthwhile to enable this sudo qrexec-authorization by default for our default template, after all. This is maybe because for many AppVMs there will never be a need for user to start root shell.
  • no actual solution (since 2017)
  • not even a revised logical explanation of the “WTF”
  • people passionately defending the “WTF” by repeating it, thus contradicting even author’s follow-up thoughts

@tanky0u

Just a little correction:

[…] the topic in this thread is focused on protecting the / filesystem of the individual qubes from unauthorized exec/modifications).

The topic of this thread is understanding the logic of the decision for passwordless root. Not defending it, not opposing it.

@tempmail

This is major misconception and a flaw.

It is an analogy, not equivalence, and not aimed to spark an off-topic debate. I hope you don’t mind.

@DVM

The example is fine. Just see the forest.

Typing a command does not require any expertise. It is another normal (not extreme) thing in Linux.

Some users don’t want to touch a terminal, or at least not too much.

But we are not comparing GUI workflow vs CLI workflow. The comparison is between sudo <command> and qvm-run --user root VMNAME command.

They just want to open their applications, do what they want to do, and be done with it.

How does restricted root impede that?

This is added complexity for basically nothing.

That “nothing” needs to be clarified, considering everything said so far.

With this method, you’re forcing users to use dom0 more than is necessary to install new software, for example.

If the real goal is to avoid typing and improve usability, why does the documentation instruct to type commands? Why not have the system auto add an additional “Install software” or “Start root terminal” shortcut for each template, just like we have “Settings”, etc? Passwordless root is not required for any of that.

What are the benefits of root restricted qubes? Can you give a list of benefits you can think of?

If I may point out, most kindly and respectfully, this is not a for and against argument and not a game of questions and counter-questions. @tanky0u’s 2) summarizes it quite well.

I would just like to have my questions answered. The basis for the questions is in the OP.

3 Likes