6

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?

bernie2436
  • 1,437
  • 10
  • 22
  • 29
  • "The setuid and setgid bits are normally set with the command chmod by setting the high-order octal digit to 4 (for setuid) or 2 (for setgid). "chmod 6711" will set the setuid and setgid bits (6), make the file read/write/executable for the owner (7), and executable by the group (first 1) and others (second 1). All chmod flags are octal." -wikipedia – adric May 02 '12 at 20:45

2 Answers2

8

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.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • So it might be better to say the program "has" setuid root? (Meaning that it has permissions to run as root). – bernie2436 May 02 '12 at 15:01
  • 2
    It's just terminology, I think. I have only ever heard "application x **is** SETUID root" so I think that is the accepted usage. – Rory Alsop May 02 '12 at 15:03
  • Although this is very old, I'd add this point - perhaps the usage comes from the option's name. "application x is set [with] uid = root" – Stilez Apr 03 '18 at 05:47
0

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 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.

Peter Green
  • 4,918
  • 1
  • 21
  • 26