From: Stuart Henderson Subject: Re: Investigating adding functionality to doas To: Aaron Rainbolt Cc: Matthias Kilian , tech@openbsd.org, adrelanos@kicksecure.com Date: Fri, 29 Nov 2024 16:39:15 +0000 On 2024/11/29 09:30, 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'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.