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

> Aaron Rainbolt <arainbolt@kfocus.org> 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 disagree.
> 
> When security configuration is fragmented with the argument "but it is
> more powerful", the potential for mistakes increases greatly.
> 
> In our world, that makes no sense. One file exposes the entire policy.
> It is simple for a reason.

I would argue the potential for mistakes isn't *increased*, but simply
changed. When you have a fragmented but powerful configuration, a
project can provide good, secure defaults so that a user is less likely
to leave things in an unusable (or worse, unsafe) configuration. In
exchange, you open the door for the project to do something highly
inadvisable that results in an unusable or unsafe configuration. When
you have a unified, simple configuration, the project is no longer able
to make a mess of things for the user, but now the user can end up with
a system that is unusable or unsafe out of the box because they didn't
know they needed to update their doas config because they're not too
familiar with the system's internals. I don't think I need to argue that
packages automatically modifying doas.conf is a bad idea, the world
tried that with autoexec.bat and config.sys in the days of DOS and it
didn't work well at all :)

I guess it's a question of whether OpenBSD is interested in supporting
the requirements of projects outside of OpenBSD itself, at least when
it comes to doas. I agree that with OpenBSD's methodology and use case,
splintering the config isn't all that useful (though perhaps it would
let ports do useful things). But for a project, OpenBSD-derived or
otherwise, that doesn't expect the user to know how the system works
internally, the unified model isn't sufficient.