On Fri, 29 Nov 2024 09:44:50 -0700
"Theo de Raadt" <deraadt@openbsd.org> wrote:

> Stuart Henderson <stu@spacehopper.org> wrote:
> 
> > On 2024/11/29 09:30, Aaron Rainbolt wrote:  
> > > 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.  
> > 
> > I'm not sure there is a sane way to handle this with "include" files
> > - have the "include" files processed before the main doas.conf and
> > it's easy for the user to accidentally override it and break things
> > - have it processed afterwards and it's easy for some package to
> > override a user's requirements and break things.
> > 
> > An alternative would be to put the configuration sections for these
> > various programs into a default doas.conf distributed with the
> > system. Or use a special binary based on doas which is _just_ used
> > for these "internal" elevations and permits only them.  
> 
> But the ship has sailed.
> 
> We are not going to make this more complicated, and affect the
> existing users who rely upon the simplicity.
> 
> It is simple for a reason.  There are always people showing up and
> saying "but I want it to be more complicated, and here are my
> complicated reasons, and the people who rely upon simplicity will
> just adapt".
> 
> Those people will not have to adapt, because we'll keep it simple.
> Much easier.
> 
> Anyone is free to fork doas codebase, add all the features they want,
> CALL IT BY A NEW NAME WITH NEW COMMANDNAME, and in a couple years
> collect all the features of sudo and start collecting bug dangerous
> reports in those features.  Anyone who thinks this isn't how it will
> play out is being dishonest.

FWIW, I did search the tech mailing list archives for 'doas' before
posting, and didn't see *anyone* who had made a feature request for
doas before, so I didn't know that feature requests to doas were
at all common. I also didn't think any of these features were risky or
were similar to sudo's more ambitious features like regex handling,
aliases, machine specific policies, etc. (Password feedback was the one
that was the most "eh... that doesn't seem like it really fits" that I
could tell.)

Anyway, back to the point. I think it's clear enough that configuration
snippets are considered a bridge too far, so I'm happy to drop it. I
was legitimately trying to help upstream when I offered to add this,
but my downstream will survive just fine if we have to implement a
thing that builds snippets into a working config file.

At the very least, would the umask handling feature be welcome? The
only place umask modifications can be made reliably when working with
privilege escalation is in the privilege escalation utility itself, due
to the fact that it behaves almost like an environment variable. The
workaround is to use a wrapper script, but that is a horrible hack that
I would like to avoid if at all possible (though again, my downstream
will survive if we must). I can definitely see this being useful in
OpenBSD itself, separate from any other project.

I am well aware that forking doas is an option. It's also one I'm
trying to avoid like the plague because as much as I trust I can write
good code, I don't trust myself to write good enough code on my own.
The fact that the only two CVEs ever reported against doas were both in
a fork of it and only affected the fork does not escape me, and that's
another big reason why I want to work with upstream rather than forging
my own path alone. Especially since this is an SUID-root utility.