Introduction

While in IT Security back in 2008, our IT system operations team managed UNIX systems in way's I that thought to be abolished a long time ago: Using 'telnet' to connect directly, all user ID's shared the single UID 0. I attempted the adoption of safer alternatives, outlining good reasons (below).

Today, five years later insecure practices still exist. Although software and OS vendors continuously improve and enforce of basic security standards out of the box, IT staffing constraints leads to shortcuts whereever possible. As a result, memo's like this are not getting obsolete, and publishing it could help in continously making the case for sound system administration.

Sharing the Root in UNIX: The "bad", the "not-so-good", and the "OK" way

Got Root? T-Shirt

"Root" is the name of the single, most powerful system account in a UNIX operating system. Because it has unlimited rights, protecting this access is crucial to ensuring sound, safe system operations. The importance of this account is so obvious, the IT community even created T-shirts with the taunting question: got root?

The problem today: Organisations need to dedicate specialized teams to providing system operation support. As a result, a increasing number of engineers need to safely co-operate as "root".

  1. The "bad" way: Sharing uid=0

    The simplest form of letting multiple users work as "root" is to give them all the same user id: "UID=0". This is possible because in UNIX, nothing prevents you from creating multiple user records that share a single user ID. It works.
    Why is this "bad"? In operating systems, user names are translated into numeric user ID's, which are the base for identifcation and privilege granting. In UNIX operating systems, the standard ID for "root" is defined as '0'. Since all account activity is done by UID rather then by account name, sharing this ID makes it impossible to tell "who did what". For example log records, or newly created files will not carry the correct user name. It get's worse when multiple "UID=0" users log in together.
    Finally: In Unix, passwords are assigned to account names, rather then UID's. That means instead of just having a single root password, we are now having several to protect. Compromising just one of them will compromise the whole system. Those of you with "UID=0", ask yourself: Do you have a good password? Not all do.

    Here I typically refer to specific system examples. On a critical DB server hosting the main customer data, no less then 18 (!) users shared the "root"-uid, including the whole operations team, developers, and a few more. Out of these 18, four had passwords like "abcd12" or "password1", effortless to compromise.

    By sharing the UID=0 in user accounts, remote login cannot be restricted for the "root" account, because it would prevent these users from logging in over the network. However exposing the "root" login over the network increases the risk, making it directly acessible to anybody in our LAN, rather then the limited number of local users on this server.

    Additional Information

    susie114:~ # cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
sshd:x:100:101:SSH daemon:/var/lib/sshd:/bin/false
wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false
frank4dd:x:0:0:Frank Me, #567742:/home/frank4dd:/bin/bash
gmeyers:x:0:0:George Meyers, #734391:/home/gmeyers:/bin/bash
...

    In UNIX, the file /etc/passwd "links" user account names to the system's UID and GID (located in column 2/3). Above, two additional accounts are made "root".

  2. The "not-so-good-way": The 'su' command

    Another way to provide access to the privileged root account is using 'su', and sharing the "root" password among system administrators. With knowledge of the "root" password, the system-builtin "switch user" command can be used by local users to become "root". Using the 'su' command keeps a log record, showing who became "root", and when. This is already much better then sharing "UID=0", but still flawed for todays teamwork. Sharing a single password is very difficult to control. Changing the password and letting everyone know securely isn't easy, and with a large enough group, how do we keep this password secret?

  3. The "OK" way: Using the 'sudo' command

    The most common and flexible way of delegating system privileges is using the 'sudo' command. Here, administrators are normal system users without a shared ID or shared password. For "root" access granting, their user name is added to the 'sudo' access list (/etc/sudoers). When needed, these privileged users simply prepend the system command with the word "sudo", and the command will be executed as "root". Ultimately, it is posible to start a new shell via sudo, and operate continously as "root". 'sudo' requests the users own password before execution, thus adding another layer of security. It also creates log records, just like 'su'. Using 'sudo' became quickly a standard, and the well-known Linux distribution "Ubuntu" completely eliminated the "root" account, requiring all system administration being done through 'sudo'. 

    susie114:~ # cat /etc/sudoers
...
# User privilege specification
root         ALL=(ALL) ALL
frank4dd     ALL=(ALL) ALL
gmeyers      ALL=(ALL) ALL
...

    Example entries in /etc/sudoers, granting the privilege of command execution under all user accounts, including "root". While this is a very basic setup, 'sudo' has a quite fine-grained control mechanism for limiting access to resources, it's manual pages (URL's below) list numerous examples on how to configure it for specific cases. Especially for larger user groups with mixed roles, it makes sense to make an effort creating granular delegation rules.

    Separating 'sudo' log records

    It is good practise to separate the 'sudo' log records into a dedicated log file. By default, 'sudo' logs into the standard log system 'syslog', using the auth facility. Syslog itself typically creates a system-wide logfile such as /var/log/messages, combining log records from a variety of system services. This creates some more effort to filter and review.
    By defining the logfile parameter in the 'sudoers' configuration file, we can separate the 'sudo' records. A different way of separation can be achieved through the default syslog mechanism, defining a dedicated syslog facility for 'sudo', such as local0. Using syslog can have advantages through integration into a centralized logging system, sending sensitive log records such as 'sudo' in a safe, central place. Regardless of the method, it is a good idea to keep a local copy, adding file rotation to manage the size, while creating a meaningful filename index by date.

Summary

Most organisations adopt "Hardening" or "Secure Operations" standards which include rules for granting, using and protecting privileged "root" access. Some companies go beyond 'sudo': Implementing one-time password (OTP) granting software for privileged access, or replacing passwords with two-factor authentication tokens, such as SecurID.

While it is debatable how much is "enough", technology alone is not able to address all. Sound practise on multiple levels, understanding the why and how while using the system-builtin tools can go a long way. Disabling remote "root" access, setting decent "root" and user passwords, refine logging, choosing secure, encrypted access protocols (i.e. SSH) and keeping up with patch updates is a good combination.

Manual pages around sudo

Complementary security practises

Source:

Content:

See also: