what does it mean to be setuid root?

Question

I am reading Tanenbaum's Modern Operating Systems 3e. He says "Suppose that the program being attacked [with malicious code] is SETUID root in UNIX (or has Administrator power in Windows). The [malicious code inserted with a buffer overflow attack] can now make a couple of system calls to convert the attacker's shell file on the disk into SETUID root, so that when it is executed it has superuser power."

What does it mean to be SETUID root? Does he mean that the program has root permissions? Why does he say that the program is setuid root?

This somewhat of a language question, but to a security noob with only basic linux/unix that passage in the book is hard to understand. What's he talking about?

Answer 1

SETUID means that the executable can run under different permissions than the user who has executed it.

Certain applications are set like this so the users can run with low permissions but a specific application they need to run with higher permissions can be.

SETUID 0 or root means that when the program is run it is as if root ran it - which leaves you open to all the usual security risks of running something at high permission levels - it could potentially do anything to your system - so generally the number of applications that require SETUID should be minimised on a Unix box. Most security audits of Unix machines include looking for SETUID and SETGID files that are world writeable as they present a high risk.

Answer 2

User accounts on unix-like systems are identified by a UID (user ID).

A process can be associated with more than one UID. The two main ones are the "real UID" which identifies who owns the process and the "effective user UID" which identifies what user's permissions the process currently operates under*.

"setuid" in this context refers to a file permission bit (it is also the name of a related system call). When it is set on an executable file and that file is executed then the "effective UID" is changed to the owner of the file. This means that the program runs with the permissions of it's owner rather than the permissions of the user that ran it.

When we say an executable file "is setuid root" then we mean it has the setuid bit set and is owned by the user 0 (root). So it will run with an effective UID of 0 and can basically do whatever it wants.

The "real UID" remains the same, so the program can identify the user that ran it and can switch back to that user if desired.

setuid programs are/were an important part of unix systems allowing functionality to be exposed to users where the function as a whole is considered safe for the user to use but the building blocks used to implement those functions are not.

However they are also risky, a small mistake in a setuid program can easily expose more than was meant to be exposed. Various debugging related features are also disabled for setuid programs to prevent them being used to bypass the restrictions.

In recent times Linux systems have been replacing some uses of "setuid" with a new mechanism called "capabilities" which allows for finer-grained allocation of special privileges to programs.

There has also been a push, particularly on the desktop, to move away from the model of a user executing a process with elevated privileges and instead have the user make a request to a process that it already running via dbus/polkit. The advantage of this approach is that the user only controls the content of the request and not the overall execution environment of the code.

* There are potenially others too, but they aren't immediately relavent here, see http://man7.org/linux/man-pages/man7/credentials.7.html for more details.