The problem with su and root

wukw

The problem with su and root
Current GNU/Linux distributions use the “su” model to elevate user priveledges. SU (or Substitute User) is a simple command which allows you to assume another identity on your pc. It’s most-often use is to become the root or administrative user. Both GNOME and KDE provide graphical tools which perform the same task, allowing you to install packages, change your resolution, and so on. I’ve been using su for many, many years now. Usually to become the root user.

The root account in unix is the holy-grail of hackers for a good reason. With it, you have absolute control of a computer. You can format disks, change any configuration file at whim, and you can remove any trace that those changes happened. Su and root violate the entire security principal of least priveledge.

To compensate, over the years I’ve come up with a variety of tools to allow me to track changes made while I’m the root user. I store my .bash_history, require comments be made on logout describing changes, and use a brightly colored red shell prompt to log commands and remind me that while logged in as root; I can do a lot of damage. The other problem with su/root is that I’m required to remember the root password for every computer I manage. As something of a security professional, this means I have to keep a record of a ton of different passwords.

About a year ago, I ran across a simple solution but didn’t realize it. I tried to solve a simple windows file sharing problem on my little brother’s OS/X machine. OS/X runs a variant of BSD underneath all the glitz and eye candy, so I figured I’d just login as root and fix up his samba config. It took me a while to realize exactly what was happening when my brother informed me that there was no “root” account. You had to use a tool called sudo.

I thought it was a wierd way of doing things, but I liked the idea of a unix machine without root. About six months ago I installed Ubuntu. Ubuntu doesn’t use the root account either. Like Mac’s it uses sudo to ensure that the proper person is making changes to the system. After getting “used” to not having a root account, I’m sold.

Why sudo?
Sudo is a tool that supports allowing users to use their own credentials for privilege escalation. No two passwords. No root user. Furthermore, sudo already supports granularity. If Linux distributions used sudo instead of su by default, you wouldn’t have to give out the root password to anyone who needed to become an administrator on a unix box.

In a nutshell, here are some of the features and reasons to use sudo:

Least privilege : Some users need to be able to change network configs, or shutdown the pc without root. Sudo allows specific users (or groups of users) to run specific commands, and not any others.
Logging : Every single command used through sudo is logged. This enables you to see who did what which is great from a security point of view, and essential from a troubleshooting point of view. When used in tandem with syslog, you can log all restricted commands to a central “log host”.
Timestamping : Sudo uses timestamp files to implement a “ticketing” system. When a user invokes sudo and enters their password, they are granted a ticket for 5 minutes. Each subsequent sudo command updates the ticket for another 5 minutes. This avoids the problem of leaving a root shell where others can physically get to your keyboard. There is also an easy way for a user to remove their ticket file, useful for placing in a .logout file.
Shared Configuration : Sudo’s configuration file, the sudoers file, is setup in such a way that the same sudoers file may be used on many machines. This allows for central administration while keeping the flexibility to define a user’s privileges on a per-host basis.
Root Shells : Sudo avoids the “I can do anything” interactive login by default - you will be prompted for a password before major changes can happen, which should make you think about the consequences of what you are doing. If you were logged in as root, you could just delete some of those “useless folders” and not realize you were in the wrong directory until it’s too late.
Script Kiddies : Every cracker trying to brute-force their way into your box will know it has an account named root and will try that first. What they don’t know is what the usernames of your other users are.
Box Ownership : Sudo allows easy transfer for admin rights, in a short term or long term period, by added and removing users from groups, while not compromising the root account.
A little fiction
Here is a typical scenario for the use of sudo which shows in practical terms, why GNU/Linux distributions should be using it by default instead of su and root.

Alice is a contractor who provides IT services and tech support for their customer, a small car audio service shop managing a number of Fedora desktops. The shop employs ten service techs, a manager, and a receptionist.

The techs all share workstations, or at least access to them. They have their own work areas, but in order to make troubleshooting easy, they frequently move around a lot and all of them have accounts on each other’s computers. They use a variety of applications related to their troubleshooting work, some which are customized not only for the shop, but for each tech’s specialty.

The manager uses typical office applications, but on a laptop. She connects to wireless networks at remote locations regularly, and as a result needs to be able to tweak network and wireless settings when away from the shop. The manager isn’t particulary pc savvy, and needs to be walked through configuration changes, sometimes on the phone without network access

The receptionist plays a lot of simple games like solitaire to pass the time on slow days. She quickly burns through them and is constantly installing and removing new games.

Alice was hounded constantly by the techs or the receptionist who needed to change screen resolutions or install (and ocassionally compile) their applications. She’d get calls at 5:00am from the manager asking for how to get on the wireless network at Starbucks. Eventually, Alice gave up and now everybody has the root password plastered to their PC on a sticky-note.

The tech’s (who were adept computer users) quickly began browsing through each other’s emails and generally begin to spy on each other. The receptionist began to break her configuration about once a week. And the manager had no concept of root and still calls for help.

Sudo solves a few of Alice’s problems. First, it allows the technicians to install applications from an internal repository, but denies them access to each other’s files and email. Second, the manager can now change her wireless settings without having to bother to login as root at all, eliminating some of the compexity of getting online. And thirdly, the receptionist can now install as many variants of solitaire as she wishes, without having to worry about breaking her computer’s configuration. And to top it all off, sudo can log every single command to syslog!

The Gory Details
So how can you apply all of this to your own GNU/Linux box? It’s pretty easy! First, install sudo if it’s not already installed. Now fire up visudo (as root) to edit your /etc/sudoers file. The syntax is pretty simple. To get started, try something like this.

root ALL=(ALL) ALL
cmauch ALL=(ALL) ALL
%users localhost=NOPASSWD: /sbin/mount /cdrom,/sbin/umount /cdrom
%users localhost=NOPASSWD: /sbin/shutdown -h nowReplace ‘cmauch’ with your username. Later on you can tweak. Save the file. Now disable the root account completely by typing this in.

passwd -l rootThis works by changing the root password to a value which matches no possible encrypted value. Now log out of root and login as yourself.

The next time you need administrator access to something, simply prefix any commands you want to run with sudo. EG:

sudo vi /etc/X11/xorg.confYou’ll be asked to confirm your own password, and shezam!, your running. A quick look at /etc/auth.log also shows the entire command logged. Eg:

Nov 25 03:30:33 redbox sudo: cmauch : TTY=pts/5 ; PWD=/home/cmauch ; USER=root
; COMMAND=/usr/bin/vim /etc/X11/xorg.confThe second example in the configution above shows how to begin to implement least priveledge. In a nutshell, this example allows users in the “users” group to mount and unmount the cdrom drive, and to shut down their pc without the root password or even a password prompt.

If you want to poke at a more complex configuration to look at, be sure to google sudo or check the sudo website.

Some Caveats and a Warning
Since your probably appying this change to a distribution that isn’t sudo friendly, keep the following in mind.

User accounts typically don’t have /sbin or /usr/sbin in the default $PATH. As a result, you may need to add those directories to a users’ path, or better - create a symbolic link between the command you’d like them to be able to use (/sbin/shutdown) and (~/bin/shutdown). In Debian in particular, if you plan on using apt-get, aptitude or deslect, you’ll need to have /usr/sbin in your path. Icky.

Some tools like webmin require both root access and a root password. There isn’t a great workaround for this except to perhaps use other tools which do not require root access. Besides, It is kind of creepy to allow any piece of software root access over the web.

When your filesystem becomes completely corrupted and your machine drops into single user mode on boot, you might find yourself locked out of your computer and unable to boot into single-user mode at all because this requires the root password. You can either patch sulogin to handle this, or you can do as I do and simply boot from a USB or CDROM drive to fix things up.