sam
August 11, 2025, 5:11am
1
@arraybolt3 Hello!https://qubes-doc--1504.org.readthedocs.build/en/1504/developer/releases/4_3/release-notes.html#security-features
opened 10:20PM - 27 Apr 25 UTC
C: core
release notes
ux
P: default
targets-4.3
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
###… The problem you're addressing (if any)
Right now any boot modes advertised by a template will be visible for both that template and any AppVMs derived from it. This might not make sense for all boot modes - Kicksecure would like to implement an "unrestricted admin" boot mode that removes the user-sysmaint-split package during early boot to allow the user full `sudo` access for that boot only. This would take advantage of the fact that rebooting an AppVM resets most of its root filesystem to make this change temporary, so that users can switch between safe and unrestricted modes. This boot mode only makes sense for AppVMs, it would be detrimental for a Kicksecure template to be booted in this way.
### The solution you'd like
Add another boot mode qvm feature class, `boot-mode.restrict.(boot-mode-name)`, which can be set to either `AppVM` or `TemplateVM`. The boot mode will then be restricted to that VM type (i.e. if the feature is set to `AppVM`, that boot mode will only be available for AppVMs, not TemplateVMs).
This could potentially be made more flexible by allowing the feature to be set to a comma-separated list of the VM types the boot mode should be supported in (AppVM, TemplateVM, DispVM, RemoteVM, etc.), but I fear that might cause problems because of the presence of AppVM default boot modes. If a template sets a boot mode that isn't supported by DispVMs as the AppVM default boot mode, what should a DispVM based upon that template do? Thus why I believe this should only allow two restriction choices. "AppVM" in the context of this option really would only mean "anything other than a TemplateVM". Perhaps the wording should be adjusted accordingly, not sure.
The only problem I can see
### The value to a user and who that user might be
Less confusing in the user interface, users won't see boot modes that they shouldn't be using.
### Completion criteria checklist
(This section is for developer use only. Please do not modify it.)
opened 11:19PM - 31 Jan 25 UTC
closed 11:12PM - 26 Mar 25 UTC
C: other
release notes
P: default
targets-4.3
### 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_
1 Like
I was hopeful it would allow that, but unfortunately it doesn’t yet . Live mode requires using an in-VM kernel with Dracut, and boot modes are only supported when using a dom0-provided kernel right now. There is ongoing work to get in-VM kernel support for boot modes, but it requires a GRUB patch which I’m still working on getting upstreamed and integrated into Qubes OS.
4 Likes