Index | Thread | Search

From:
Aaron Rainbolt <arainbolt@kfocus.org>
Subject:
Investigating adding functionality to doas
To:
tech@openbsd.org
Cc:
adrelanos@kicksecure.com
Date:
Thu, 28 Nov 2024 19:06:02 -0600

Download raw body.

Thread
(Note: I don't have code patches yet, this is mostly me probing to see
if the functionality I want in doas is something that is desirable
and/or acceptable upstream. I intend on sending patches if so. Also,
apologies if this is the wrong list, I debated sending this to
bugs@openbsd.org but I couldn't tell which list was more appropriate.)

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":

* There's no support for setting the umask of the process being
  launched by doas - it appears that the umask is set purely based on
  internal logic in doas (which also seems to just propagate the umask
  of the process that launches doas to the process that doas launches
  based on my testing, I haven't looked at the code yet). It would be
  very useful to be able to specify a rule like
  'permit user as root umask 022', so that we can configure user
  accounts with a strict umask like 027 without users unintentionally
  creating files that only root can read when doing things like
  'doas vi /etc/config_file'.
* 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. (Note: I am well aware of the fact that doas doesn't
  support a wildcard-style method of allowing all users on the system
  to run a tool as another user, this doesn't pose a problem for us
  though since we can specify an "admin" group and just add all users
  that are authorized to run privileged commands to that group.) It
  would be helpful if the main doas.conf file could specify other files
  or directories to "include".
* This is minor, but there is no "password feedback" option that would
  allow displaying a character like '*' for every character of the
  password that has been entered. Arguably this kind of a feature could
  be seen as a security liability, but it would make the tool more
  usable for some, and since Kicksecure is targeting users who might
  not be "good with technology", this would be useful for us.

I don't expect any of these to require a whole lot of code to
implement (though... I guess I can see the password feedback one
potentially being hard), so I don't think these features would pose a
threat to doas's goal of remaining very small. The first two would
greatly increase doas's usability outside of OpenBSD, and the umask
feature in particular would make doas more useful in OpenBSD itself.

If any of these sound like something OpenBSD would be interested in
having implemented, I'll get a patch (or two or three) together. I'm
also open to other ways of doing the things that I'm trying to
accomplish with doas currently.

Thank you for taking the time to look at this!
Aaron