Replace sudo with doas

Development
1

There are many miscellaneous improvements that could be done to vastly harden Whonix.

Let’s take the program sudo that is a SUID program and is written primarily with companies use-cases in mind. It supports complex configuration and the source-code is relatively Large and not properly audited. Think of the exploit that affected it for years and no one knew about it.

I chose to start the miscellaneous improvements thread with sudo since Whonix does not use any sudo complex configuration quirks and thus making the jump should be seamless with no major issues.

Switching to the more secure and audited alternative doas which is built with security and desktop usage in mind can bring enormous security benefits to Whonix.

You could even alias sudo='doas' to make the transition even more seamless.

I am willing to do the required extensive testing on my Whonix machine and report back any issues I may encounter.

1 Like
2

sudo exploitability hysteria is old news. There are tons of articles about this, it’s perfectly suitable and safe.

3

No hysteria involved in writing this post. I am talking purely about security, doas is simply a lot more secure. And don’t take my word for it, take the experts word who wrote, the same guys who work on OpenBSD.

Even in-house security experts such as @madaidan recommend doas over sudo

4

Some quotations / references on sudo vs doas would help to settle the question if it is more secure.

doas seems also written in C. At least rust would have been nicer. Or if sudo (or doas) was mostly rewritten in python and only strictly necessary parts in rust that cannot be done with python. That said, before using doas, are there even more secure alternatives?

Did you grep the Kicksecure / Whonix source code yet to see if it is feasible to replace it?

1 Like
5

Does doas support credential caching? dist-installer-cli (Kicksecure / Whonix - Linux installer) runs as user but uses sudo several times when required. If needing to re-enter the password several times that would be impractical.

1 Like
6

Some quotations / references on sudo vs doas would help to settle the question if it is more secure.
references:

doas is a minimal replacement for the venerable sudo. It was initially written by Ted Unangst of the OpenBSD project to provide 95% of the features of sudo with a fraction of the codebase.

It is exactly same as sudo except much less codebase (reduced attack-surface) and is written with Desktop and security in mind, things that sudo lacks as it is written with companies in mind.

It is written by the same people who wrote openSSH, openBSD and more. It is vetted.

Does doas support credential caching?

doas does support credential caching with a simple configuration file such as this:
permit persist :wheel

1 Like
7

https://salsa.debian.org/debian/opendoas#peristtimestamptimeout contradicts this.

Perist/Timestamp/Timeout

The persist feature is disabled by default and can be enabled with the configure flag --with-timestamp.

This feature is new and potentially dangerous, in the original doas, a kernel API is used to set and clear timeouts. This API is openbsd specific and no similar API is available on other operating systems.

As a workaround, the persist feature is implemented using timestamp files similar to sudo.

See the comment block in timestamp.c for an in-depth description on how timestamps are created and checked to be as safe as possible.

1 Like
8

Apart from that the next step could be:

  • Check current uses of Kicksecure / Whonix source code using sudo. This could use a complete review. Attempt to replace these uses by using capabilities, if applicable. Maybe neither would be required.
  • Do the same for pkexec because if getting rid if sudo should get rid of pkexec too?
  • The /etc/sudoers.d configuration drop-in snippets probably don’t hurt and can remain even if sudo would be no longer installed by default.
  • If sane, feasible… Replace all users of sudo with root-wrapper (to be invented) (part of helper-scripts) a tool that uses doas if available, falls back to sudo if available or errors out if neither is available. This might help during migration and keep this flexible.
  • It seems there’s no /etc/doas.conf.d configuration snippet drop-in folder. Please post a feature request and/or contribute to upstream (if they were to accept such a feature).
  • Because without /etc/doas.conf.d how would each package configure the required exceptions?
1 Like
9

That is odd. is important to keep in mind that there is 2 versions of opendoas, one for BSD systems and one for Linux systems.

1 Like
10

So I decided it’s enough talking and it’s time to get straight to the action.

Time to remove sudo and install doas !

NOTE:: I am using KVM port of Whonix made by @HulaHoop

To reliably test, I am going to start by only replacing sudo from Workstation.

I first looked up doas package in bookworm, noticed it is a transitional package for [opendoas](https://packages.debian.org/bookworm/opendoas)

So I installed [opendoas](https://packages.debian.org/bookworm/opendoas)

OFF-TOPIC:: As it installed, apt told me there is a package called busybox which is installed and no longer needed, potentiality room for improvement here ? @HulaHoop consider removing busybox since we already have all gnu tools installed, makes no sense to have it really.
And would love if @patrick checked on Virtualbox to confirm / deny busybox package being installed by default

Back to topic:
I configure opendoas by first making a directory /etc/doas.d/ then inside I create doas.conf with the following content:

# This will allow users in the wheel group to use doas.
permit persist :wheel

Then I make a symlink in /etc/doas.conf

ln -s /etc/doas.d/doas.conf /etc/doas.conf

I then ran the command groups to show what groups I am apart of, and received the following:

user cdrom sudo audio dip plugdev users console ssh debian-tor

I was baffled at first why my user is not part of the wheel group but I guess whonix uses the sudo group instead? Is it a security risk to add myself to the wheel group and remove sudo from my user ?

Anyway I went back again and edited /etc/doas.conf to edit wheel to sudo

permit persist :sudo

For your information, persist means cache creditenels so you only have to type password once in a terminal, but if you close terminal and try in another one you must enter password again. Same exact behavior which is done by sudo.

Bam, it all works extremely well!

Now back to the big guns, before I remove the sudo package, I took a look at /etc/sudoers and /etc/sudoers.d/ files to confirm that Whonix does not use any kind of special configuration for it.
Turns out it does but I decided to go the reverse engineer way. I simply backed up the original sudoers files, then I wrote

doas apt remove sudo

Then I got the following:

The following packages will be REMOVED:
  anon-ws-disable-stacked-tor apparmor-profile-dist apparmor-profiles-kicksecure
  bootclockrandomization dist-base-files helper-scripts kicksecure-default-applications-cli
  kicksecure-dependencies-cli kicksecure-dependencies-system kicksecure-desktop-applications-xfce
  kicksecure-desktop-environment-essential-gui kicksecure-desktop-environment-essential-xfce
  kicksecure-recommended-cli legacy-dist msgcollector msgcollector-gui non-qubes-audio
  non-qubes-vm-enhancements-cli non-qubes-vm-enhancements-gui non-qubes-whonix-workstation-cli
  non-qubes-whonix-workstation-xfce open-link-confirmation repository-dist sdwdate sdwdate-gui
  security-misc setup-dist setup-wizard-dist sudo swap-file-creator systemcheck tb-default-browser
  tb-starter tb-updater usability-misc vm-config-dist whonix-base-files whonix-firewall
  whonix-shared-default-applications-gui whonix-shared-packages-dependencies-cli
  whonix-shared-packages-recommended-cli whonix-workstation-packages-dependencies-cli
  whonix-workstation-packages-dependencies-pre whonix-workstation-packages-recommended-cli
  whonix-workstation-packages-recommended-gui

I immediately did “N” to prevent everything from being removed , what’s up with that? why it pulled all these packages ?

1 Like
11

links:

group wheel:

busybox:

Not sure what this is good for but this won’t abolish the need for native /etc/dosas.d support.

Because these packages Depends: on sudo. You see that if you analyze current uses of sudo by Searching the Source Code.

Without looking at the source code, no meaningful progress can be made here because there are many invocations of sudo --non-interactive (and pkexec).

1 Like
12

I am cloning the kicksecure repo right now. Will grep through it.

1 Like
13

Just bumping this, I’ve been using exclusively doas for years now and have been setting up my Whonix gateway. I encountered the same problem neo here has when removing sudo. Just wanted to throw in I’d be happy to help out and patch these programs with a doas case and test.

If you want to collaborate on this @neo0xff let me know and I can share my matrix

14

We can collaborate through the forum but Matrix is fine too

15

If you don’t like sudo, then you also don’t like pkexec?

pkexec presumably is even more fancy, complex. Yet, I didn’t find any other way to allow GUI applications take root actions such as:

  • Anon Conection Wizard (ACW) writing to Tor configuration, or
  • Derivative Repository Wizard writing /etc/apt/sources.list.d/derivative.list file,
  • etc.

Except for pkexec / sudo.

1 Like
16

Problem with pkexec is that it breaks hidepid.

1 Like
17

Yes, yes I do not fancy the idea of running GUI stuff on root.

I am not expert on the matter but on Linux, virt-manager somehow manages to manage VMs that are only accessible to root user while virt-manager it’s self is running as user, I think it has something to do with polkit. Maybe we should look into that?