Ownerships and permissions details

Identities and accounts

Notions of identity and accounts:

• If authenticated it is an identity, if authorizes it is an account; root is an identity (authenticated by password, SSH private key, Kerberos ticket, ...), id 0 is an account.
• /etc/passwd and /etc/group authorize an identity to one or more accounts.
• /etc/shadow and /etc/gshadow identify a user to some identity.
• Gids and group names are in effect shared uids and user names.
• Identities are proven by password for both user name and group names except for default group names. Password authentication for group names almost never used.
• Accounts, that is uids and gids, are defined administratively and give access to kernel resources primarily.
• In UNIX user names (identities) are purely a matter of convenience, no system calls take user names.
• Identities give access to accounts, accounts may give access to resources (inodes) in other accounts, subject to authorization; both are security tokens, distinction exists to avoid authenticating on every access.

tree$ id
uid=1(pkg) gid=1(pkg) groups=1(pkg)

tree$  sudo getent shadow root
root:$6$cd0BQ.O0$JjUkqeTW1Cg6iri3SZMZfDoVLghGbc4vnyFqFb69CPdwHoyUkmuW2.hZYQgcNYyr9RGXgklSTAdYvtsAFiMPP0:16794:0:99999:7:::
tree$  getent passwd pkg
pkg:x:1:1:pkg:/home/pkg:/bin/bash
tree$  getent group ssl-cert
ssl-cert:x:107:postgres,prayer,freerad,yaws

Processes and state passing

Processes don't share state:

• Process data and metadata copied on fork.
• Process data: code, static, stack, environment.
• Process metadata (explained later): ruid, rgid, euid, egid, umask, limits, root directory, current directory, mount directories, file descriptors ...
• Tree of processes with inheritance-by-copy.

Process state details

Process state:

• Can change their copy of metadata and data.
• Cannnot change ruid or rgid. Can change euid to ruid or egid to rgid, or can change euid or egid to anything if ruid is 0.
• This because (effective) euid and egid are used for inode access, (real) ruid and rgid are used for kernel resource (CPU quota, memory quota, disk quota, ...) access.
• Cannot change (without strange mechanisms) other process data or metadata, neither parent nor child, once forked.
• All shared state is in files (with some apparent exceptions).
• Most processes only set their metadata at the start by inheriting a copy from their parent, or reading some shared file, need to restart to change metadata (difference between profile and env).
• File permissions apply only at open(2) or exec(2) times; passed file descriptors still remain valid even if inode permissions change later or ownership (of inode or process) changes.

tree$  ls /proc/1/
attr             cpuset   limits      net            projid_map  stat
autogroup        cwd      loginuid    ns             root        statm
auxv             environ  map_files   numa_maps      sched       status
cgroup           exe      maps        oom_adj        schedstat   syscall
clear_refs       fd       mem         oom_score      sessionid   task
cmdline          fdinfo   mountinfo   oom_score_adj  setgroups   timers
comm             gid_map  mounts      pagemap        smaps       uid_map
coredump_filter  io       mountstats  personality    stack       wchan

tree$  sudo ls /proc/1/fd
0  1  11  13  14  15  17  2  20  22  23  25  29  3  32  4  5  6  7  8  9
tree$  sudo sh -c "tr '\0' '\n' < /proc/1/environ"
HOME=/
init=/sbin/init
recovery=
rootfsflags=inode64
TERM=linux
BOOT_IMAGE=/boot/vmlinuz-4.2.0-22-generic
PATH=/sbin:/usr/sbin:/bin:/usr/bin
PWD=/
rootmnt=/root

tree$  PID  PPID  EUID  RUID  EGID  RGID SUPGID               TPGID  SESS COMMAND
...
17025     1  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24 16966 16960 /usr/lib/kde4/libexec/start_kdeinit +kcminit_sta
17026     1  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17026 kdeinit4: kdeinit4 Running...                   
17027 17026  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17026  \_ kdeinit4: klauncher [kdeinit] --fd=9        
17050 17026  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17026  \_ kdeinit4: ksmserver [kdeinit]               
17052 17050  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17026  |   \_ kwin HISTFILESIZE=300 KDE_FULL_SESSION=t
17144 17026  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17026  \_ /usr/bin/xsettings-kde HISTFILESIZE=300 KDE_
17150 17026  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17026  \_ /usr/bin/alarm-clock-applet --hidden HISTFIL
17151 17026  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17151  \_ /usr/bin/python /usr/bin/hp-systray -x HISTF
17239 17151  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17151  |   \_ /usr/bin/python /usr/bin/hp-systray -x H
17240 17239  2048  2048  2048  2048 0,1,1,2,4,5,6,7,8,24    -1 17151  |       \_ /usr/bin/python /usr/bin/hp-systray 
...

Inodes and account permissions

Inodes have (owning) ouid and ogid and permission list as per /usr/include/linux/stat.h:

• For processes running on the same kernel instance, kernel provides files both as permanent storage or as shared communication channel, for unrelated processes, and manages access control on behalf of accounts.
• octal because of PDP-11 convention, also each octal digit represents neatly 3 bits. I always put a leading zero to ensure it is read as octal.
• 0SUGO, that is 12 bits: 16 bit PDP-11 word, and the other 4 bits are type of inode.
• Very special rules apply to S permissions, and somewhat special to UGO permissions for directories.

tree$  stat /
  File: ‘/’
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 806h/2054d      Inode: 96          Links: 45
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-04-04 21:13:38.274908537 +0100
Modify: 2016-01-05 22:17:10.186991926 +0000
Change: 2016-01-05 22:17:10.186991926 +0000
 Birth: -

Account permissions details

File inodes don't have names:

• On execution only:
  • uid special (s 04): set process euid to ouid
  • gid special (s 02): set process egid to ogid
  • other special (t 01): optimize loading
  Upper case of the special permissions has special meaning.
• Plus (U, G, O):
  • read 04
  • write 02
  • exec 01

tree$  ls -ld /var/log/messages /usr/sbin/uuidd
-rw-r-----  1 root adm  76620068 Jan  8 08:03 /var/log/messages/
-rwsr-sr-x  1 libuuid libuuid 21584 Sep  2 19:35 /usr/sbin/uuidd

Specific permission types

Directory inodes are collections of directory entries:

• On creation or removal only:
  • uid special (s 04): no effect
  • gid special (s 02): inherit ogid
  • other special (t 01): only owning id can remove
  Upper case of the special permissions has special meaning.
• Plus (U, G, O):
  • list (r 04)
  • add/remove (w 02)
  • search/resolve (x 01)

tree$  ls -ld / /var/tmp /var/mail
drwxr-xr-x 45 root root     4096 Jan  5 22:17 /
drwxrwsr-x  2 root    mail       52 Jan  8 07:57 /var/mail
drwxrwxrwt 31 root    root     8192 Dec 31 21:22 /var/tmp

Default permissions

Inode permissions setting:

• Default to 00666 for files, 00777 for directories unless explicit.
• But at creation time defaults turned off selectively with per-process umask.
• Special rules for changing special permissions.
• The umask usually defaults to 00022 (group and others can read), will default to 00006 (group can read or write, others can only search/execute), some default it to 00066 or 00067.

tree$  echo 'default' > file
tree$  ls -ld dir file
tree$  mkdir dir
drwxrwxrwx 2 pg pg 40 Jan  8 08:14 dir
-rw-rw-rw- 1 pg pg  8 Jan  8 08:14 file

tree$  umask 0006
tree$  mkdir dir2
tree$  echo 'umask 00006' > file2
tree$  ls -ld dir2 file2
drwxrwx--x 2 pg pg 40 Jan  8 08:15 dir2
-rw-rw---- 1 pg pg 12 Jan  8 08:15 file2

Permission checking

Process to inode permission checking:

• Permission checks in this order, to inodes:
  • euid is the same as ouid, check U
  • egid is the same as ogid, check G
  • neither euid nor egid matches ouid and gid, check O
• This means that permission denied if euid same as owning gid and permissions missing even if permissions allow egid or neither, and similarly for egid.
• A proces with euid not equal to 0 cannot change the ouid of a file, but a process with euid equal to the ouid and one of the egids equal to the ogid can change the ogid of a file to any of its egids.

tree$  chmod ug=,o=rw file; ls -ld file
-------rw- 1 pg pg 8 Jan  8 08:14 file
tree$  cat file
cat: file: Permission denied
tree$  sudo -u pkg cat file
default

Identity to account defaults

Typical setups:

• 1 user name has:
  • unique uid
  • shared primary gid
  • optional shared secondary gids
  Used to be the default.
• 1 user name has:
  • unique uid
  • unique primary gid
  • optional shared secondary gids
  It is the current default to allow the default umask to give group permissions, as for example in 00006 instead of 00066, so that secondary groups work by default.
• Several user names have same uid, same primary gid (quite rare). Can have different shell or home directory for example.
• Several user names have same uid, different primary gid (exceedingly rare).

Mutual distrust

The biggest problems are dynamic accesses among accounts and mutual distrust:

• Uids define disjoint protection domains.
• Uid disjoint domains are crossed through either other permissions or via owning group permissions and shared gids (triangulation, bank shot, stepping stones), potentially a chain: uid1-gidA-uid2-gidB-uid3-...
• Original design: set-uid and set-gid executables were meanto help this crossing.
• Current misdesign: uid 0 is used as universal crossing way, so chain looks like uid1-root-uid2-root-uid3-....

Typical solutions

Typical crossing problem where uid 1 and uid 2 want to send/receive data such that only the other can read/write it, and neither gives access to more than needed:

• If uid 1 and 2 known in advance or few, create common gid A, then uid 1 create file with permissions 006[246]0 and sets ogid A, then uid 2 can access it. This does not require mutual trust.
• uid 1 creates directory with 00633 permissions, uid 2 creates random file name in it with permissions 00666, sends name to uid 1 (ha!), uid 1 can write to it even if ouid and ogid don't match its euid or any of its egids.
• Relying in directory permissions protects the directory entry (link) from disclosure, if uid 1 wants to create another directory entry then anybody could access it.
• Only if uid 2 trusts uid 1, uid 1 creates a set-euid executable, which then is started by uid 2 thus with euid 1 and ruid 2. It creates a file with ouid 1, opens it, then sets euid to 2, and then can accesses it via the file descriptor, while being able to access files accessible to euid 2 files.

tree$  ls -ld /usr/sbin/exim4 /var/spool/mail/ /var/spool/exim4/
-rwsr-xr-x 1 root        root        983296 Feb 25  2014 /usr/sbin/exim4
drwxr-x--- 5 Debian-exim Debian-exim     40 May 24  2015 /var/spool/exim4/
drwxrwsr-x 2 root        mail            52 Jan  8 07:57 /var/spool/mail/

The one to many cases

One to many case case not symmetrical:

• For uid 1 receiving data from any other uid N same as before: one directory or one set-euid executable with ouid 1. For example: a mail transport agent or a printer spooler runs as uid 1. Which is trusted by any uid N.
• For uid 1 sending data to any other uid N inconvenient: needs many delivery directories or many delivery set-uid programs. For example: mail delivery agent.
• In practice 1 to many uids N means using uid 0 as intermediary, for example:
  • Uid 1 creates an executable with permissions 00755, that is this able to switch euid between 1 and N.
  • A user with euid 0 that trusts uid 1 changes its owning user to uid 0 and permissions to 00755.
  • Then uid 2 can start it euid 0 and ruid N, and then it can prudentially switch to euid 1 first to read the data, and then to euid N to write the data to a file with uid N, typically inside a directory with ouid 1.

tree$  ls -ld /usr/bin/{mlocate,procmail,bsd-write}
-rwxr-sr-x 1 root tty     17328 Jun  4  2013 /usr/bin/bsd-write
-rwxr-sr-x 1 root mlocate 42176 Jun 20  2013 /usr/bin/mlocate
-rwsr-sr-x 1 root mail    91816 Sep  4  2014 /usr/bin/procmail

tree$  ls -ld /var/lib/mlocate/mlocate.db 
-rw-r----- 1 root mlocate 25427311 Jan  8 07:35 /var/lib/mlocate/mlocate.db

Dynamic many-to-many

The big problem is arbitrary many-to-many mutual distrust: uid 1 and uid 2 want to exchange data but neither will execute a set-euid file with ouid of the other, and there is no common group:

• Ideally euid/ruid distinction for files, instead of single ouid: then uid 1 creates inode with permissions 00600 and writes data to it, and then sets its euid to uid 2, and uid 2 then can read it. This does not exist.
• Both uids cannot but trust running a set-euid executable with ouid 0, and that can read the data from a file with ouid 1 and write the data to a file with ouid 2 and viceversa. So for example the command chownx for passing an inode from an uid to another, for example by authenticating the second.

Related commands

Related files and commands:

• tr '\0' '\n' < /proc/$N/environ
• cat /proc/$N/limits
• ps -eo pid,ppid,euid,ruid,egid,rgid,supgid,tpgid,sess,args e
• getent passwd, getent group
• id, groups
• find options -uid, -gid, -perms
• stat
• chown, chgrp
• login, newgrp
• su, sudo

Extensions

More complicated situations:

• POSIX ACLs: a very different topic, rather more extensive.
• The other new way of communcatin is via IPC which is by default in the non-UNIX domain not subject to kernel access control.