On Fri, 29 Nov 2024 08:30:14 +0100
"Peter N. M. Hansteen" <peter@bsdly.net> wrote:

> On Thu, Nov 28, 2024 at 07:06:02PM -0600, Aaron Rainbolt wrote:
> > I've been playing with doas on Linux lately, since I work with a
> > project (Kicksecure) that is interested in switching from sudo to
> > doas. The much smaller size and secure upstream fits well with what
> > we're trying to do. However, there are a few features missing from
> > it that would be quite useful for our use case, which I'd be
> > interested in contributing to OpenBSD if they aren't considered
> > "too much":  
> 
> I do not speak for the project, but I think the chances of having any
> of the functionality you describe added to doas is minimal. The
> reason is quite straightforward: doas was specifically designed to be
> as simple as possible while still being useful to the OpenBSD
> developers themselves.

Right, and making it overly complex isn't my goal here. Half the reason
Kicksecure wants to use doas is because it's *not* the miserably
complex behemoth that sudo is. I think at least two of the features I
want to add will be useful to OpenBSD too though (not sure if the
*developers* will use them since they've lived without them this long,
but they might), and I don't expect either of them to be messy to
implement or require a large amount of code.

> The reason doas exists is that keeping the base sudo in sync with the
> ever increasing complexity of the upstream code became a maintenance
> nightmare.
> 
> Unless you are at least a little involved in developing the system,
> chances are (I estmate upwards of 90% of the active users) your needs
> will be covered by simply copying the default /etc/examples/doas.conf
> to /etc/doas.conf and be done with it. To save you the trouble of
> looking up the result, this would leave you with a configuration that
> has this as the only active line:
> 
> permit keepenv :wheel
> 
> which again covers the practical needs for the vast majority of us.

So, I am involved in developing the system, and I know that a
configuration like that will not work. The reason is:

* Various utilities in the system need to be able to run certain
  executables as root. Many of these utilities run as the user at login
  time, so they have to be able to run these privileged commands
  without authentication. otherwise the user would be spammed with
  authentication prompts every time they boot the system. Thus we need
  nopass rules to help with that.
* Some of these utilities (optionally) take input via environment
  variables or can have their behavior overridden by environment
  variables, and so using keepenv in the rules for those utilities would
  be very dangerous.
* We don't want the user to be able to run *everything* without
  authentication, so a global nopass rule isn't safe.

I actually spent a very significant amount of time looking over our
existing set of sudoers rules and determining how to translate them to
doas rules in a way that would be sufficient for us. This was the
result: https://forums.whonix.org/t/replace-sudo-with-doas/17482/18

> Developers or active testers with a need to build packages from ports
> or build the system from source may need some extra features, much as
> described in the doas.conf man page. 
> 
> I can muster some sympathy for the desire to include the foot shooting
> prevention features you describe, but to get any additional complexity
> included you would need to supply extremely good code and present
> truly convincing arguments that the desired results could not be
> achived in any other way. The design goal for doas was to be as
> simple as at all possible while remaining useful to the OepnBSD
> developers, so the bar for adding functionality is high. Basically,
> you need to demonstrate that the added complexity is worth the
> maintenance overhead in perpetutity.

Sure, that makes perfect sense, and figuring that out is why I wrote
this email. Technically there are other ways of doing the things I'm
looking to implement, but... they're extremely hacky.

* Setting the umask appropriately could be done with a wrapper script
  around doas, which would set the umask, and then call doas with
  whatever arguments the user specified. This may not work correctly if
  doas messes with umask more than just passing it through (haven't
  found out if it does yet), and it means putting a shell script in
  between the user and doas, which is obviously not something we want.
* Implementing configuration snippets could be done by warning the user
  to never edit doas.conf by hand, and to instead write config snippets
  if they need to add any rules. Then a script can be used that builds
  those snippets into a doas.conf file. The main reason this is
  undesirable is because it means the user could add configuration and
  then forget to "rebuild" it, it means that doas.conf becomes
  impossible to safely modify, and it means that a problem in any one
  configuration snippet will both break doas entirely. Figuring out
  the right configuration snippet will be tricky because doas will
  report which rule is broken, but not which file it came from.
* Password feedback would require the "interposer" script between the
  user and doas to record the password into a variable, then feed it
  into doas. This means that the user password will be stored at least
  temporarily in the memory of a process that user owns. This could be
  a security risk if something can read that process's memory. Having
  doas do this directly would mean only a process running as root has
  the password, which is a bit safer.

Due to the hacks needed to force doas into doing these things, it seems
like it would be better to add the features to doas itself. That would
most likely be safer and far more elegant.

I've gotten C code upstreamed into Qubes OS in the past, which also has
very high coding standards due to their security focus, so I have
experience with writing good C. Given that this is eventually intended
to go into a SUID-root application that our users will be relying on,
I'll be writing code carefully for our sake as much as for upstream's
sake.

> That said, would perhaps your project needs be better served by using
> OpenBSD going forward? ;)

That would be fun :) However, even if we were to port over to OpenBSD
as a base, we'd still need or at least really want at least two of
these three features (namely umask control and config snippet
handling).