Aaron Rainbolt <arainbolt@kfocus.org> wrote:

> 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.

I disagree with all your points.