From: "Theo de Raadt" Subject: Re: Investigating adding functionality to doas To: Aaron Rainbolt Cc: Matthias Kilian , tech@openbsd.org, adrelanos@kicksecure.com Date: Fri, 29 Nov 2024 09:40:28 -0700 Aaron Rainbolt wrote: > On Fri, 29 Nov 2024 09:12:08 -0700 > "Theo de Raadt" wrote: > > > Aaron Rainbolt wrote: > > > > > On Fri, 29 Nov 2024 05:06:52 +0100 > > > Matthias Kilian 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.