So you think that a real attacker (or any malware) will use su, or sudo to get root? 
What you would get with that prompt is you can ‘controll’ your own activity only, which leads to a false sense of security…
Did you read Automate vm sudo authorization setup · Issue #2695 · QubesOS/qubes-issues · GitHub and following comments? From my interpretation of it…
Joanna, founder of Qubes got convinced that it is a good idea:
Automate vm sudo authorization setup · Issue #2695 · QubesOS/qubes-issues · GitHub
Solar Designer, security researcher is also convinced it helps.
@marmarek, Qubes lead developer wants to implement it. The ticket is still open. I am interpreting this as Qubes would be interested to get this interpreting. It would be done faster if contributions were provided.
This is so far an argument from authority but hopefully valid in this case. But then when I look at the actual arguments made in the ticket, it makes sense to me.
Non-root enforcement is a long standing standard security feature of Android and iPhone. This is only a prerequisite or supporting feature of other features on top of it. References what inspires my viewpoint:
- Whonix ™ Security Roadmap
- Mobile Operating System Comparison - Whonix
- YouTube: Honey, I Shrunk the Attack Surface – Adventures in Android Security Hardening
- PDF: Honey, I Shrunk the Attack Surface: Adventures in Android Security Hardening
(Non-root enforcement can be and is abused as user freedom restriction but if it’s a security feature or freedom restriction is a policy decision, not an inherent issue.)
1 Like
Well Joanna was clear (at least to me) that root isolation would serve to protect Xen.
While undoubtedly Xen is the most critical point of Qubes, whole idea is not about protecting Qubes. Otherwise tomorrow, hardening Whonix by Qubes developers (for example) could be also considered as “protecting Qubes”. And the day after, hardening Windows by themselves again.
As I see it, it should be Xen and other distro developers to protect their OSs.
As Joanna wrote too, “most, or perhaps all of the XSAs that affected Qubes required root in the VM”.
What this could tell us is that for the one who plans to attack Xen, he/she first has to realize how to attack and gain root. And the one who is able to attack Xen is for sure able to gain root.
I’m not advocating either option, I’m just noticing. Maybe it’s better to spare energy and resources for further Qubes OS developing itself.
1 Like
Told ya! But most of the people here told me nah, the passwordless root is fine.
2 Likes
well lets think about solution , how about a policy that asks if you want to do SUDO in a certain VM?
I think you forgot to add “/s”.
If you were being serious then I think you should reread the thread,
since you seem to have missed key points.
Passwordless root is a convenience, and part of a trade off between
usability and security.
Attacks on Xen may require root. The point is that someone who has a
Xen exploit will undoubtedly have a root escalation.
I remember Joanna’s comment, and I have reread it since. I think it’s a
misinterpretation to think that she changed her mind. That comment is
obviously her thinking through the options, not reaching conclusions.
Some years ago, there was a thread on this subject - Flogging a Dead
Horse. I don’t think the debate has moved on since.
If you don’t like passwordless root, remove that package. That’s all. Why
people get so exercised about the issue is beyond me.
When I comment in the Forum or in the mailing lists I speak for myself.
4 Likes
that’s what is recommended instead.
1 Like