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
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
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
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
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
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
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:
-
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). -
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.
-
again, not explaining hte logic behind adopting passwordless but offering the off-handed remark “if you don’t like it, remove it.”
1 Like
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
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
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
This is getting more and more difficult. I wonder why.
Keeping it as short as possible:
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:
- 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…
- 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
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.
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.
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
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.
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
The documentation is a Community effort; It would be good to have GUI instructions there. Please help if you can.
Concerning GUI software installation:
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
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
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
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.
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:
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)
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
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