Unix permissions, ownership and setuid

File security and ownershipThe chmod(1) commandProcess OwnershipSetuid, Setgid and the Sticky bitWriting setuid programsAn attack on a setuid program

File security and ownership 1

Up to 216 or 232 userids can be created for a Unix system. Each user has a unique UID number and a unique username in the passwd(5) database file, used to control login security. UID numbers start at 0 and work upwards. Normally low UID numbers are reserved for programs and services with human users starting at 500 or 1000.

The same one to one correspondence exists between group names and GIDs, see group(5). Files and processes also belong to a specific userid and group. This determines who is allowed to do what to a file or directory, and which files a particular process is allowed to read, write or execute.

File security and ownership 2

The system uses the UID and GID as 16 (or 32) bit numbers internally, and resolves references to the userid and group names using the /etc/passwd and the /etc/group files. Some systems e.g. NIS use network wide passwd and group maps which have the same format.

The names are used when displaying this information to the user, for example when you use the ls -l or the ls -lg commands. Normally UID 0 is reserved for root, who has system administrator privileges.

File security and ownership 3Using the ls -l command, the first 10 character directory

column describes the file type and permissions. For the first character a - (hyphen) indicates a plain file, d a directory and l a soft link.

The remaining 9 characters are split into 3 components of 3 characters each, to describe the user's, group's and others' privileges respectively. Within each 3 character triplet, the first indicates read permission, the second is for write permission and the third is for execute permission. If the r, w or x character is present, the permission is allowed, if the position is occupied by a - (hyphen) the permission is denied.

Directory Rights

On a directory, the x permission means something different from the ability to execute a file. Directories can't be executed. Here the x permission means the ability to search through, or traverse a directory to access subdirectories, whether or not you are allowed to read the directory being traversed. Being allowed to write to a directory enables files to be renamed, or deleted within it.

File Permission Examples

Sharing data on a multiuser system

Giving write access on your own directory isn't a safe way to share data. This gives the ability to do anything (accidently or deliberately) to any of the contents of the directory.

If you want to share your files, allocate read and execute permission to the directory and read permission to your files. Others can then read them or copy them into their own directories. System default permissions may not suit local needs.

A multi-user open system in an academic environment is not very secure, but some protection can be given by putting files into a directory to which only you have access.

The chmod command 1

File permissions are assigned using the chmod command. This can be used in one of two ways. Some users prefer to give the octal 3 digit mode, others prefer to use the character equivalents.

Examples using octal modes:

chmod 421 f1 assigns permissions r---w---x to f1chmod 750 f1 f2 assigns permissions rwxr-x--- to f1 and f2

Each octal digit adds 4 for read, 2 for write and 1 for execute permission. The first digit is for user, second for group and the third for others.

The chmod command 2

Examples using mnemonic modes

Process Ownership

In this example, the ps command was used to display the UID, PID, GID, (i.e. user, process and group identities) run

status and command for processes on the system.

rich@saturn:~/work/dsalg/c$ ps -eo uid,pid,gid,stat,cmd

501 21157 501 R+ ps -eo uid,pid,gid,stat,cmd 33 23592 33 S /usr/sbin/apache2 -k start 0 26005 0 S spamd child 501 27532 501 Sl ktorrent -caption KTorrent

Process ownership inheritance and setuid

Security is maintained by child processes normally inheriting the UID and GID ownership fields from their parents, so every process you create while logged in normally has your user and group privileges.

The login(1) program is an exception to this rule. Some programs also use the setuid(2) or setgid(2) privileges so that they run with different real and effective UIDs or GIDs. This allows system administrators to create privileged programs to enable other users to access files etc. in the manner controlled by the privileged program.

Setuid, Setgid and the Sticky bit

On some directory listings you may see s, S or t characters instead of the x (execute permission) indicating use of setuid, setgid or sticky bit. Setuid and setgid applies to programs such as passwd(1) or procmail(1), which run with the privilege of the program owner, or group owner, and not the program user which would otherwise be the case.

The sticky bit is used on directories such as /tmp where all users have write access, but not to each others' files.

Setuid example

rich@saturn:~$ ls -l /usr/bin/passwd

-rwsr-xr-x 1 root root 27132 2006-07-11 13:51 /usr/bin/passwd

When a user changes their own password using the passwd command, this program is run by the user, but runs with the UID of its owner (root).

Setgid examplerich@saturn:~$ ls -l /usr/bin/procmail

-rwsr-sr-x 1 root mail 68152 2005-05-03 03:10 /usr/bin/procmailrich@saturn:~$ ls -l /var/mailtotal 15652-rw-rw---- 1 rich mail 15984976 2006-10-18 20:03 rich-rw-rw---- 1 test mail 1810 2006-10-15 08:20 test-rw-rw---- 1 rich mail 4333 2006-09-26 07:00 trap

When user1 uses procmail to send an email to user2, procmail needs to be able to write to the mail spool (/var/mail/user2) of the other user, which has group ownership of mail and group write access. The write access by user1 to user2's mailbox is restricted to what the procmail program is programmed to do, i.e. deliver a message.

Sticky bit example 1rich@saturn:~$ ls -ld /tmpdrwxrwxrwt 13 root root 4096 2006-10-18 10:43 /tmp

Everyone on the system can write files to the /tmp directory.

rich@saturn:~$ echo hello > /tmp/hellofrich@saturn:~$ ls -l /tmptotal 3-rw------- 1 pete pete 6 2006-10-18 10:55 scratch-rw-r--r-- 1 rich rich 6 2006-10-18 10:52 hellofdrwx------ 3 root root 4096 2006-10-18 10:39 872388287423rich@saturn:~$ cat /tmp/scratchcat: /tmp/scratch: Permission denied

Sticky bit example 2

rich@saturn:~$ rm /tmp/scratchrm: remove write-protected regular file `/tmp/scratch'? yrm: cannot remove `/tmp/scratch': Operation not permittedrich@saturn:~$ rm /tmp/hellofrich@saturn:~$

In practice, programs which use /tmp for temporary storage tend to name files there in such a manner that other users of /tmp are very unlikely to want the same names. Typically, contents of /tmp are automatically removed, e.g. on reboot or after they have not been accessed for a certain number of days.

Writing Setuid programs 1

On occasion it will be necessary to write a program to enable ordinary users to carry out specific work, e.g. reading or writing from a particular file or database, that requires privileges belonging to root or a less privileged user or group.

In general, try to design the application to minimise the privilege needed. E.G, in the above example, mail spools are writeable by the mail group. If the job can be done using Setgid permission using a specialised group this is safer than using Setuid.

Writing Setuid programs 2

If the job to be done requires an interpreted script, this should never be made setuid or setgid directly. This is because running a script involves running 2 programs, with a likely and unknown delay between the 2.

Firstly when the kernel identifies the first 2 characters (#!) of a script it will take the rest of the first line as the path of the interpreter to execute. Secondly the kernel will load and execute the interpreter and pass the pathname of the script to the interpreter, and the interpreter will interpret and run the script.

Exploiting the race condition 1

A local attacker can exploit the delay between the first and second stages by changing the script, accessing it through a link belonging to the attacker.

This kind of vulnerability is called a race condition - the security of a system depends upon which of 2 activities completes first. The attacker needs to change the contents of a link after the first stage, and before the second.

Exploiting the race condition 2This can be done by the attacker creating a soft link in /tmp or

elsewhere to the setuid script, executing the setuid shell and then changing the contents of the link before the script is executed. If the attacker can arrange for the system to become heavily loaded between stages 1 and 2, e.g. by running some very demanding programs, he or she will have plenty of time to change the target of the link before the program is loaded and interpreted.

The attacker has to write 2 exploit scripts. The exploit he wants to run with higher privileges must use the same scripting language as the setuid program. The other script will create the symlink, execute the setuid script through this, and then change the target of the symlink quickly enough to win the race and then remove the evidence.

Designing a specially privileged script to run securely

See the HTML version of these notes for the worked example showing the source codes for a compiled setuid

'C' wrapper and shell script to be run with root privileges.

These notes also show all the commands used and describe some of precautions which need to be taken, e.g. to validate and size all input data and avoid taking input e.g. from environment variables which a malicious user could manipulate.

Making the wrapper program setuid

The chmod u+s wrapper command used by root enables the compiled wrapper program to be run by ordinary users, but to run as root with root privileges.

This is an example of privilege increase. In some other situations, a program e.g. login starts running as root, but wants to execute a program with ordinary user privileges, e.g. the user's login shell. This involves a privilege decrease.

setuid and setgid system calls

These 2 functions (or system calls) are used when a program starting as root can run more securely with reduced privileges as another system user.

This facility enables many of the system services to run within a user identity created for the purpose of the service. Typically a server program needs to start as root to use a low network port number. A good example is the webserver Apache, which might usefully run as many different users running different virtual servers on a shared host.

Further ReadingWhen you have time, read the following system manual pages. Pages

not on your system can be found on: http://linux.die.net/man/

chmod(1) changing permissions on a file

setuid(2), setgid(2) setuid and setgid system calls

passwd(5), group(5), shadow(5) security configuration files

login(1), passwd(1)privileged commands enabling login and password changes

http://bcu.copsewood.net/sectheory/permissions/permissions.htmlworked example showing creation of a setuid application.