Privileged account access is a sensitive thing today, especially with all the compliance and regulations requirements built into most corporate information systems. Even without any regulation, most good UNIX and application operations people will want to know WHO did WHAT?
In the old days (pre-sudo), there was just “su” which was used to achieve the ability to run a command as another user, typically but not always root. The “su” was logged but it still could result in a lack of access control due to the ability of passwords to be shared. With “su” you enter the password of the account you are using, so since anyone might know that password eventually, we consider that “anonymous” access. Though “su” will log the identity of the user who uses it, with password accounts you have to worry about multiple entry points (console, ssh, ftp, possibly telnet). With NO-password accounts, on most UNIX default installations, you only have to worry about two entry points: sudo and keyed ssh. Because of this, no-password accounts can be considered to be much more secure. Note: It should be obvious by now, but to be very clear: By NO-password accounts, we mean accounts that don’t have valid passwords and are thus prevented gaining UNIX execution access as a result of a username/password combination. We do not mean that the account can be accessed with a username and entering a blank password. Their is no standard terminology unfortunately. It would be nice if the various flavors of UNIX that offer this ability would use the same name for it but they don’t. Solaris calls them “NP” (No Password) accounts. OpenBSD manual calls them “accounts that are not intended to be logged in to”. Linux uses the same method as the BSDs but doesn’t have a term for it. There is the ability to set a no-password account in the BSDs and in 99% of the Linux distros (all those using /etc/shadow) by setting it to an invalid character (both ! and * are used for different symbolic reasons). Apple MacOS doesn’t call it anything but they set root to “no-password” by default.
Why don’t you need a root password? In Linux and the BSD UNIXes, you can just set the password to “*” or “!” or “!!” or “*************” and in Solaris you can set the password to NP, which means it doesn’t have a password. The only way to access the account is by sudo (or ssh, if you have keys set up, and, in the case of root ssh, if you allow root ssh – we recommend you don’t). This means all root-accesses are now logged and can be audited, even “sudo su – ” if you allow that for your core UNIX admin team.
When Todd C. Miller and the other OpenBSD folks integrated sudo into the OpenBSD operating system, this was a game changer. With sudo, you entered your password to authenticate yourself, and it allows you to run specified commands as specified user, those specifications being in the special root-owned file “/etc/sudoers”. The /etc/sudoers file allows some fine grain ability to specify specific commands that certain users may run as root (or other users) but restrict all other commands. Care must be taken to craft this file without holes, “sudo <vi, cp, or anything that writes a file in a executable file system>”, but it is not extremely difficult to allow elevated privileges only where necessary. Like any lock on the door, you must read the manual, understand the configuration, and audit and verify the system periodically.
Tip: To secure shell scripts that run as root can be tricky. Make a special directory for scripts that will contain commands that will be executed with your privileged execution software such as sudo. You might name it /apps/sudos/. That directory should be root owned and 755 permissions (readable, executable by all, but writable only by root). The contents of the directory should also be root owned and 755 permissions. This controls this directory as the only place where sudo commands can run from, so anything that goes here must be sanity checked before installation (and in periodic audits). Don’t allow operations on this special directory from any sudo “mv” or sudo “vi” or “cp” or even “perl” and “dd” (basically anything that can writes files to a disk).
Now you might want to go out and buy a fancy sudo replacement that has centralized control and logging and that would be fine if it was deployed well (at a higher expense of course), though those advantages pan out less if you have three things in place in your application environment that you should have anyhow:
- Centralized Remote Log Server – We will write more about this later, you can bet on it. Delivery can by either syslog or push script daemons or crons.
- Centralized Host Intrusion Detection – There’s ways to tell if things change on a system from another system, typically on that is off the network most of the time itself to protect its file signatures. The /etc/sudoers file is only one of many important files on a UNIX system for which you should have the ability to know if it changes, so having a way to know when files in /etc/ change, and alerts to go out to the host administrator is an important function of any healthy data system. We’ll be writing more about this later too.
- Centralized File Distribution services – If you manage more than 5 servers, and you don’t have a way to version control and distribute configuration file updates automatically to your servers, you should work on that, because the investment will pay off. We’ll have some tips later for you regarding this.
© Copyright 2020 Rex Consulting, Inc. – All rights reserved
