It could be if someone writes it. But, as I’ve repeatedly said the devs
dont see this as providing any significant increase in security within
the context of Qubes. It might make you feel more secure, but I doubt
it makes any real difference to the security of your data. And that’s
what counts.
2 Likes
It sounds like you are implying that the known exploits against hypervisors have no need for sudo privileges
I am unfamiliar with the technical details, but I have heard of a couple hypervisor exploits that escape VMs and pose or have posed a risk to dom0
Are you implying it makes no difference whether a qube VM or all of Qubes (including dom0) has a passphrase enabled to gain SuDo privileges as those exploits had no use for SuDo access as the VM “escape” already provided escalation into ROOT privileges?
Because that is what it sounds like when I read what you said
Other than that, I am first and foremost concerned about my mom getting phished and so from an admin perspective I can better protect her as a less capable user while not micromanaging her activities by simply disabling SuDo even with just a passphrase on SuDo. As the Threat Model we are both under will not allow me to do so remotely, as I did see on the GIT a remote admin being worked on in Qubes but that is going to be useless for me as it benefits those hunting and attacking me and people I know more so than physical admining stuff on-site. In general this is hypocrisy as anything having remote admin privileges (currently deemed important to work on rather than local admin needs by such devs) will degrade Qubes security model.
2 Likes
I will waste another minute on this, because you continue to mislead and make fake claims: the Cloud analogy is simply wrong. The use-cases for Companies using Azure or AWS are totally different from the use-case of the potential QubesOS individual users.
Nobody in his/her sane mind will use AWS to store their crypto wallet. No whistleblower or human rights advocate will use Google Drive or Amazon S3.
Stop being so defensive please. The passwordless root may have been a mistake in 2013, continues to be one in 2024. The obstination for having this as a default and stopping non-technical users from removing the feature, are amazing.
2 Likes
Regarding convenience, it is possible to create a .desktop file in dom0 that lets you open a root terminal. All that is needed is to add -u root to the qvm-run command.
[Desktop Entry]
Type=Application
Name=anon-whonix: Xfce Terminal (Root)
GenericName=anon-whonix: Terminal Emulator (Root)
Exec=qvm-run -q -a -u root --service -- anon-whonix qubes.StartApp+xfce4-terminal
And then you can open it in the applications menu.
1 Like
I dont understand why this topic generates such heat - “continue to
mislead and make fake claims”, “hypocrisy” - this isnt the language we
expect here.
@barto - you’re missing the point - In the cloud analogy, it’s the cloud
providers who are equivalent to Qubes users, and they are content to
allow their users to have passwordless root. It hasnt proved to be the
cause of millions of exploited cloud machines.
Given the fact that experts in security are content with this
configuration, you may want to review your understanding of the threat
model.
There are many features of Qubes that require use of the CLI and some
degree of knowledge. The devs believe that for non-technical users the
recommended way to use Qubes is with passwordless root.
@Lace - you should read the announcement and details of remote admin and
you will see that it comes with major warnings. Please read background
before you make inflammatory remarks.
3 Likes
It is amazing that 3.5 months later people continue to discuss the off-topic pro and against passwordless root. This thread was never meant to be that. It was aimed to clarify the security logic of this whole thing.
This is an issue that has been discussed many times before - on GitHub,
in the mailing lists, and in various threads in the Forum. And the
“debate” never moves forward, because users run over the same ground
that’s been covered before.
Considering the actual question, I have not seen it discussed anywhere, otherwise I wouldn’t start this thread. Unfortunately, the “debate” you mention is a fact which happens somewhat mechanistically, burring the actual question.
Some years ago, I pointed out that the “WTF” response to passwordless root
seems strange to anyone who’s dealt with any of the major cloud
provisioners, where passwordless root is common:
The problem is not that it is strange but that it is inappropriate and non-informative - bombastic, partial, even cynical - definitely not suitable for technical documentation (not even a good tribute to the author who we all surely respect much). The very fact of these never ending “debates” with zero practical outcome confirms the confusion it results in.
As we repeatedly say, the documentation is a community effort, and is a
good place for any one to contribute to the project.
Maybe this repetition has to stop and be transformed into something that makes sense? Personally, when I read it for the first time, I got additionally confused - somehow the student is expected to write the book one is trying to learn from, like Baron Munchausen pulling up on his own hair. Community effort is good but only possible at a much later phase. Now, whenever I see the word documentation, I automatically expect to read “community effort” in a reply (just like when I read security, I expect someone to say “reasonable”). These magical words don’t do any favor to the community. They stimulate automatic thinking, i.e. not thinking but mechanical repetition.
5 Likes
That sounds scary if anything managed to reach dom0
@barto I have found at least 1 use case where a journalist may utilize QubesOS off-site remotely in a cloud (albeit not to store important stuff, but to open questionable files received). Check it out I made a question about it,
https://forum.qubes-os.org/t/qubeos-as-a-remote-cloud-virtual-thin-client/25287
… as I think it will be a safe way to not just access my compromised Google account(s) again but also open up 1 known malicious PDF which not only I need to keep as evidence but is also an important PDF I need to print as it is an LLC document (so I can report the case to other agencies and have the LLC shutdown and EIN officially ended — I currently cannot do this without re-infecting my system which I don’t have $ to trash more equipment but this method is a way to not have to have a burner or one use-case machine that will end up being thrown away which in my situation is needed as I have no $ currently)
I looked into above and beyond methods and found out that opening up a PDF in a disposable is NOT full proof:
— image description start —
Screenshot of the following source:
— image description end –
Which then lead me to my new idea of possibly utilizing a “Thin Client” once I read a so-calles “off-topic” reply that lead me to Authentic8
@qubist IMHO it is NOT “off topic” and besides this thread has it in its topic …
I am not arguing pro or against
As a user I am requesting a simplified toggle on and off so I don’t have to follow instructions you and others post for CLI
wow, I am not the one with attitude here some of yall are and it shows. I just want it in the GUI, why is this controversial to give users OPTIONS?
I felt this yes, if I could contribute I would and yall making me want to eventually learn this just to spite it all and do something like KickSecure since no one else seems to have a ready made package for this and the devs might never deem it as a priority
1 Like
If something manages to reach dom0 you would have bigger things to worry about.
2 Likes
I am getting tired of having to read this saying over and over across Qubes (it is in old threads)
I get it
The statement sometimes is not useful though and sometimes even feels like an excuse to not deal with stuff as if everyone should throw their hands up once dom0 is breached as say “you won you pawned me you own my system now” but that is not truly the end of the last stand as they still have to gain persistence too
2 Likes
I think that this is off-topic, so I’m going to stop here. But the entire system is accessible from dom0 with or without root. Persistence as a user is not hard to obtain. Now, let’s not continue this discussion here.
2 Likes
I found it!
Instead of being so vague to newbies with a one sentence statement slogan about dom0 breaches, and make such users become prone to defeatism rather than figuring out all the mitigation and counterattack methods against threats that may or may not break into dom0;
possibly citing this PDF will bring more clarity than the tired old lines of sounding so defeatist:
page 11 of this PDF
— image description —
screenshot of PDF page 11 go back to URL previously cited
— end of image description —
I think that this analogy is great, and should probably be included somewhere in the documentation if it’s not already. But I’d like to point out that the reason people are so opposed to this, is that we go out of our way to use a secure operating system, to then completely dismiss defense in depth. I have no doubt that Xen is going to protect my data, and this can very much be confirmed by looking at cloud providers where anyone can get a root box, yet they remain uncompromised.
Despite knowing that, many people still want more. I will continue using NoScript to browse the web, hurrying to install the latest patches, applying AppArmor profiles and locking down root. The inconvenience of that is insignificant compared to losing huge chunks of my CPU’s performance, not to mention the complete lack of hardware acceleration.
I believe that the rejection of the premise stems from this fact, we are already giving up so much to run a more secure operating system, so it’s jarring for many users to hear that they should suddenly neglect all best practices of secure computing and turn their device into a playground for arbitrary software to run as root in because it’s convenient.
I like to continue using my computer as I otherwise would, and if worst comes to worst, then at least I was running Qubes OS.
2 Likes
BTW: do you know of a document about vm security in QubesOS (maybe compared to type 2 virtualization) other than Lace already mentioned above (https://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf)?
I am asking, because it soon celebrates its 10th birthday…
2 Likes
— image description: screenshot of video cited bellow (it shows a fake SuDo login to gain the password when a user with SuDo privileges decides to log-in). END of description —
Short version:
SuDo passwords are indeed useless without anti-phishing mitigation at SuDo login.
This however creates a strong security argument FOR the use of Multi-User specifically within the context of QubesOS — as QubesOS is intended as a Workstation NOT as a Server (yet).
(*) see video cited bellow
Long winded version:
I now understand more in-depth as to why adding a password to SuDo can be useless if an attacker is skilled enough to bypass it without a mitigation safeguard to tell a user if they have been prompted by a fake login or not. However, this makes a strong argument why WORKSTATIONS such as Personal Computers (the current use-case for QubesOS btw) should implement multi-user so to allow SuDo Group separation; so that if an attacker were to escape from a VM they still would lack ROOT unless they had other tricks to REMOTELY bypass at REST disk partition of an admin account as the only sole SuDo Group privileged user on the Workstation (while it is not logged-in at all, therefore toggling between said user should be disabled by default IMHO).
Don’t take my newbie word for it, check out what this well versed techie Linux professional says in the video cited bellow.
Skip 6 minutes into video:
Yes. This is weird. I tired…
But instead Passwordless root access in qubes | Qubes OS has been appended in commit Update page on passwordless root. · QubesOS/qubes-doc@fdcb21e · GitHub meanwhile with:
The core of this statement continues to reflect the views of the Qubes developers.
I would hope that these can be enumerated and gotten under control one day. Seems a worthwhile development goal. Attempts into that direction:
- GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup
- Dev/VirusForget - Kicksecure
Advanced users, developers can help with that. It starts by describing the issue reasonably well to raise awareness, to enumerate all attack vectors and proposing solutions.
Other operating systems (Android?, iOS?, …?) don’t seem to have this issue. Why? Why is it an issue for Linux desktop distributions? What has to happen to fix this issue for Linux desktop distributions?
Perhaps a restricted shell (that actually works) that or safe-mode that doesn’t parse ~/.bashrc etc. And/or a desktop environment that has a safe-mode that doesn’t parse ~/.config/autostart etc. or at least has detailed documentation on all of the files/folders that might be vulnerable to persistent malware.
Even if subscribing to a passwordless sudo threat model / viewpoint, not logging in as root has reasons. Not security reasons.
This is for reasons of history, legacy. Even during the times of X11, root login was frowned upon.
- In result, some applications such as
katehave even hardcoded (non-configurable) code to outright refuse running as root. - At time of writing, when opening a Qubes root console (dom0:
qvm-run -u root vmname xfce4-terminal), it is not possible to start GUI applications by default. (Maybe fixable by somexhostcommands, but undocumented and non-trivial for most users.)
Since changing all applications that - maybe for the wrong reasons - refuse running as root is infeasible, under this threat model using a non-root user with passwordless sudo would still be better for usability reasons.
Related ticket:
A user to root local privilege escalation (LPE) exploit is out reach for many actors.
For example, there are many Android devices where users are suffering from Administrative Rights Refusal which have never been rooted despite large community interest. This also goes for set-top boxes, iPhones and similar devices.
It’s futile to argue that non-root enforcement cannot improve the security of the system (in case of Qubes, of an App Qube).
Non-root enforcement is the industry standard for Android [1], iOS and any locked down Linux based operating system.
In other words, root exploits are often unavailable for long periods of time for many actors.
Impossible to break? No. More complicated, more expensive? Yes.
This is also arguing kinda “we cannot prevent root local privilege escalation because the kernel is bad, therefore let’s be lazy and don’t even try to secure the user space”. Maybe the Linux kernel is horrible. But then then still, focus is required. Fixing 1 issue at a time. And sudo/permission hardening; making sudo available/unavailable inside a VM as a simple dom0 VM settings checkbox s within reach.
LPE is an issue but there are people working on improving the security of the kernel. They might fail or succeed. Or other people might even one day manage to provide a usable alternative kernel with no or less LPE issues.
We should disallow one issue (kernel LPE issues) to block progress on sudo/permission hardening.
There’s no need to elevate developers to god status. We’re humans. We make mistakes. We’re learning. Refer to post Automate vm sudo authorization setup · Issue #2695 · QubesOS/qubes-issues · GitHub.
This can be done using /rw/config/rc.local other mechanisms such as a systemd unit that runs a script which only does only perform actions based on the VM name.
I am also very interested in and working on finding these issues, reporting actionable tickets with the goal of getting these issues fixed, and developing Open Source code to fix these issues.
One excellent source for these issues is the infamous, multiple times referenced comment by Joanna (Automate vm sudo authorization setup · Issue #2695 · QubesOS/qubes-issues · GitHub). Or Solar Designer’s comment (Automate vm sudo authorization setup · Issue #2695 · QubesOS/qubes-issues · GitHub).
Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)
that has resulted in the creation of SUID Disabler and Permission Hardener, among many other discussions which I am working through, attempting to fully wrap my head around this issue. This is documented here:
I opened a new ticket just recently.
I think we’re getting close to describing all the issues, (We don’t know what we don’t know.)
And as for fixing these issues, we’re also making progress with that. (Except for kernel attack surface.)
See also:
2 Likes
Sorry, but I really don’t care about passwordless root. Because in my threat model, my online vms are exclusively dispvms, all of them are empty, carrying nothing important, and when they do it is because the online resource I’m accessing to needs it and should be aware of it, and almost all of them are single purpose instances… Accesing Qubes’ forum - single dispvm. Search engine, another dispvm, homebanking, another dispvm and so on…
A bit of initial discipline, and the routine becomes a miracle…
1 Like
Rationale for Protecting the Root Account
- Protect the virtualizer: It is harder to attack the virtualizer without root / kernel access.
Qubes - Strong Linux User Account Isolation - Motivation
Motivation of user/root isolation in Qubes? In the past, there have been Xen vulnerabilities that requires root access. (Actually a kernel module, but root has the permission to load kernel modules.)
All three vulnerabilities have the potential to enable a guest virtual machine to break out of the hypervisor isolation. However, in order to exploit this vulnerability, an attacker would need to be running code in kernel mode of one or more VMs on the system. Any system that allows untrusted users to run arbitrary kernels will be particularly vulnerable.
At that time, the inability to escalate to administrative (“root”) rights, thereby preventing the running of code in kernel mode by loading a kernel module, would have mitigated these vulnerabilities.