Qubes sudo / su / root Hardening - Development Discussion

Patrick · January 24, 2025, 1:20pm

What is it that the user can mess up?

“If you can do it in Tails without leaking your IP, it should be possible in Whonix Gateway.” → That would also include running Tor Browser, Firefox. Running these in Tails is functional and doesn’t automatically leak IP. This isn’t functional in Whonix (and doesn’t leak IP either).

But the use case for Whonix-Gateway is different from the use case for Tails.

Whonix instead has a design where we can say:
“If you can do it in Tails without leaking your IP, it should be possible in Whonix-Workstation.”

Whonix uses a Whonix-Gateway / Whonix-Workstation split design to allow for greater security and flexibility.

The feature you’re suggesting goes into the walled garden direction. The following is unrelated from privilege escalation tools (sudo etc) hardening: A feature request could be titled:

Whonix-Gateway account user should not have access to GETINFO address Tor control protocol command / circuit information by default

Unrelated to privilege escalation tools because as configured currently account user can access the Tor control protocol.

Implementation of such a feature request would possible in theory. We’d have to break most Tor Controllers such as Nyx and Onion Circuits by default or write complex onion-grater: a Tor Control Port Filter Proxy profiles. (Not worth the development effort, because the Tor control protocol will likely not be implemented in Arti, and things will be different there, yet to be determined.) (related: Keep an eye on Arti (Tor))

The Whonix design is at time of writing:

In Whonix-Workstation, the user can safely run applications without IP leaks.
In Whonix-Gateway, the user can safely configure Tor and use Tor controllers.

The feature we don’t have is a feature often used in corporate context, “distrust the human”, “protect a human victim of Social Engineering and (Spear) Phishing from shooting their own feet by following malicious advice”.

Therefore, I consider this out-of-scope for this ticket.

Due to this git commit (source code modification), no manual user modification will be required to avoid getting package qubes-core-agent-passwordless-root accidentally uninstalled during sudo apt autoremove.

No special instructions neccessarily required.

Migrating existing installations to user-sysmaint split can be done as per user documentation.

sysmaint - System Maintenance User links to sysmaint - System Maintenance User which has a chapter Installation.

Related: user-sysmaint-split - Whonix-Workstation versus Whonix-Gateway - Default Installation Status Differences

Patrick · January 24, 2025, 3:05pm

Patrick · February 4, 2025, 9:22am

github.com/QubesOS/qubes-issues

Polish support for booting qubes with custom kernel command line parameters (useful for Kicksecure and Whonix user-sysmaint-split)

opened 11:19PM - 31 Jan 25 UTC

ArrayBolt3

C: other P: default

### The problem you're addressing (if any) (This is somewhat of a followup to a… conversation I had with Demi and Marek in the Qubes OS Matrix room.) Currently, Qubes OS allows booting a Qube with special kernel command line parameters by using a special cli-only feature (sadly I can't remember the name of the tool used for this). If you don't do this, each qube is simply booted with some default command-line parameters, which are sufficient to allow the VM to boot and be usable. Thus far, this has been good enough, since each OS booted in Qubes generally doesn't have multiple boot modes that need to be supported. With the introduction of the [user-sysmaint-split](https://github.com/kicksecure/user-sysmaint-split) feature into Kicksecure and Whonix, things have changed somewhat. As a form of defense-in-depth on top of the security Qubes and Kicksecure already provide, Kicksecure will soon offer a package (really a set of packages) that will allow separating user and root responsibilities much more strongly than usually done. The current implementation uses file permissions on the `sudo` and `pkexec` executables that makes them only able to be run by a special `sysmaint` user, which is locked by default and cannot be signed into normally. This makes `sudo` and `pkexec` completely unable to be run during a normal user session, greatly reducing the risk of a root compromise. To gain access to the `sysmaint` account, the user must physically reboot the machine and select "PERSISTENT mode SYSMAINT" from the list of boot options - doing so triggers a systemd unit that unlocks and automatically logs into the sysmaint account. For added security, most if not all non-essential services are suppressed while booted into sysmaint mode, and a very minimal desktop named [sysmaint-panel](https://github.com/kicksecure/sysmaint-panel) is provided to discourage the user from launching potentially dangerous applications like Firefox while in this mode. Users can run privileged commands even when not booted into sysmaint mode through an SUID-less privilege escalation framework called [privleap](https://github.com/Kicksecure/privleap). This is all well and good, but right now this only works on physical hardware and traditional virtual machines (virt-manager, VirtualBox), because it requires the user to be able to boot into "sysmaint mode", which requires access to a GRUB console. Qubes VMs don't usually even use GRUB (since they share the dom0 kernel which is directly booted by Xen), and even when they do for some reason, you don't get access to the console during bootup unless you're using an HVM. This puts Qubes OS users in a bit of a sticky spot if they want to take advantage of the features offered by user-sysmaint-split. In UX terms, basically the end result is that `sudo` and `pkexec` become permanently unusable, and to get root access the user has to open up a root console either via `qvm-run` (which is dangerous because of X11) or via the "Open console in qube" feature of Qube Manager (which is secure and neat but also slow and somewhat difficult to use). Most of the "nice bits" of user-sysmaint-split are not accessible. In addition, Kicksecure templates will *also* be basically "locked down" by this, making it tricky to make changes or install software in the templates without resorting to one of the above solutions. Only AppVMs really need `sudo` and `pkexec` locked down, ideally a Kicksecure template should have full root access out of the box. Last but not least, Qubes OS only supports specifying custom kernel parameters for a qube if that qube shares dom0's kernel. If you use a VM-internal kernel, you can't set the kernel parameters because those are hardcoded into a GRUB config file within the qube. This is a problem since Kicksecure has some interest in using qube-internal kernels by default, and obviously users may want to use custom kernels or the like without losing the ability to control (or even use) user-sysmaint-split. ### The solution you'd like The solution I have in mind here isn't really one solution, but rather a set of them that fixes all of the paper cuts here: * Templates should be able to specify auxiliary kernel parameters that Qubes OS should use when booting them and AppVMs based on them. Each template should be able to specify more than one set of kernel parameters, one per boot mode it supports. * These boot modes should somehow be exposed to the end user. How exactly this should look I'm unclear on - an easy solution would be to provide a drop-down in Qube Manager's settings window that would allow selecting the boot mode the VM should use on next bootup. A potentially more usable solution would be to integrate the boot modes into the application menu somehow, but this could overcomplicate the user interface and might also be a massive pain to implement. * Templates should be able to specify the default boot mode for themselves and the default boot mode for derived AppVMs separately. This way the Kicksecure template could be set up so that it would boot in sysmaint mode by default, while AppVMs would be booted in user mode by default. This would allow the Kicksecure template to be used in an intuitive fashion similar to most existing templates. * There should be some way to boot a VM with dom0-specified kernel parameters *even if* you're booting using a qube-internal kernel. Demi, Marek, and I had a pretty long discussion about how this could be done, ultimately it seems that pvgrub is the best tool to use for this, but will need some extra features for it to work. * In a perfect world, the user should be able to define their own boot modes. That would make this rather complex suite of features be useful for much more than just Kicksecure and Whonix. None of this is set in stone, I'm definitely open to alternate ways of implementing things that would be easier. This is obviously a very large list of features, which I intend to contribute or at least help contribute. ### The value to a user and who that user might be user-sysmaint-split will work really, really nicely in Qubes OS. Additionally, with the ability to specify auxiliary kernel parameters in templates, Kicksecure and Whonix could use the extensive hardening parameters they use on the desktop within Qubes as well. Users who need or want to tweak their kernels and kernel config will also have much more freedom to do so, which could benefit Qubes OS devs as well as highly advanced users. ### Completion criteria checklist _No response_