Here is how to reproduce the issue:
$ cp `which cat` .
$ ./cat /proc/self/environ
XDG_VTNR=7LC_PAPER=ru_RU.UTF-8<...>_=./cat
$ sudo setcap cap_net_raw=ep ./cat
$ ./cat /proc/self/environ
./cat: /proc/self/environ: Permission denied
This happens because /proc/self/ items are owned by root for any
process with capabilities set. Process's euid is still user (not root)
hence it can't access the file with 400 permissions owned by root:
$ cp `which ls` .
$ ./ls -l /proc/self/environ
-r-------- 1 ubuntu ubuntu 0 Mar 17 12:26 /proc/self/environ
$ sudo setcap cap_net_raw=ep ./ls
$ ./ls -l /proc/self/environ
-r-------- 1 root root 0 Mar 17 12:27 /proc/self/environ
I understand why we protect /proc/self/environ with 400 permissions,
some software allows you to pass credentials as environment variables
(e.g. AWS_SECRET_ACCESS_KEY) and making /proc/self/environ publicly
readable would be a problem. I also understand why root is assigned as
the owner for /proc/self items if target application has extended
permissions (via suid or capabilities), otherwise unprivileged user
may get access to privileged data by reading
/proc/pid/{mem,stack,syscall} of the application with capabilities he
started.
What I want to discuss is the possibility of making a loophole to
allow processes with capabilities to read their own
/proc/self/environ. We already have a similar one [1] for
/proc/<pid>/task/<tid>/comm and another one may be useful as well. It
can be implemented practically the same way.
I met this issue while trying to use address sanitizer [2] with the
application which requires some capabilities to run. Address sanitizer
reads its configuration options (ASAN_OPTIONS) directly from
/proc/self/environ [3] (probably to be able to take control very early
on when libc is not initialized). As a result, it doesn't receive
ASAN_OPTIONS from the environment if target application has some
capabilities set. It tries to open /proc/self/environ, fails and moves
on.
Do you feel like this issue needs to be resolved in the kernel? Or
it's a form of bad behavior of the application which needs to be
addressed there?
Thanks,
Oleg
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/proc/base.c#n3193
[2] https://github.com/google/sanitizers
[3] https://github.com/gcc-mirror/gcc/blob/gcc-6-branch/libsanitizer/sanitizer_common/sanitizer_linux.cc#L366
