I’m not about to waddle into this conversation again–I just want to post a convenient way to enable sudo prompt.
For those who missed @anon22772651’s posts, what this does is it generates a dom0 prompt similar to what is presented when moving files between VMs. However, all the user needs to do is press ‘enter’, so the inconvenience is minimized.
Those who feel the need to should implement this, while those who don’t should just go on with their merry lives.
You don’t have to install vm-boot-protect to get sudo prompt–just run configure-sudo-prompt. The author, @Tasket is a recognized contributor (or on the Qubes Team) and his code is short and widely used, therefore scrutinized, and therefore trustworthy. His other scripts are well worth looking at too.
I’m not sure whether any of the above will work with 4.2. In fact, can anyone tell me whether vm-boot-protect and vm-boot-protect works with 4.2?
Merry Christmas and a (reasonably) secure new year to all.
For example, I have a few scripts that automatically install software and run it every time I run a qube. (Or every time I need it.) You can’t do that conveniently with a dom0 prompt. It saves me another template. And I frequently shutdown qubes from the command line without any prompts as well.
This is completely illogical, and I didn’t see anyone saying that except you.
VMs are isolated reasonably well. Root isolation doesn’t provide a reasonable security but adds friction. For most Qubes users, it’s expected that this additional friction is not worth it. I am one of such users. Using Qubes itself is already a huge jump in security. It’s sufficient as a first, big step. It’s already hard enough, so we have very few users.
As far as I understand, passwordless access in qubes now works only for convenience. You can use any option in your qubes:
Don’t install the package that provides passwordless access, and use qvm-run -u root namevm namecommand from dom0
Use dom0 hint
The standard passwordless option
It’s up to each individual to decide which option to use.
And in general, using sudo password or dom0 hint is not a panacea. Personally, I only use the dom0 hint for personal control and I am aware of the fact that if someone attacks me, the sudo password and dom0 hint will not save me (lucky if xen survives the attack, otherwise it’s game over). I think people should care more about organizing their qubes and separating important information. You probably wouldn’t run untested scripts in appvm where bank data is stored, etc.
I’d like to summarize by saying that qubes developers are aware of many security issues and are working on them, but they don’t have infinite resources to meet all the requests for system enhancements. It all takes their own time.
For example, I have a few scripts that automatically install software and run it every time I run a qube.
If something is automatic, you should not need to do anything additional (neither with sudo, nor without). That is zero burden to usability.
And I frequently shutdown qubes from the command line without any prompts as well.
Even if we assume that typing commands is a usability feature at all, qvm-shutdown from dom0 is just the same and requires zero passwords.
This is completely illogical, and I didn’t see anyone saying that except you.
Post 21 (+ various additional implications I am not going to analyze):
an isolated system that can’t harm anything else around it
VMs are isolated reasonably well. Root isolation doesn’t provide a reasonable security but adds friction.
Argue with Joanna on GitHub, not with me. She wants to re-enable restricted root. I am just looking for clarity.
For most Qubes users, it’s expected that this additional friction is not worth it.
It is not expected. Nobody expects passwordless root by default on a *nix system, otherwise there would be no “WTF… are you crazy”. It is made expected through and because of the “WTF”. So, only established and educated users expect it. That’s why all the arguments about “usability”, and “for beginners” make no sense.
It’s up to each individual to decide which option to use.
The community effort (aka documentation) does not explain in which cases one should use one or the other and why. It just says “WTF” and (almost) everyone repeats “WTF”, attacking those who dare to ask about it. It’s like an indirect veto on the topic served with a libertarian “but you are free to do what you want” (without necessarily knowing why and without talking about it who are simply comfortable with the default).
I am guessing adding those package installation commands to /rw/config/rc.local doesn’t satisfy you?
I don’t think @qubist disputes this, neither do I. The problem is trying to understand the logical reasoning behind having passwordless-root as the default mode of operation inside individual qubes.
I agree with the line of reasoning here. EDIT: I only agree up to the last sentence. I think the last sentence makes the error in assuming that only beginners are linux user beginners. Many Windows users who come into QubesOS wouldn’t expect a password entry for doing admin actions.
After this many posts, and from previous discussions, I am inclined towards accepting the passwordless-root decision as an anachronistic element of QubesOS. It’s always been like this, so no point in asking why it is like this. If you don’t like it, you can of course change it. But I am at the point that I believe nobody is able to propose a logical, coherent explanation that went into saying “let’s have passwordless root anyways” back in the old days of QubesOS. Probably it made the early developers’ and maintainers’ work easier, and it stuck with the users, as well.
If you have malware on your computer that can read/write your home directory, I think sudo without password is the least of your problems. You can go deeper into this topic, talk about X isolation, etc. There are many options to get around the sudo password to whoever is performing the attack. Focus more on splitting work into different qube, run dangerous and unverified documents in disposableVM, everyone will benefit.
As for the documentation, it is outdated in some places, not clear (illogical) in some places. Most of the documentation is the work of the community, if you are an expert in some area that will help those who use qubes, you can make a request to add or update the documentation.
I think the last sentence makes the error in assuming that only beginners are linux user beginners.
To me a beginner is one who begins using computers. Otherwise one is already experienced (more or less).
However, since neither beginner or advanced user (used also in docs) have clear definitions, they are pretty much abstractions and subject to misunderstanding. In the context of the current thread: WTF is an advanced user? How does one become that? Is a beginner supposed to edit the “community effort” in order to find out? Vague stuff.
There are no flashing red lights and big signs saying “You have malware in this qube”. Proceed from there.
I don’t see why the right way to work securely should be to deliberately disable all in-qube restrictions and trash qubes all the time. We distrust the infrastructure, the hardware, even the distro packages (which touch even offline qubes and even super-mini-micro-nano-templates) and don’t want to fool ourselves that anything is secure. This is a vicious circle. If we follow that line - let’s trash computers too.
Confidentiality is your ebank password in a vault (or split-gpg) and account balance not available or disclosed to unauthorized individuals, entities, or processes, which is achieved by Qubes’ dispvm single browser tab instance so it is available only to authorized entity, Bank and to you.
Security is not a tool. It’s a process. Root has nothing to do with this.
Prior to Qubes, Windows was the only OS I had even limited experience with. My hate for Microsoft brought me here, and I jumped straight from Windows to Qubes. I have had to learn some things along the way, but the OS has been completely usable for me from the start.
I don’t know enough about the subject of passwordless root to say whether I prefer it over having one, but Qubes as installed works for my needs. I do appreciate the topic/thread, though.
Can you elaborate on your first paragraph, please? I’m trying to decide where I come down on this issue and one weakpoint of the “pro-WTF” side seems to be the argumentation that “privilege escalation to root is easy, because X11 and many others”, but then these “others” usually don’t get mentioned. In fact, the already quoted comment by joanna talks mostly about how to deal with X11 isolation. If you go further down in that thread to this comment by @Demi you see that this issue is actually addressed now in newer QubesOS versions for those who are disciplined enough never to use sudo from a “normal” VM terminal.
However, since I’m not a security expert or even developer, I’d love a breakdown of other (non-X11) ways to easily (!) escalate to root (in a Qubes VM setting with apparmor/SELinux enabled, passwordless sudo disabled and where one never uses sudo in a regular VM terminal and always opens files and links in disposables).
So far it seems to me that QubesOS actually strengthens root protection (if passwordless sudo is removed and the user cooperates and always uses qvm-console-dispvm or the admin.vm.Console service), which it seems is a good argument for regarding root protection as a meaningful additional barrier (the main barrier being Xen isolation).
not revive this thread but I found it an interesting read. I’ve been using Qubes for about 2 months now, and while the argument on pass-wordless root is above my head (one ill likely disable after reading as I prefer more than less). I would agree with the quoted statement that as a beginner I find the documentation lacking and was also confused by it being a community effort. Of the things as a developer I wouldn’t want a community to control official documentation (beyond customization guides) is one of them. “community” documentation does not quite = “official” to me. There’s not even that many official documents on the docs page compared to for example a “help” document tree that would appear in Windows, so I don’t fully understand why the official team doesn’t maintain these as they inherently have the best understanding of the project. I too found it not the most satisfactory answer that the documents may be wrong but hey you can update them yourself…which isn’t exactly awesome when as a beginner you need the document to understand it in the first place so how do I possibly update it. Which leads you searching far corners of this forum or worse the rest of the internet and hoping the answers you found apply within Qubes specific structure. I’ve found many guides particularly on YouTube which have terrible information (like one guy installing a ton of stuff in Dom0) and considering the official documents may not be correct you cant blame people for following someone else guide (you don’t know what you don’t know) and they likely move about their day unknowing they compromised their security, accurate and maintained official documentation would combat this. Seems like it puts a lot on the community to investigate out solutions and then document them and also keep them relevant which likely hasn’t been the most successful approach as many of the documents are 3+ years old without update. It sounds like they are working on making it better from a previous post discussion of mine which is awesome but I certainly understand where you are coming form with this statement.
Sorry to bump this thread, but some additional things that sudo authentication would give us is better privacy in Whonix. We can restrict hardware identifiers with hide-hardware-info.service, thus making it harder to identify what devices are connected to a qube, and hiding cpuinfo, etc.
That’s not necessarily a security feature, but random software cannot know what CPU you are using, for example.
Additionally, if any form of code execution could take place between the Whonix-Workstation and Whonix-Gateway, it could freely connect to the clearnet which would otherwise would require root on KVM, VirtualBox and other platforms. Perhaps unlikely to happen though?
Finally, I want to quote a former Whonix contributor.
Why give the application even the opportunity to attempt to attack the hypervisor?
Personally I have opted to only using minimal templates, which I don’t have passwordless root installed in.
(I booked-marked this thread to follow “put a password in front of sudo” instructions soon in hopes to make the password work, but I wish the Qubes team would just further isolate it by giving an easy click GUI setup option so to not only force a password onto sudo everywhere but to also have “multi user” ability on one desktop so to have less permissions and even no permissions and then have the admin administrate from a whole other user login of the entire PC not merely from just another qube or dom0 but dom0 in a whole different login on the same partition. I mean if they are doing a remote admin for Qubes then why not do a local admin for Qubes as it is less of a security risk than admin-ing remotely anyway)
This thread should be a “must read” for everyone who intends to install QubesOS.
The lack of up-to-date documentation, combined with the false “this has been discussed and settled before” rhetoric, are chilling and off-putting. Way to go!
You cant stop yourself, can you Barto?
It’s untrue there’s any “false rhetoric” here.
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.
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:
Of course, there may be particular cases where an alternative may be
the default. There’s nothing stopping Whonix from requiring sudo
authentication if the project wishes.
As a default, to provide user convenience, Qubes ships with passwordless
root. Users who dont want it can remove it - this is fully documented,
and a link is included to the community guide on using a dom0 prompt.
Currently the devs do not think that removing passwordless root will
provide any significant increase in security in the context of Qubes.
As to the lack of up-to-date documentation, it’s true that we’re lagging
behind. We could make progress if more users updated the existing
documentation - This can be done on GitHub,
but I’m happy for people to email or PM me, if they prefer.
As we repeatedly say, the documentation is a community effort, and is a
good place for any one to contribute to the project.
… and as a user who dislikes using CLI, all I ask is why can’t this be a “setting” inside the GUI to toggle “on” and “off” for global and/or on specific qube VMs
That way any user of any level can opt-in or opt-out of passwordless sudo without having to guess if they input copied and pasted CLI correctly