jump to navigation

Making your linux install more secure. Part I: The setuid bit December 7, 2008

Posted by haskelladdict in Linux.
Tags: , ,
trackback

Admittedly, when it comes to computer security I am a bit of a fanatic. Unfortunately, even small improvements in overall security can often be time consuming to implement and will typically cause more than less inconvenience to users. Hence, one has to strike a balance between how much security to enforce versus how much inconvenience users can be expected to tolerate in their daily use. Fortunately, there are a number of security improvements that can be put into place quite rapidly with minimal impact to the user. This column will focus on one of them: Ridding your Linux install of unnecessary setuid root files.

Let’s first look at what setuid files are and why they may pose a security risk. When running a program, firefox say, the kernel creates a process with a certain set of permissions that control what the process can and can not do during its life time. Most importantly, this includes file, device, or network access permissions. A process’ permissions are controled inside the kernel by its user ID (uid) and group ID (guid). For each process, the kernel actually tracks several uids/gids. To simplify the following discussion we will only consider the real and effective uids (the discussion for gids is similar). Under normal circumstances the real and effective uids are identical and equal to the uid of the user who started the process. Hence, if user Susan with uid 1000 starts firefox, the resulting process will have a real and effective uid of 1000. Whereas the real uid only tracks who started the process, the effective uid controls, for example, which files the firefox process can read, write, or execute, namely, exactly those files that user Susan with uid 1000 can read, write, or execute. If the firefox process tried to write to a file with the following permissions

-rw-r–r– 1 root root 3.1K 2008-11-24 08:48 /etc/rc.conf

this would result in a permission denied since uid 1000 can not write to /etc/rc.conf owned by root who has uid 0.

This is of course a good thing since it forces processes to interact with files (and other system resources) according to the policies imposed on the user who started the process in the first place. However, sometimes this poses a problem: Imagine that a user would like to change her password using the passwd command. In order to do so, the passwd command has to be able to write to the password file /etc/passwd which in turn requires write permissions for the user. Clearly, we can not allow users to arbitrarily write to /etc/passwd since this would constitute a big security hole in our installation (imagine a user erasing the content of /etc/passwd). Not all is lost though, because fortunately we don’t need general write permissions for /etc/passwd, only the passwd command somehow has to be able to write to the file, nothing else.

This is where the setuid bit comes in handy. It can be enabled via chmod by setting the highest order octal to 4 (e.g., chmod 4744, will set read, write, and execute permissions for the owner with the setuid bit set, and read permissions for group and others, respectively; alternatively, chmod u+s can be used to set the setuid bit). Here’s what the permissions for the passwd command might look like on your system

# ls -la /usr/bin/passwd
-rws–x–x 1 root root 37K Nov 26 12:31 /usr/bin/passwd

As you can see, the setuid bit is set as indicated by the s in the user permissions instead of the usual x. So what does it do? Well, if an executable file with setuid bit enabled is executed, the resulting process will run with an effective uid corresponding to the owner of the file, rather than the user who started it. Since the user will still be the one determining the real uid the real and effective uids will now be different. Hence, if Susan decided to change her password by starting the passwd command, the real and effective uids of the process would be 1000 (i.e., Susan’s uid) and 0 (i.e., root’s), respectively. Since the effective uid determines what a process can do, Susan’s passwd command effectively acts as if executed by root, and can therefore write to /etc/passwd which is exactly what we wanted it to be able to do. Great!

Unfortunately, there is a downside. Since setuid root processes have the same power as root itself, one has to make absolutely sure that these processes can only be used for their intended purpose and nothing else. Should a malicous person succeed to trick one of these setuid root executables into doing something else, bad things could happen. In effect, this would provide her with the same priviledges as hacking into the root account itself. Hence, setuid root binaries need to be especially well designed to make sure that these things can’t happen. Two corollaries follow:

  1. The smaller the number of setuid root executables, the better.
  2. If you are thinking about making one of your own binaries/scripts setuid root make absolutely sure that they are safe and can not be exploited by a third party. Did I mention that setuid root files are bad?

This brings us back to the main topic of this post. Many Linux distributions by default often come with a significant number of setuid root executables most of which don’t really need this priviledge at all. A simple

# chmod u-s

will remove the setuid bit and quite possibly make your system a bit more secure. Which binaries need to be kept setuid root depends a little bit on the circumstances, but typically their number will be less than a handful. E.g., on a single user system where the user has the ability to become root anyways almost no binaries need to be setuid root with the exception of su and sudo, perhaps. On a multi user system it might be convenient to have commands like passwd, mount, and umount be setuid root. In any case, think twice before making/keeping a binary setuid root.

To determine all setuid (and setguid) binaries on a system you may find the script below helpful. It will search the filesystem for setuid/setgid files and list them in ~/suidfiles.txt. You can then go through the list and decide which ones to keep (hopefully not very many) and which ones to convert into regular executables.

#!/bin/bash

/usr/bin/find / -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \; 2>/dev/null > ~/suidfiles.txt
Advertisements

Comments»

1. Rahmathulla - March 13, 2009

brilliant ! more helpfull for me. thanks.

2. nolamiami - July 28, 2009

thanks! setuid finally makes sense


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: