On Fri, Nov 29, 2024 at 11:13 AM 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.
>
>
A few pointers and a question.

The umask could be set using login.conf and a class , so it can be managed
outside doas ( that's the actual question , it think it is possible )
The Include can be done outside easily running `cat /etc/doas.d/* >
/etc/doas.conf` can be done in the reload of the service declaration
I will not comment on The password  "feedback"  ( really? a "feature ?" )

A packager could even do something a bit more fancy than `cat
/etc/doas.d/*` to include different usernames using some sort of macro
expansion.

DOAS stay doas, the package is providing local OS stuff,

Everybody happy ?