search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
542 stars 48 forks source link

Support Qubes that use doas rather than sudo #9599

Open ArrayBolt3 opened 12 hours ago

ArrayBolt3 commented 12 hours ago

How to file a helpful issue

The problem you're addressing (if any)

All official Qubes OS templates currently use sudo as a privilege escalation framework. This is mandatory, as Qubes OS ships some sudoers configuration files, which obviously won't be usable without sudo. Not all distros and users necessarily want to use sudo, however - it's big and complicated, thus potentially more vulnerable than a simpler privilege escalation framework.

Whonix in particular is currently looking into the possibility of porting over our existing sudoers configuration to doas, allowing us to replace sudo with doas. In the event we do attempt to migrate to doas, we do not want to have both sudo and doas installed in the Whonix VMs since that results in an increase of attack surface rather than a decrease. Since Qubes OS is a top-priority platform for Whonix, we cannot port from sudo to doas without there being doas configuration that replaces Qubes OS's existing sudoers config present within individual Qubes.

The solution you'd like

Ideally, there would be doas configuration snippets that would be able to replace the sudoers config shipped by Qubes OS packages. That way, any Qubes that used doas could simply use a qubes-doas-config package rather than whatever package ships the sudoers config. (If the sudoers config is currently bundled into a package, obviously it would have to be split out for this to work.) Additionally, any parts of Qubes OS that currently use sudo to elevate privileges within a Qube would have to be adjusted to use doas when appropriate, and documentation that instructs the user to use sudo would have to be adjusted to mention doas if that documentation was applicable to any official Qubes that used doas.

The value to a user, and who that user might be

Any users who are using a defense-in-depth strategy by disabling passwordless sudo within individual Qubes would potentially benefit from this. The only valid reason to disable passwordless sudo within a Qube is to make it harder for an attacker to attempt any attacks against Xen or dom0, by requiring them to bypass the in-Qube privilege restrictions first. It is theoretically easier to bypass the in-Qube restrictions if sudo is in use than if doas is in use, due to sudo's much larger size and much more powerful (and easy to mess up with) configuration file format. In contrast, doas is many times smaller than sudo, and features a much less powerful configuration file format that is harder to make mistakes with. Thus for users who are bothering with disabling passwordless sudo, using doas in place of sudo in at least some Qubes should result in an even harder-to-breach first line of defense.

For obvious reasons, users who are leaving passwordless sudo enabled on all of their Qubes will not see any significant security benefit from this change.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

ArrayBolt3 commented 12 hours ago

(As a followup, if Qubes OS is receptive to the idea of supporting the use of doas in Qubes that go out of their way to support it, Whonix is interested in contributing the code and documentation needed to implement this.)

adrelanos commented 6 hours ago

I think instead of inventing a dedicated qubes-doas-config package, we could simply put the doas configuration file into the same package.

For example the qubes-core-agent package is currently shipping sudoers.d configuration snippet file /etc/sudoers.d/qt_x11_no_mitshm.

For doas support, above confirmation file could remain existing as is.

What could be contributed here is adding an additional file to the qubes-core-agent package. The doas configuration snippet /etc/doas.d/qt_x11_no_mitshm. [1]

So Qubes has nothing to loose here. At worst, A few additional files which are ignored by sudo and everything else.

Is this feasible? Yes, very much so. [2]

[1] Adding /etc/doas.d support (doas configuration snippet d. drop-in folder) is already planned, pending implementation.

[2] If acceptable to Qubes, this would most likely by contributed by @ArrayBolt3, who recently landed a much more complicated source code contribution: https://github.com/QubesOS/qubes-gui-daemon/pull/149 (unrelated to this ticket)

marmarek commented 2 hours ago

If Qubes wishes to stay on sudo, Qubes can do so.

If I understand @ArrayBolt3 correctly, that's not necessarily the case. If the goal is to not have sudo installed at all, then no Qubes package can use sudo internally either. There aren't many such cases, but there are a few: