Unix permissions, ownership and setuid

1
Unix permissions, ownership and setuid

• File security and ownership
• The chmod(1) command
• Process Ownership
• Setuid, Setgid and the Sticky bit
• Writing setuid programs
• An attack on a setuid program

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

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

4
File security and ownership 3

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

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

6
File Permission Examples
7
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.

8
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
  f1
• chmod 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.

9
The chmod command 2

• Examples using mnemonic modes

10
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_at_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

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

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

13
Setuid example

• rich_at_saturn ls -l /usr/bin/passwd
• -rwsr-xr-x 1 root root 27132 2006-07-11 1351
  /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).

14
Setgid example

• rich_at_saturn ls -l /usr/bin/procmail
• -rwsr-sr-x 1 root mail 68152 2005-05-03 0310
  /usr/bin/procmail
• rich_at_saturn ls -l /var/mail
• total 15652
• -rw-rw---- 1 rich mail 15984976 2006-10-18 2003
  rich
• -rw-rw---- 1 test mail 1810 2006-10-15 0820
  test
• -rw-rw---- 1 rich mail 4333 2006-09-26 0700
  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.

15
Sticky bit example 1

• rich_at_saturn ls -ld /tmp
• drwxrwxrwt 13 root root 4096 2006-10-18 1043
  /tmp
• Everyone on the system can write files to the
  /tmp directory.
• rich_at_saturn echo hello gt /tmp/hellof
• rich_at_saturn ls -l /tmp
• total 3
• -rw------- 1 pete pete 6 2006-10-18 1055
  scratch
• -rw-r--r-- 1 rich rich 6 2006-10-18 1052
  hellof
• drwx------ 3 root root 4096 2006-10-18 1039
  872388287423
• rich_at_saturn cat /tmp/scratch
• cat /tmp/scratch Permission denied

16
Sticky bit example 2

• rich_at_saturn rm /tmp/scratch
• rm remove write-protected regular file
  /tmp/scratch'? y
• rm cannot remove /tmp/scratch' Operation not
  permitted
• rich_at_saturn rm /tmp/hellof
• rich_at_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.

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

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

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

20
Exploiting the race condition 2

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

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

22
Making the wrapper program setuid

• The chmod us 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.

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

24
Further Reading

• When 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/per
  missions.html
• worked example showing creation of a setuid
  application.