Subject: magic symbolic links and CAP_DAC_READ_SEARCH

[Jeff Norden]

I'm certainly no expert, so there could easily be some security issues that
I'm not seeing right now, but...

It seems to me that the CAP_DAC_READ_SEARCH capability ought to allow
readlink() to succeed on a "magic symlink" even when the uid/gid would
otherwise disallow it.

The capabilities(7) man page says:
 CAP_DAC_READ_SEARCH
  * Bypass file read permission checks and directory read and execute
    permission checks;
etc.

This could be handy to see what files a process has open without using
full-blown root priv.  E.g., "ls -l /proc/nnnn/fd/"  run via setpriv or
capsh.

Thanks for listening,
-Jeff

---------
The following illustrates the current situation.  'rsudo' is a personal script
I use to run a command with dac_read_search; sort of a 'read only' version of
sudo. (I really should clean it up a bit and post it somewhere.)

jeff@ups:~$ ls -l /proc/1/fd/0
ls: cannot access '/proc/1/fd/0': Permission denied

jeff@ups:~$ sudo ls -l /proc/1/fd/0
lrwx------ 1 root root 64 Oct 23 13:48 /proc/1/fd/0 -> /dev/null

jeff@ups:~$ sudo readlink /proc/1/fd/0
/dev/null


jeff@ups:~$ rsudo ls -l /proc/1/fd/0
ls: cannot read symbolic link '/proc/1/fd/0': Permission denied
lrwx------ 1 root root 64 Oct 23 13:48 /proc/1/fd/0

jeff@ups:~$ rsudo readlink /proc/1/fd/0

The first 'rsudo' above ran the cmd:
 sudo setpriv --inh-caps +dac_read_search --ambient-caps +dac_read_search
 --reuid=1000 --regid=1000 --init-groups -- ls -l /proc/1/fd/0
The second did the same for 'readlink /proc/1/fd/0'