Support Qubes that use doas rather than sudo

[ArrayBolt3]

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]

(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]

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.

• There is no need to ever remove it.
• If Qubes wishes to stay on sudo, Qubes can do so.
• And if Qubes hypothetically would port to doas, then users who wish/need to go back to sudo could simply do so too.

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: QubesOS/qubes-gui-daemon#149 (unrelated to this ticket)

[marmarek]

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:

• core-agent-linux: in qvm-connect-tcp (when handling ports below 1024)
• app-linux-input-proxy: starting/re-starting services when GUI starts (needs to stay, but doas support can probably be added)
• app-linux-usb-proxy (easy to avoid)
• video-companion: loading/unloading modules
• a lot of usage in tests - this I would ignore initially, and fix when noticing some failing tests

[adrelanos]

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.

True.

• Option A) We could workaround that using dummy-dependency (man page) or similar. -> Not preferable at all. Kinda horrible.
• Option B) Qubes could use (Debian packaging syntax) Depends: sudo | doas. This means the dependency would be fulfilled by either sudo or doas. According to this syntax, the first mentioned package becomes the default (in this example, that's sudo). But switching to doas would be allowed by apt-get. -> Better.
• Option C) Qubes has no longer any dependency on sudo. -> Ideal, but probably unrealistic?

[marmarek]

Option C) Qubes has no longer any dependency on sudo. -> Ideal, but probably unrealistic?

This actually might be not that hard, given quite small number of places it's used in.

[marmarek]

And then only the passwordless-root package would have Depends: sudo | doas