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
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
I use passwordless sudo in dom0. DomUs create a prompt in Dom0 asking for permission to run as root.
No password, simply hit enter or cancel.
2 Likes
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
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
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
That sounds like valid reasoning because most things in human life work that way. If someone can run a marathon, they can certainly run a shorter distance.
But with security vulnerabilities, having knowledge of a way to escape a VM does not automatically mean knowledge of a way to escalate to root. Someone could come across a VM escape by chance, or a specific exploit could be leaked.
Every vulnerability requires time to find. Forcing a hypothetical adversary to find a root escalation in addition to a VM escape makes it more expensive for them to attack me. Fundamentally, this is how all security works: every system is vulnerable, but by making it expensive to launch an attack we minimize the number of attacks that are actually launched. Every layer increases the expense and so provides some value, even if it is not as expensive as a different layer which must also be breached. Of course, adding the layer must also be weighed against the costs (convenience, availability, etc) so it makes sense that different people use different sets of layers.
3 Likes
Someone with a transient exploit would just wait until they have the root exploit, which wouldn’t be long, if they need a root exploit at all.
They wouldn’t start an advanced exploit chain just to realize halfway through they didn’t have the root exploit, which would allow you to gain knowledge about the transient exploit.
Not using passwordless root might buy you a little time, which is somewhat pointless because it does absolutely nothing when the attack happens.
so we could better understand why it was more important than not, to have password.
It is not, and that is not the question at all.
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?
No.
Simple adding a line to correspondent RPC policy, resolves this, for example
Thanks.
I too will not participate anymore because it looks it is obvious no reasoning can change your mind.
There is nothing to change. But I am obviously unable to convey it to you.
1 Like
These exploits are irrelevant for the Qubes versions above 3.2. They did not allow to escape VT-d, and they were the reason Qubes switched to the hardware virtuzalization.
2 Likes
This is true. In other words, as I said above, removing the passwordless root would be a reasonable defense in depth. However, its existence by default indicates to new users that its security is much, much lower than the hardware virtualization, which is the distinctive feature of Qubes. Whenever possible, do not seriously and solely rely on root, if you have Qubes.
I don’t understand this discussion. To me, it seems we all agree that a root password would add a little bit more security. Joanna also agrees.
See also:
and
1 Like
How so? Whonix already has no passwordless root. All other AppVMs do not protect your privacy by default, so your example is irrelevant in the context of this discussion.
However, its existence by default indicates to new users that its security is much, much lower than the hardware virtualization, which is the distinctive feature of Qubes. Whenever possible, do not seriously and solely rely on root, if you have Qubes.
Hardware isolation is surely much stronger than software one. Both are not necessarily self-exclusive though. One paradox here (as I shared in another thread) is that we do have the possibility for additional hardware isolation (4 protection rings on x86), yet in Linux we use only 2 (kernel and user) inside the qube. Xen adds one more but 1 unused still remains. I wonder if that has been proposed or discussed anywhere. But it’s off-topic.
I don’t understand this discussion. To me, it seems we all agree that a root password would add a little bit more security. Joanna also agrees.
She didn’t say anything about a little bit. What I read is that she obviously no longer maintains the firm position outlined in the “WTF” document (thus making it old and needing an update) but wants to have restricted root, just done properly, so that it is strong enough.
Personally, I neither agree or disagree. That is the whole point of the current thread - to clarify the logic because the reasoning in the “WTF” is somewhat unsound. It seems to me a good idea someone to update that page, so that it explains better. As it seems, currently it has created more of a religious belief (Joanna said so. Period. Don’t question it), rather than showing the whole picture (including that same Joanna saying something else later).
4 Likes
Anonymity != privacy != security
They are often related but not equivalent. There are cases in which they may be completely unrelated.
Whonix is focused on anonymity. My example is relevant because if system logs (and other system components) contain additional system-specific information (as they usually do) that may facilitate deanonymization. Having an additional border may make this more difficult.
1 Like
You should give a link to that if you want this discussion to be on point (I tried but couldn’t find anything by now).
Isn’t this Issue relevant here? I’m no expert but to me the answer looks the same: anonymity and privacy are only provided by Whonix.
Another relevant discussion:
Each time when I see something is lacking in the documentation and ask about it, someone repeats that it is a community effort (you did it twice in the current thread), suggesting that it is me who has the write the documentation. IOW, I am supposed to somehow already know what I am trying to learn. 
You should give a link to that if you want this discussion to be on point (I tried but couldn’t find anything by now).
You shared the link yourself. It was shared earlier in the current thread too and commented on.
Isn’t this Issue relevant here?
TLDR. From the title it seems a different issue (different deanonimization vector).
I’m no expert but to me the answer looks the same: anonymity and privacy are only provided by Whonix.
Run lscpu in a Whonix VM and you will see if Whonix knows what your CPU is.
As for the potential case I am talking about, again in a Whonix VM run:
journalctl -k
and compare it to:
sudo journalctl -k
1 Like
Hi qubist,
I might be misunderstanding you so feel free to correct me. But it sounds like what you’re trying to do is figure out what the “right answer” is in terms of choosing to enable passwordless root or not. The problem is that when it comes to security, there is no “right answer”. There are tradeoffs which increase security at some cost, usually availability or convenience. There are good reasons to disable passwordless root if you the possibility of someone obtaining a vm escape is part of your threat model. However, this comes with usability drawbacks and for many people the increase to security is not worth this drawback. For example, if someone has an exploit this valuable they are likely not going to use it in order to drain the bank account of a random person. Instead, they would use it to attack the infrastructure of a bank, or the developers who maintain the software that banks rely on. So for a lot of people passwordless root makes sense.
People who find their way to this forum are naturally going to be more concerned about a wider variety of threats than the average person, for whatever reason. So it makes sense that there would be a disproportionately large number of people on this forum who decide to disable passwordless root. There is nothing wrong with that. It also makes sense that the vast majority of people would want passwordless root. There is also nothing wrong with that.
From the contents of this thread, it seems like you understand the security benefits of disabling passwordless root. Whether or not these are with the usability costs is a judgement each person has to make for themself.
5 Likes
I still don’t understand what “usability drawback” a password-entry for sudo command brings.
I might be misunderstanding you so feel free to correct me. But it sounds like what you’re trying to do is figure out what the “right answer” is in terms of choosing to enable passwordless root or not.
Not really. As I said, I am neither against, nor for either of the two alternatives. What I am trying to figure is the actual reasoning behind the “WTF”, as the superficial text it provides is not it. I say superficial, because I have read a lot of amazingly deep stuff by Joanna, based on which I simply refuse to believe that this is the actual and complete reasoning. Her later comments on GitHub also confirm that there is more to it.
The simplification “VMs are perfectly isolated, so root needs no password” seems easily accepted by the majority as “the right answer”. Parallel to that, the same people repeat the other mantra - that there is no perfect security. So, they both assume that VMs are perfectly isolated and that there is no perfect security. I wonder how many have actually dug deeper into that, as DMA attacks are actually possible even with IOMMU (contains also links to Joanna’s papers on the subject, showing that those are possible). And that this is just one thing, found through quick search, not a complete study of the subject.
Another fact, worth considering IMO, is that nothing so far looks at the possibility of flaws in this whole “perfect isolation” which may be discovered in near or far future. Side-channel CPU attacks, for example, were not a thing just a few years ago. They changed quite a lot the security considerations after appearing though. That is a different discussion though.
So, I hope you understand the source of my confusion, as well as the effect of the “WTF” on the community (which we see even in the current thread). I was hoping that someone with deeper expertise and understanding of the whole matter would be able to provide a more meaningful clarification (ideally, even update that doc). Then, anyone reading it would have a better basis to decide for oneself how and why to act considering case specifics, not merely be given “freedom to do what you want” (including to fool oneself).
The problem is that when it comes to security, there is no “right answer”.
The even bigger problem is that there are so many wrong, yet easily accepted, answers.
1 Like