Would it be more secure to not install ‘passwordless-root’ so in case a Qube get’s hacked, the attacker won’t be able to get root access?
Of course the drawback is that whenever we want to install something, we have to type in dom0
qvm-run -u root [template] xterm
In other words: what’s more secure… have passwordless-root installed or not?
Thanks.
I am new to Qubes, but what I have learned is, and it sounds ultimately logical, that once the hacker is in dom0, anything else doesn’t matter. The one who can get to dom0 probably can do much more than gaining root access in it.
Thank you @enmus
I’m not talking about dom0.
I’m talking about installing a minimal template to use for sys-net, sys-firewall, etc.
Let’s say I have:
internet ← sys-net ← sys-firewall0 ← sys-VPN ← sys-whonix ← sys-firewall2
Let’s say an attacker somehow is able to get through the TOR network and gains user-access at sys-firewall2. And the attacker wants to install something to monitor my activity. would not installing passwordless-root prevent that?
Of course, after rebooting sys-firewall2 is back in the original state (when made disposable).
not much, but since you are talking in appvm, it still better than having passwordless-root
I would like to know the same thing. All of the arguments I hear about passwordless root are about dom0 being compromised, but it’s unclear how domU doesn’t benefit from protecting malicious files from being installed in the root directory during an active session. Why not restrict that ability with domU password for root/sudo actions? It’s not just the current session that can potentially be compromised if the attacker makes the exploit persist with bind-dirs.
@apoawaisoChae, @enmus & @necker sometimes it really is a good idea to search a bit before posting a question. This particular topic has been discussed to death several times over…
It is highly unlikely that this thread will produce anything that the others haven’t yet.
In the end you have the choice to either use passwordless root (the default and consensus of the core team), not use it and use qvm-run -u root instead or configure a dom0 prompt for it. So if it makes you feel better, go for it.
If there is any aspect of it you feel hasn’t been addressed in the linked threads above … let’s have it.
This has been crawled over repeatedly in the mailing list and the Forum.
Will removing passwordless-sudo stop an attacker from getting root?
How does that protect the root directory (does this mean / or /root ?)
The benefit in most stock qubes (based on full templates) is minimal,
and outweighed by convenience for most ordinary users.
Of course you are free to remove the package if you choose, or to use a
dom0 prompt. The options are covered here
Minimal templates ship without the package by default. Those templates are aimed at
advanced users, so the lines of convenience are drawn differently.
imo the security benefit in not having the package is marginal there too.
Consider a GUIX overlay to a Debian template for your service VM’s. My Net-sys, Firewall-sys…etc all are passwordless and I remove both Nautilus and Firefox… You can do a lot of other things to make them secure. Use disposables… I can go on and on…
I think the “interactive” dom0 prompt for sudo makes a perfect balance of usability and security. YMMV.
Okay. Just to be clear, I’m not arguing otherwise. I simply don’t understand. And apparently I’m not the only one who doesn’t understand.
I read the links you provided. To be fair, several of them have no discussion or explanation. They consist of rejecting the question outright with the implication that the misunderstanding is the responsibility of those who don’t understand. I suppose, by definition, it is the problem of those who misunderstand. But perhaps it’s possible that something is missing in the explanations? I know… I know… but it’s been explained so many times. The thing is, these types of misunderstandings aren’t uncommon. I suspect that some sort of basic knowledge is being presumed as a given by those who understand the matter… but that basic knowledge is not understood by those who don’t ‘get it’. Or something similar to that.
In the above links (with actual discussion and attempts at explanation), there were several references to the same article by Rutkowska that was published years ago - which, as provocative as it was, obviously fell short in clarifying the matter for many users because the topic has been revisted so often since then.
So allow me to clarify what doesn’t make sense to me. Again, I’m not arguing that root passwords are more secure. I’m simply describing my (apparent mis)understanding.
Rutkowska wrote:
“all the user data is already accessible from the user account, so there is no direct benefit for the attacker if she could escalate to root”
I don’t understand this. How is everything already available? Obviously with no password needed in a VM, everything is available. But if there was a root password, the user would need it to access everything, no? The same user would also need the password to access the root directory in the template, no? What am I missing? Why is this true in a Qubes VM but not true in my other laptop running Debian?
Rutkowska wrote:
“there is… no benefit in trying to install some persistent rootkits, as the VM’s root filesystem modifications are lost upon each start of a VM.”
My understanding is that a user can “make any file persistent” with bind-dirs. Therefore, is it not possible to create the persistence necessary to have an exploit survive reboot? How is bind-dirs not a “backdoor to persistence” and a direct counterthreat to the security offered by template-based VMs?
I wonder if my confusion is primarily based on not understanding how most attacks occur. I always imagine something like a network attack or remote hacking of a shell or a situation where the hacker hits one final key, leans back and says “We’re in.” At that point, I imagine the hacker has access to the same shell that I do and therefore, a password is what will stop them from doing more damage. Of course, given the pushback surrounding this whole topic, something tells me my understanding is way oversimplified and I’ve been watching too many bad movies. In the end, if root passwords really are useless, I just want to have some sense of what I am defending myself against.
I guess that’s the gist of my misunderstanding. Any and all feedback is appreciated. I really don’t want to be an annoyance. But I am even more motivated to undertand and not just blindly agree with authorities on the matter. 
Thank you for your patience.
But what for? The root partition in AppVM is reset every reboot. There is no much point to modify it. In a TemplateVM, you should not run any programs, except the installation scripts.
Because Debian security relies in principle only on the separation of accounts, whereas Qubes security relies on the virtualization. You separate your workflows into security domains. You do not run an untrusted code in a trusted domain. Of course, you can create an additional obstacle for an attacker by creating the root password/prompt, but it will not bring much additional security and will bring a lot of inconvenience (depending on how much you use the root account of course). In this case you will be vulnerable to the privilege escalations, which are found in Linux every month. For the Qubes level of security, it’s like a security theater.
@necker on a “normal” (e.g. Debian) computer all the currently logged in users data is accessible. You might have multiple user to somehow segregate your data a bit. When an attacker is able to execute anything on such a computer, they already have access to all data that belongs to that user and they might escalate to root to achieve harder to detect persistence and gain access to other user accounts on that machine. So the root password is attempting to protect the system integrity as well as the integrity of other user accounts.
On Qubes, each qube has only one user and a read-only system partition. So when an attacker somehow gains execution inside a qube they already have all the user data stored in it and modifying the system part is pointless. They may use bind-dirs or simply the home dir to establish persistence, but that will simply prolong their access to that one qube with its data in it which they already have anyway.
The point here is that the root password inside such a qube doesn’t guard anything of value. Once a qube is compromised, the data it contains is compromised. Having root privileges does not buy any additional advantage. Only if you assume that there is a) a virtualization escape 0-day and b) this 0-day somehow requires root privileges could you make a weak case. But then, as Joanna pointed out … and attacker with access to a Xen VM escape 0-day will likely not be slowed down by having to find a root escalation exploit either.
I think the attack surface for potential VM escape is much higher if an attacker has local root. Well, LPE 0days are the cheapest breed, but why make this task even easier?
If I dedicate VM to banking only, no other site ever (login page as a home page), do I need extra hardening? If I do, please elaborate scenario.Who and how will attack me?
Well, if you are paranoid, you may think about stuff like FOXACID delivering exploits via your local ISP :))
And, how non-paswordless root will help me in that case?
Thanks for the replies. They actually do help. I think most of my confusion is due to a lack of understanding about how most systems are attacked. If I want to secure my home, I audit the property and stucture and draw upon my knowledge of how windows, doors, locks and surveillance systems are defeated. Without that knowledge, I would be more prone to ineffective or redundant countermeasures that don’t offer much additional security.
So it’s relatively clear why a root password doesn’t add significantly more protection to Qubes OS as a whole compared to the inconvenience it would create in maintaining the system with updates.
However, depending on the threat model, it does seem that there is still the potential for certain VMs to benefit from having a root password.
@sven wrote: “[an attacker] may use bind-dirs or simply the home dir to establish persistence, but that will simply prolong their access to that one qube with its data in it which they already have anyway.”]
In other words, an attacker can in fact compromise a VM with persistence across multiple reboots - even if the associated template or the rest of Qubes OS remains secure. That’s a good thing for Qubes OS as a whole - but what if that single VM is dedicated to managing digital assets that are worth millions or a secure drop that handles data that could result in great harm to someone if compromised?
While the addition of a root password for a domain is not in itself a guarantee of security, it does offer some additional protection that might be worth the additional inconvenience depending on the threat model.
tl;dr Arguements for passwordless root are the strongest when considering the default configuration for Qubes OS as a whole. However, a root password can still offer additional security for an individual VM if the threat model warrants the highest possible security for that domain - as a root password can potentially make it more difficult for an attacker to use bind-dirs to make an exploit persist across VM reboots.
(As always, please clarify if my current perspective is flawed… again, I’m not arguing. I’m clarifying my own understanding. 
)
And, how non-paswordless root will help me in that case?
assuming you’re responding to the FOXACID post, then nothing will help you at that point because that’s a three-letter-agency going after you, so it’s likely you’re already screwed
You wouldn’t keep those in a network connected qube. You would receive in a disposable, store in an offline qube and view/edit in a disposable offline qube.