sudo account validation failure

D

davhol

My company produces an appliance (PHP/Web User Interface) based on FreeBSD (11.1) and recently, the sudo package was updated from 1.8.22 to 1.8.23. We have a couple of restricted shell logins for customer maintenance issues and after the upgrade, one of the restricted commands (which is a shell script with a sudo cat <file>) no longer works (it worked just fine prior to the sudo package update and, if I down-rev the package, it will continue to work). I've attached a screenshot of the console output when trying to execute the command when it fails.
We need to upgrade to FreeBSD12 where we won't be able to down-rev the sudo package (nor would we want to). From some research, we've discovered that in 1.8.23, sudo was re-engineered to use PAM and this, I believe, is where we are having issues. Does anyone have some insight as to how we can get commands like these to work again under the newer versions of sudo?
6063
 
Problems like that can be caused by various things. It's hard to tell without seeing your sudoers file, the properties of the accounts involved (e.g. does the home directory exist, does it have a valid shell etc.), maybe changes that you have done to the PAM configuration (…/etc/pam.d/sudo), and so on.

If everything else fails, you can build the security/sudo port without PAM support. Just run make config in the port's directory, remove the “PAM” checkmark, then rebuild the port and install it.
 
Maybe security/doas is an option? It's much more lightweight (34,3KiB vs 2.57MiB) and secure; e.g. doesn't accept passwords via pipe (which is advertised as a feature by sudo...).
Also the config syntax is much clearer and human- as well as scripting-friendly, which helps avoiding potentially dangerous misconfiguration.

We're using only doas on all our hosts and I found it to be much more scripting friendly; for user scripts as well as for configuring it via config management (ansible, scripts) especially because the config syntax can be very easily mangled with grep/sed/awk.
 
Talking about alternatives … personally I much prefer super (port security/super). It has all the features and flexibility of sudo, but the configuration syntax is much cleaner and easier to understand, so it's less error-prone and safer to use.
 
sko said:
Maybe security/doas is an option? It's much more lightweight (34,3KiB vs 2.57MiB) and secure; e.g. doesn't accept passwords via pipe (which is advertised as a feature by sudo...).
Also the config syntax is much clearer and human- as well as scripting-friendly, which helps avoiding potentially dangerous misconfiguration.

We're using only doas on all our hosts and I found it to be much more scripting friendly; for user scripts as well as for configuring it via config management (ansible, scripts) especially because the config syntax can be very easily mangled with grep/sed/awk.
Click to expand...
I'm agree with sko.

doas is friendly and secure. just do a pkg install doas and after that create the file that the POST install message says (normally /usr/local/etc/doas.conf) and add the following line:
permit nopass YourUsername

doas could be used for example to allow some users to use specific devices, programs or something similar.

Regards
 
Thanks Olli@!
Here's what is in /etc/shells:
Code: 
/bin/sh
/bin/csh
/bin/tcsh
/usr/local/bin/bash
/usr/local/bin/rbash
/usr/local/libexec/git-core/git-shell
Here's the relevant part of /usr/local/etc/sudoers:
Code: 
## (the '#' here does not indicate a comment)
#includedir /usr/local/etc/sudoers.d
netdiag ALL=(ALL) NOPASSWD: /bin/cat /root/.google_authenticator
netdiag ALL=(ALL) NOPASSWD: /usr/local/sbin/dmidecode -qt 1
netdiag ALL=(ALL) NOPASSWD: <redacted pathto>/utilities/hw-ver.sh
There is no /etc/pam.d/sudo file (there is one for su)
I've tried to re-compile sudo-1.8.27_1 withOUT PAM and the issue continues to persist so this issue may not be related to pam support in sudo.
Code: 
pkg info sudo-1.8.27_1
sudo-1.8.27_1
Name           : sudo
Version        : 1.8.27_1
Installed on   : Thu Feb 14 16:06:04 2019 MST
Origin         : security/sudo
Architecture   : FreeBSD:12:amd64
Prefix         : /usr/local
Categories     : security
Licenses       : sudo
Maintainer     : garga@FreeBSD.org
WWW            : http://www.sudo.ws/
Comment        : Allow others to run commands as root
Options        :
    AUDIT          : on
    DISABLE_AUTH   : off
    DISABLE_ROOT_SUDO: off
    DOCS           : off
    EXAMPLES       : off
    GSSAPI_BASE    : off
    GSSAPI_HEIMDAL : off
    GSSAPI_MIT     : off
    INSULTS        : off
    LDAP           : off
    NLS            : on
    NOARGS_SHELL   : off
    OPIE           : off
    PAM            : off
    SSSD           : off
And here is the relevant line from /etc/passwd:

netdiag:*:1003:1002:Net Diagnostic User:/home/netdiag:/usr/local/bin/rbash

What more info can I provide? As for using an alternate utility for sudo, that's not possible right now.
 
olli@ said:
Have you looked in /usr/local/etc/pam.d?
Click to expand...
Yes, and there is no sudo file in /usr/local/etc/pam.d (should there be one and, if so, what should it contain to permit "netdiag" to do what is in the sudoers file?). On the other hand, I have worked around the immediate issue by installing doas (thanks "sko" for that suggestion), creating a /usr/local/etc/doas.conf file
Code: 
permit nopass netdiag as root cmd /bin/cat args /root/.google_authenticator
permit nopass netdiag as root cmd /kbox/bin/utilities/hw-ver.sh
and this resolves the immediate issue. I guess I can move on from here but I'm still curious as to what "happened" with sudo after version 1.8.22 where things that used to work (like I mentioned in my initial post) now fail after the upgrade to a later version. We (the freebsd community) may be seeing more of this issue as freebsd-based appliances upgrade the base OS/packages.
 
I have no issues with sudo, and I do have a sudo file in /usr/local/etc/pam.d/sudo. This sounds like it could be your issue? It might be worth you doing pkg delete sudo and pkg install sudo and deleting any files related to sudo in there before reinstalling it again.
 
You must log in or register to reply here.
Back
Top