Maybe nice to know => Setting up 'doas' for your ports collection maintenance

[ShelLuser]

Hi gang,

So... I'm biased: I plain out don't like security/sudo, never have. Instead I heavily relied on /usr/bin/su but also on lowering requirements. For example: make a ports group, give it rw access to /var/db/ports and you don't have to bother with root to (re)configure your ports as long as you're part of that group.

... then I discovered security/doas, and I became a huge fan!

So: could I somehow implement this into the "ports workflow"? You know what I love about FreeBSD? There is so much information out there, all you have to do... is go look for it: /usr/ports/Mk/bsd.commands.mk. Check this out:

# Command to run commands as privileged user
# Example: "/usr/local/bin/sudo -E sh -c" to use "sudo" instead of "su"
SU_CMD?=                /usr/bin/su root -c

One visit to su(1) later and I realized that the default -c was actually an argument, not a class definition.

So then I visited /usr/ports/Mk/bsd.port.mk which is where I found this snippet within do-config::

                ${ECHO_MSG} "===>  Switching to root credentials to create $${optionsdir}"; \
                (${SU_CMD} "${SH} -c \"${MKDIR} $${optionsdir} 2> /dev/null\"") || \
                        (${ECHO_MSG} "===> Cannot create $${optionsdir}, check permissions"; exit 1); \
                ${ECHO_MSG} "===>  Returning to user credentials" ; \

So that's why they're firing up an extra sh instance with their sudo example.

Surely we can do the same with doas? Guess what, we can! => SU_CMD=/usr/local/bin/doas -n sh -c.

This will work miracles if you have something like this in your /usr/local/etc/doas.conf: permit nopass :wheel.

In other words: root permit restrictions in place, but without the hassle of needing constant password authentication.

I'm actually in the process of "kerberizing" this process courtesy of security/krb5 and a shell script, but that's a story for another time Work in progress so far.

Hope this could be useful for some of you!

 

[Maturin]

To me sudo was always some Linux crap.
Never used it on FreeBSD, never will, hate it when I'm forced to use it on some Linux, 'cause on many distris there is no real root anymore.
To me sudo always was a security gap. For two reasons:
1. (under some Linux) you get root-rights not by knowing root's password - there ain't any - but with your own user's password. Get the user's password, and you're root.
2. because of:

the hassle of needing constant password authentication.

Because you're getting pissed if you have to constantly entering passwords, and frequently mistype long passwords (plus everytime getting this annoying goody-goody message: "this will be reported" To whom? ME!!) you naturally pick short, so unsecure passwords. (typical of my ubuntu passwords: 'crap' )
How many of you sudo-ers also use simple and short passwords? hm?!
Yeah, "just temporary", of course. How long is this "temporary" situation been? >2 years?

So since it's not a good idea to remote login directly as root,
thanks ShelLuser for this post on doas!

 

[mariachi]

It would be great if, instead of a password, I could plug in my yubikey and never be asked for anything. No yubikey, no elevated privileges.
I know it's possible for SSH (I haven't tried it yet), but haven't seen discussions about using it for systems authentication. Maybe that's a dumb idea?

Otherwise I share the feelings about doas vs sudo coming from a lot of years in Linux and using FreeBSD recently in earnest.

 

[eseipi]

It would be great if, instead of a password, I could plug in my yubikey and never be asked for anything. No yubikey, no elevated privileges.

But doesn't that mean you just have those permissions all the time? What's the point in elevating then in the first place?

 

[JohnK]

Sorry, I may be a bit slow on the uptake but why not just make a rule to allow a user to build a port?

Not sure where I got the crux of the following but I have this in my doas.conf (along with all the other normal stuff).

# - The following permits john in group wheel to build ports.
# - Non-exhaustive list of variables needed to build ports
permit nopass setenv { \
        FTPMODE PKG_CACHE PKG_PATH SM_PATH SSH_AUTH_SOCK \
        DATADIR DESTDIR DISTDIR FETCH_CMD FLAVOR GROUP MAKE MAKECONF \
        MULTI_PACKAGES NOMAN OKAY_FILES OWNER PKG_DBDIR \
        PKG_DESTDIR PKG_TMPDIR PORTSDIR RELEASEDIR SHARED_ONLY \
        SUBPACKAGE WRKOBJDIR SUDO_PORT_V1 } john:wheel

 

[Blue|Fusion]

But doesn't that mean you just have those permissions all the time? What's the point in elevating then in the first place?

In the very brief overview that ShelLuser gave, yes it is rather insecure.

Here is a more restrictive doas.conf that I use on my FreeBSD systems: (slightly edited to add nolog and dmesg where appropriate)

# Require password for wheel users to do any actions as root
permit persist keepenv :wheel

# Do not require password for users in the wheel group running specific commands as root
permit nolog nopass keepenv :wheel cmd top
permit nolog nopass keepenv :wheel cmd btop
permit nolog nopass keepenv :wheel cmd ps args ax
permit nolog nopass keepenv :wheel cmd ps args aux
permit nolog nopass keepenv :wheel cmd dmesg
permit nopass keepenv :wheel cmd pkg args upgrade
permit nopass keepenv :wheel cmd pkg args autoremove

# Allow snmpd user to run specific commands as root for LibreNMS monitoring
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/wireguard.py
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/bind
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/nfs
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/smart
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/ups-nut.sh
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/manufacturer
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/hardware

Note that the last rule that matches the action is applied, which is why the specific command not requiring a password come after the blanket whee users requiring a password line.

Also, you'll notice I do have the persist option in the case of a password being required. I opted to use security/opendoas, a fork from the official portable OpenBSD doas to improve PAM authentication and a persistent password for several minutes (5 minutes IIRC). It is, however, falling behind in updates and future is questionable.

 

[sgharms]

# Require password for wheel users to do any actions as root
permit persist keepenv :wheel

# Do not require password for wheel users running specific commands as root
permit nopass keepenv :wheel cmd top
permit nopass keepenv :wheel cmd btop
permit nopass keepenv :wheel cmd ps args ax
permit nopass keepenv :wheel cmd ps args aux
permit nopass keepenv :wheel cmd pkg args upgrade
permit nopass keepenv :wheel cmd pkg args autoremove

# Allow snmpd user to run specific commands as root for LibreNMS monitoring
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/nfs
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/ups-nut.sh
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/manufacturer
permit nolog nopass snmpd as root cmd /usr/local/share/snmp/hardware

This is a really lovely starting point for a doas.conf file. I'd vastly prefer this to the complexity afforded by sudo. If you cases much more complex then this, you have a root password for a reason IMHO.

 

[SirDice]

To me sudo was always some Linux crap.

It was originally developed on 4.1BSD, about a decade before Linux existed.

A Brief History of Sudo

The Early Years Sudo was first conceived and implemented by Bob Coggeshall and Cliff Spencer around 1980 at the Department of Computer Science at SUNY/Buffalo. It ran on a VAX-11/750 running 4.1BSD. An updated version, credited to Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso, and...

www.sudo.ws

 

[JohnK]

Blue|Fusion Interesting that you implicitly allow wheel and not a specific user.
Could that be a "dangerous situation" (where another user added to admin group later)?

I opted to allow user (not group).
permit nopass john as root cmd pkg args update

Also, is there a reason why you called out TOP/BTOP/PS (-i.e. do those commands need root access)?

 

[Maturin]

It was originally developed on 4.1BSD, about a decade before Linux existed.

Thanks! Learning can be fun

 

[Blue|Fusion]

Blue|Fusion Interesting that you implicitly allow wheel and not a specific user.
Could that be a "dangerous situation" (where another user added to admin group later)?

I opted to allow user (not group).
permit nopass john as root cmd pkg args update

Also, is there a reason why you called out TOP/BTOP/PS (-i.e. do those commands need root access)?

In my absolutely unprofessional opinion, if a bad actor can add themself to the wheel group, they already gained root level access through another means. For ease of administration and multiple admin accounts on some hosts, specifying :wheel vs a specific user is an acceptably low risk for my needs.

With the following sysctl settings, a non-root user may not see other users' processes, so to see the system processes as a whole, root level access is required.
sysctl.conf

security.bsd.see_other_uids=0
security.bsd.see_other_gids=0

% ps ax | wc -l
       7
% doas ps ax | wc -l
     121

Also, I should add dmesg to the nopass doas.conf commands as I have security.bsd.unprivileged_read_msgbuf=0 in sysctl as well.

 

[JohnK]

I was thinking more along the lines of multiple (different) solutions -e.g. htop and btop whereas one admin installs a solution where one already existed and thus creates a sort of a mess. …I’m just me on my servers so I don’t have much of a ‘professional opinion’ either but I thought it worth the ask. I wouldn’t be concerned too much with a user elevating privileges (too late at that point).

Good to know about the sysctl stuff. Thanks.

 

[ShelLuser]

But doesn't that mean you just have those permissions all the time? What's the point in elevating then in the first place?

Having such permissions accessible still differs from actually using them, which is the point. Because it would still create a barrier between what normal users can access and/or do and root.

Which is also why I'd argue that not using a password doesn't have to be insecure at all, also depending on how the account which can do that gets authenticated.

It is a bit far fetched, but not having to type a password also implies no risk of evesdropping. Still, I am actually in the process of expanding on all this through the use of Kerberos, even though this isn't officially supported by security/doas.

Sorry, I may be a bit slow on the uptake but why not just make a rule to allow a user to build a port?

Well, because I prefer the elevation: not being able to "do" certain things unless I elevate my permissions, after which I am allowed to.

 

[eseipi]

Having such permissions accessible still differs from actually using them, which is the point. Because it would still create a barrier between what normal users can access and/or do and root.

If I understand you correctly, we're examining a situation where a normal user is a member of the wheel group, and that group has the nopass option in doas.conf to execute any command ( permit nopass :wheel). In this case, yes, there is still some barrier to run programs with uid 0 (namely, one need to prepend the command with doas), but I think it's even less secure than putting your unencrypted password.txt into some deep directory that no one would ever think to look in. What attack vectors does this barrier protect us from? Certainly not from malware or unauthorized remote access, which I think are the main concerns in our context.

Which is also why I'd argue that not using a password doesn't have to be insecure at all, also depending on how the account which can do that gets authenticated.

Exactly, in this scenario every :wheel user effectively becomes superuser and must be treated accordingly, which is why I asked about the point of such elevation. For now I can only think of protecting (quite weak also) against myself

UPD: The approach suggested by Blue|Fusion is much more justifiable and, in my opinion, is the only reason to have the nopass option at all. It provides some convenience in certain places without wrecking the privilege separation in general.