How to harden su with dpkg-statoverride?

Question

I am reading an Ubuntu 14 hardening guide and this is one of the suggestions:

It generally seems like a sensible idea to make sure that only users in the sudo group are able to run the su command in order to act as (or become) root:

dpkg-statoverride --update --add root sudo 4750
/bin/su

I looked up the dpkg-statoverride command but I still can’t figure out exactly what the command above is doing?

It seems to imply that Ubuntu 14 by default allows anyone to sudo. To test, I created a new user, logged in as that user, tried to sudo and it failed – which is good.

So what is the purpose of the suggestion above?

Answer 1

The purpose is to prevent ordinary users from running the su command (su is similar to sudo, the difference being that sudo executes one command, su starts a new session as a new user, which lasts until that user runs exit)

The default mode of su is 4755 or rwsr-xr-x, the "s" means that the command is set-UID (which means that it always runs as the user who owns it, rather than the user who happens to execute it. In this case su is owned by root, so it always runs with root privileges)

su has its own security measures in place to ensure that the user who executes it has authority to become another user (typically by asking for the other user's password), but it's conceivable that there would be a security vulnerability in su that would allow an attacker to somehow convince it to do something else without authority.

By changing the mode to 4750, it prevents ordinary users (users other than root and those in the sudo group) from even reading or executing it in the first place, so an attacker would need to either change the ownership of that file, or change the mode of the file, or change their own effective UID/GID before they could even attempt to exploit this theoretical vulnerability in su.

The dpkg-statoverride command is useful in this instance because it directs the package manager to use those ownership/mode values for that file, even if it gets replaced by a newer version (i.e. via apt upgrade). In other words, it makes it more permanent than just a chown and chmod.

Here's a general-purpose tactic I recommend for this instance: Whenever I'm tweaking configuration of su/sudo or any authentication component on a Linux/UNIX machine, I'll open up another ssh/putty session to that server and log in as the root user, and just leave that session open in another window. That way if I do screw something up and lock myself out, I've already got a login session where I can fix anything I broke.

Answer 2

Depending on your users, that may be a good or bad idea.

The su command can be used by ordinary users to log into any other account, not just the superuser's, provided they know the password of the account.

This is useful e.g. when two users are cooperating on a project, one of them (userA) is logged in and they need to read a file only accessible to the other user (userB). Simply running

su -c 'cat /home/userB/file' userB >file

can be used to copy the file to the logged in user's home directory, but that is only possible if userA is allowed to run the su command.

On PostgreSQL database servers, it is usually possible for database administrators to switch to the postgres user to perform some maintenance tasks that are not possible while the database server is live; for this to work, they need to be able to run su - postgres.

The same considerations apply to the sudo command (which is different and way more complex than su -- it is only the default configuration that makes the command primarily useful for the sudoers group, because that group is allowed to run any command as root. However, if you add any custom rules, e.g. allowing any user to run updatedb with no arguments, then users outside the sudoers group need execute permission on sudo.

Also, there is not only su that is setuid -- there is also

• sg (allows temporarily joining a group if there is a group password set)
• passwd (allows changing the password)
• chfn (allows changing user information)
• chsh (allows changing default shell)

and several others. These tools share lots of code with the su command, so changing the mode of /bin/su alone will not buy you much, and changing the mode of all of them will certainly annoy your users, especially in the case of passwd.

Answer 3

On a hardened server, you want as few setuid/setgid binaries, especially such that can be run by a user account that does not need the particular tool, as possible - for one simple reason:

You do not absolutely trust these tools to police what someone does with them. Bugs in such programs or their dependencies that allowed users to circumvent such policing are frequently found, and actively sought for by security researchers and attackers. Misconfiguration (su behaviour is dependent on PAM library configuration) can cause the same problem. So every setuid/setgid binary a given (service or user) account can run is a potential vector to gaining unwanted root access.

While known problems in such software will usually cause patches/update to be available quickly, being forced to install them quickly can cause disruption - and some holes might not be known to everyone, including the vendor.

So to minimize the chance of an urgent problem to solve, it makes sense to do something like https://stackoverflow.com/questions/2189976/find-suid-and-gid-files-under-root, then research which of these can be done away with (most of them IF you are running a purpose-built server and know what you are doing), preferrably using methods like dpkg-statoverride that your package management systems supports for keeping such changes permanent.

There is another reason to restrict access to "su" in specific setups with old school NFS - you might, for essentially political reasons, restrict the root account (that some users might get for, again, political reasons. Bad practice nonetheless) from using su trivially, since it circumvents the root_squash flag of an NFS mount.