[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Any security risk to disable sudo password prompt, when using KVM snapshots?

It looks like on Qubes-Whonix, there is no sudo password prompt. But for KVM, the user has to type the password, whenever she sudo some commands. I read the Qubes documentation titled “Passwordless root access in Qubes” (I can’t post links), and it looks to me that what’s the same between Qubes-Whonix and KVM Whonix is “all the user data is already accessible from the user account”. But for Qubes-Whonix, “the VM’s root filesystem modifications are lost upon each start of a VM”, and it’s not the case for KVM Whonix.

So I guess there are prompts in KVM Whonix, to prevent persistent malware being installed from a compromiesd user account? If however, I create and maintain “safe snapshots”, upon safe events like VM creation, and VM upgrade-nonroot, and revert to the latest safe snapshot after each use of the VM?

Compared to Qubes-Whonix, there will be even less persistence in this way, with the user’s home directory also not persistent. Does this mean it will then be safe to disable the sudo password prompt with user ALL=(ALL) NOPASSWD: ALL in /etc/sudoers? Or will it cause problems and run afoul with some of the Kicksecure or Whonix hardening, or some other things?

Now you can.

Posting Links for New Users

Moved form KVM to Support forums because this equally applies to Whonix for VirtualBox. Not only to Whonix for KVM.

It’s a complex technical question whether currently most if not all single-user human Linux desktop distributions are participating in security theater or if it already provides additional security under certain threat models.

The following wiki pages are about this topic but aren’t too clearly describing all of that yet either. Probably interesting pointers for further research nonetheless.

Also related…

In conclusion, when using iPhone/Android devices that still receive security updates, the iPhone/Android approach provides strong protection against malware, meaning those platforms are impacted much less than Windows or Linux desktops. [10] Despite the many downsides (Mobile Devices Backdoors in Most Phones Tablets Etc, Data Harvesting by Most Phones, …), the security model of popular mobile operating systems often affords better protection when attempting to prevent any malicious and unapproved party from establishing a foothold in their ecosystem. In the process, the user’s and the security community’s ability to audit and control what their devices are actually doing is severely diminished. Due to a Conflict of Interest this comes at the expense of transferring power from the user to the developers, user freedom restrictions, Tyrant Security, War on General Purpose Computing.

One thing however I can say with certainty. In the future when some of the things mentioned in above links (specifically Multiple Boot Modes for Better Security: an Implementation of Untrusted Root) gets implemented, then passwordless root should be avoided.

Help is welcome is improving these write-ups. Linux desktop distributions generally could certainly improve security, benefit more from user/root separation and that without user freedom restrictions but I don’t think there is great documentation of this issue or awareness.

Thank you for sharing the articles. I see the rationale now. So Whonix is leaving the sudo password prompt on, because there are defense mechanism for this topic, both in the present, and in the future (multiple boot modes). And in those scenarios, the user will need to type the password to install packages and so on. So if Whonix let the users to do those tasks without password now, it’s awkward to train them to type passwords again in the future.

But, if I disregard those defenses, and use the snapshot routine I mentioned at the top, will it be a valid mirror of what Qubes is currently doing, and be as secure as Qubes, at least on this topic?

It’s not well enough researched, documented. Therefore I cannot say.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]