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.