Replace sudo with doas

Development
21

Deleted.

2 Likes
22

OK, so to begin with, I was wrong about doas only allowing environment variables to be preserved on a per-command basis. (I.e., I thought you could only say "preserve vars X, Y, and Z for each command, and that you couldn’t say “preserve these environment variables regardless of what command I run”. This was due to me misreading OpenBSD’s doas.conf manpage (doas.conf(5) - OpenBSD manual pages). The Arch Wiki page for doas at doas - ArchWiki corrected my understanding here, the syntax to use for enabling an environment variable to be passed through on a per-user or per-group (rather than per-command) basis is apparently:

permit setenv { VAR1 VAR2 } :group

I’ll amend my original post to reflect this.

To follow up on my previous review of doas porting feasibility, I’ve taken a look at both Kicksecure and Whonix running under Qubes OS. Here are the results. Just like before, a checkmark means “looks like it can be ported” or “isn’t necessary”, while no checkmark means it’s likely to be problematic.

/etc/sudoers.d/qt_x11_no_mitshm

  • Specifies an environment variable to be preserved that affects all utilities on the system that leverage Qt. Depending on how exactly this rule is used, this could be trivial to translate, or it could be slightly tricky.
    • Defaults env_keep += "QT_X11_NO_MITSHM"
    • translates to (roughly):
    • permit setenv { QT_X11_NO_MITSHM } :sudo

/etc/sudoers.d/qubes

  • This looks like a generic account-wide nopasswd exception for the qubes group. There’s some SELinux stuff going on with it that can’t be ported, but since Kicksecure is based on Debian I don’t expect this to be a problem (I don’t believe SELinux is even used in Whonix or other Debian-based Qubes).

/etc/sudoers.d/qubes-input-trigger

  • Contains several NOPASSWD exceptions for starting various Qubes input-related services as root. There are four sets of nine services each, each set is handled by one line of sudoers config, which covers all nine services with the help of a regex match. We don’t get regex matching in doas, so this would have to be replaced with 36 lines of doas configuration. Not great, but not horrible.
    • user ALL=(root) NOPASSWD:/bin/systemctl --no-block start qubes-input-sender-keyboard@event[0-9].service
    • translates to
    • permit nopass user as root cmd /bin/systemctl args --no-block start qubes-input-sender-keyboard@event0.service, plus eight more lines with event1.service, event2.service, etc.

/etc/sudoers.d/umask

  • Trouble. This one changes umask settings for sudo commands in general. doas handles umask configuration entirely on its own and does not allow the end-user to configure it. Thus this cannot be translated. Depending on what doas’s umask settings are and how vital this configuration is, this may or may not be a blocker.

edit: somehow the O in “OK” got replaced by a smiling emoji, fixed it

2 Likes
23

One question that does come to mind is, the Qubes-specific config is coming from Qubes OS, not from Whonix or Kicksecure. Porting things to doas means that some of Qubes OS’s software will need to be ported to be doas-compatible also, which may or may not be something they’re interested in. In the worst case, we’d end up having to maintain sudoers support for Qubes, and only providing doas support for non-Qubes. Maintaining both sounds like it could be difficult. Might be worth filing a feature request in Qubes OS?

2 Likes
24 
dpkg -S /etc/sudoers.d/umask

qubes-core-agent: /etc/sudoers.d/umask

Will need to open a ticket at Qubes.

Related:

Will also need a ticket.

Yes.

Yes, please.

1 Like
25

I just did a quick test, and it appears that processes launched via doas simply inherit the umask of the caller.

[user ~]% umask
022
[user ~]% doas bash
root@localhost:/home/user# umask
0022
root@localhost:/home/user# exit
exit
[user ~]% umask 077
[user ~]% doas bash
root@localhost:/home/user# umask
0077
root@localhost:/home/user# exit
exit
[user ~]% umask 000
[user ~]% doas bash
root@localhost:/home/user# umask
0000
root@localhost:/home/user# exit
exit

Similar behavior is observed when using doas zsh rather than doas bash. This may be sufficient to work around the inability to configure umask in doas.

2 Likes
26
1 Like
27

upstream feature discussion: 'Investigating adding functionality to doas' thread - MARC

1 Like
28

Late, but better late then never… How about run0?

Advantages:

  • Speak for itself on its homepage.

Disadvantages:

1 Like
29

I don’t really think we should go with run0:

  • We won’t be able to migrate to run0 until the release of Trixie, at least. run0 was added in systemd 256, Bookworm is using systemd 252.
  • It doesn’t appear possible to configure run0 to run commands without requiring a password. That’s a dealbreaker, we have too much stuff that needs to be run as root without a password. (I mean, I guess we could try to migrate everything that needs to run as root passwordless to systemd, but that sounds difficult or potentially impossible.)
  • It’s unclear how to configure it at all - it’s configured “by polkit”, but polkit is a generic authorization framework, it doesn’t allow you to specify specific commands and arguments the way sudoers or doas config does. pkexec works by using an “annotation” in polkit whereby you basically tack on extra info to a polkit action so that pkexec knows how to authenticate what, but run0 doesn’t use that. How would one configure certain environment variables to be allowed to pass through while denying others? No idea, it might not even be possible.
  • It’s larger than doas. Way larger. run0 (really systemd-run) is 2642 lines long (including newlines and whatnot), and is heavily tied into the systemd codebase, which is about 1.3 million lines of C code. It’s unclear how much of that could be used to exploit run0, but some of it quite possibly can. doas on the other hand is relatively isolated (the only library it uses beyond the C standard library is PAM), and is only 1,850 lines long. Ergo, less attack surface.

There’s a few other issues or at least concerns (for instance you can pass through arbitrary environment variables using the --setenv argment, the only reason this isn’t a security vulnerability that I can see is that you can’t configure run0 to run a command without a password), but I don’t think it’s practical or advisable for Kicksecure or Whonix to use run0. I think we’ll be in much better shape if we stick with doas. Thanks to doas’s isolation, we can probably audit it easier too if we choose to do that.

2 Likes
30

Excellent points on run0, thank you! So if anything, let’s stick with doas.

Actually, I was just considering, a “sudoless” design. It might be possible. Development notes are here:

In that case, neither a port to doas would be required (nor a run0 port would be required).

2 Likes
31

Hmm, sudoless comes with its own unique set of challenges as well, though it looks hopeful. Some notable hurdles from an initial quick skim:

  • The following things in Kicksecure and Whonix will probably break if sudo isn’t usable by the end-user. These aren’t just things where the user can just boot into admin mode when needed, these are things that will break the user-mode user experience.
    • bootclockrandomization
    • sdwdate
    • setup-dist (in particular the easyorca feature, but it looks bitrotten?)
    • tb-starter (this one in particular will break badly)
    • tb-updater (this also may break pretty badly)
    • Various things in usability-misc
    • (maybe?) anon-gw-anonymizer-config

(I have a more detailed list of stuff here, but it’s not polished enough for me to publish yet, some of the more complicated packages I didn’t audit fully.)

  • Many of the features here cannot be implemented by using systemd services or other background things. We will still need some way to run certain commands as root, even in user mode (this will be important for doing things like enabling Tor Browser to be launched even when /home is mounted noexec). I have an idea for this that would be written in Python and would avoid any use of setuid executables, but we will need something along these lines for things to be practical.
  • How will Qubes OS VMs handle this? Will they just run as admin automatically and not use user mode at all?
2 Likes
32

How so? It has no sudoers exception.

This one we can say “boot into admin mode”.

Needs re-design.

We’ll just break the functionality as long as doas isn’t installed. As long as Tor Browser is unavailable as a Debian package [1] and thereby properly installed into the system and keeping out executable of the /home folder, Whonix probably should not enable noexec [1] for /home by default.

Qubes has a separate ticket. → Qubes sudo / su / root Hardening - Development Discussion

Qubes default is to install qubes-core-agent-passwordless-root. The plan for Kicksecure, Whonix is to no longer install qubes-core-agent-passwordless-root by default. Users will then be advised to open a Qubes Root Console instead.

[1] Would stable Tor Browser deb package help or burden whonix devs?
[2] Enhanced Security via Mount Options and Compiler Restrictions

2 Likes
33

True (I believe, working off memory and didn’t double-check), however there’s a GUI script for it that doesn’t seem like something that can be used in admin mode (it only applies to each specific boot). I guess it is a privileged operation though, so it probably is something we’ll just live without.

hmm, I guess it won’t be that much of a problem based on the research I’ve done so far. We will lose the ability to restart, stop, or even view the logs of sdwdate though, is that acceptable?

2 Likes
34

If worse comes to worse, yes. sdwdate-gui could show restart/stop actions only if started as admin.

As for logs, a sdwdate-logs.service systemd unit, doing something like the following would likely work (simplified):

journalctl --boot --output=cat -u sdwdate > /run/sdwdate/sdwdate-log.txt

In practice, sdwdate-log-viewer would need to be adjusted to do that. (Or something similar to sdwdate-log-viewer.)

2 Likes
35

We ended up not using doas. Instead, GitHub - Kicksecure/privleap: Limited Privilege Escalation Framework has been invented thanks to @arraybolt3. privleap has been written in memory-safe language Python. privleap does not have SUID attack surface because it has been implemented without SUID.

All uses of sudo by account user in Kicksecure, Whonix source code have been ported to to privleap. past notes: sudo / doas / sudoless / privleap

No Access to Privilege Escalation Tools (such as sudo or pkexec) for Limited Accounts (such as for account user) has been implemented as part of:

With user-sysmaint-split installed, there is no sudo SUID attack surface even if account user gets compromised. This is because account user can no longer use sudo by default. [1]

Example sudo command.

sudo nano

Example error message.

zsh: permission denied: sudo
zsh: exit 126 sudo nano

User documentation:

This has been available at least since 17.3.5.3 and above. (Unreleased at time of writing.)

Written about this also here:
Why passwordless sudo by default? - #5 by Patrick - Support - Kicksecure Forums

[1] opt-out: Unrestricted Admin Mode

2 Likes
36

I mean, congratulations but at same time, I have some worries about this. I think one should not create / maintain own projects unless they’re nessacary with no viable alternative available.

doas would’ve been a better pick.

1 Like
37

Agreed, but in this instance there is no viable alternative.

doas, in its true and most-likely secure form, is not available for Linux. It is an OpenBSD-only project, relies on OpenBSD-specific APIs, and cannot be used on Linux. There are applications similar to doas which are available for Linux and which are based on the original doas code, but these are forks of doas that introduce additional code from possibly untrusted third parties. At least one of these forks has had two vulnerabilities in it (https://www.cve.org/CVERecord?id=CVE-2019-15901, https://www.cve.org/CVERecord?id=CVE-2019-15900), one of which appears to have allowed executing arbitrary commands as root without authentication. Using a fork of doas does not appear to be a great idea for that reason.

On top of that, doas does not support drop-in configuration directories, and we received a rather forceful “no” from the OpenBSD developers when we offered to implement support for such a configuration interface upstream. All configuration must go into a single file, which would have necessitated a lot of complex tooling to allow merging together doas configuration snippets into a single master file.

Further than that, there is some attack surface opened by having any executable whatsoever being setuid root. Quoting Solar Designer (Automate vm sudo authorization setup · Issue #2695 · QubesOS/qubes-issues · GitHub):

Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)

Now granted, we have not yet succeeded in banishing every single setuid root application from Kicksecure and Whonix or at least making it not executable by standard users, but we don’t want to introduce any new SUID applications, and any remaining ones we would like to remove or disarm. This is a step in that direction.

The maintenance issues were definitely something we thought of before deciding to create this. Initially, the goal was to simply disallow all privileged operations when running as a standard user, and live with the limitations imposed by that. Unfortunately, that turned out to not be practical. doas’s feature set would have worked, but without a trustworthy variant of doas, we’d have to fork it and host the forked version ourselves, which would leave us with a similar maintenance burden, arch-specific downstream code, and a potentially higher attack surface. I think the current solution with privleap was likely a better call, since it’s arch-independent, suidless, has a more usable configuration interface, and we weren’t going to avoid the maintenance burden anyway.

2 Likes
38

Are we seriously going to measure a software security by the number of CVEs discovered in it ?

Then we might as well remove Tor browser, because every update they fix multiple 0-days.

If anything, the number of CVEs a software has, is an indication of being reviewed / taken care of.

Yes, the linux doas is the not the real doas, but is it better than maintaining your own

1 Like
39

The CVEs were only one reason among many, even if there had been zero security issues it wouldn’t have resolved the maintenance burden, lacking features, challenges with arch-specific code packaging, the inherent attack surface of SUID applications, and the absence of proven trustworthiness from the fork developers. Maintaining privleap is most likely easier than maintaining doas in Whonix maintenance-wise.

On the CVE point specifically, in an application as simple and small as doas, the presence of a bug that allows trivial local privilege escalation suggests a dangerous lack of care from the doas fork’s developer. Applications with millions of lines of code and dozens of dependencies can excuse an occasional critical CVE, it’s a lot harder to make that excuse when an application is extremely security-sensitive and very small.

2 Likes