Index | Thread | Search

From:
Aaron Rainbolt <arainbolt@kfocus.org>
Subject:
Re: Investigating adding functionality to doas
To:
Matthias Kilian <kili@outback.escape.de>
Cc:
tech@openbsd.org, adrelanos@kicksecure.com
Date:
Fri, 29 Nov 2024 09:30:04 -0600

Download raw body.

Thread
On Fri, 29 Nov 2024 05:06:52 +0100
Matthias Kilian <kili@outback.escape.de> wrote:

> Hi,
> 
> On Thu, Nov 28, 2024 at 07:06:02PM -0600, Aaron Rainbolt wrote:
> > * All doas configuration has to go into a single '/etc/doas.conf'
> > file, which makes it difficult for a Linux distro to make use of
> > doas as the default privilege escalation utility in place of sudo.
> > If a tool needs to be able to be run by all users or a particular
> > user as root without a password, the user has to explicitly
> > configure that themselves, the tool can't ship a doas configuration
> > "snippet" that allows it.  
> 
> About those config "snippets": I had a very bad time figuring out
> on one of those super-clever linux systems why a
> "PasswordAuthentication no" in /etc/ssh/sshd_config didn't work. The
> reason was that they by default put a file into
> /etc/ssh/sshd_config.d with "PasswordAuthentication yes" (and didn't
> document it anywhere). So I had do disable this with an
> /etc/ssh/sshd_config.d/000-go-fuck-yourself with
> "PasswordAuthentification no".
> 
> Do you still think that configuration snippets for security related
> tools installed by arbitrary packages are a clever idea?

Certainly the feature can be misused (I actually ran into *exactly* the
problem you mention here using Ubuntu Server once). But at the same
time, there are things that just can't be done safely without config
snippets. The primary example is when a "nopass" rule is desirable for
a particular utility, and that utility wants it there by default. The
only reason OpenBSD hasn't run into this need already is because
OpenBSD is not designed to "just work" without the user learning about
how things work internally. The learning experience is part of it, so
it's fine for a user to have to configure things like doas manually.
That's a great methodology to use, but not all projects are content to
only target that userbase. For projects that target users that don't
necessarily know how the system works internally, making the user edit
doas.conf manually to set up their system isn't an option.

--
Aaron

> Ciao,
> 	Kili