Sanitizer silently ignores ASAN_OPTIONS when application has some capabilities set
- Dominant language
- C
- Stars
- 12.5k
- Forks
- 1.1k
- PR merge metrics
- No merged PRs in 30d
Description
How to reproduce the issue:
```
$ echo "int main() { return 0; }" > test.c
$ gcc -fsanitize=address -o test test.c
$ ASAN_OPTIONS="help=1" ./test
Available flags for AddressSanitizer:
<...>
$ sudo setcap cap_net_raw=ep ./test
$ ASAN_OPTIONS="help=1" ./test
```
This happens because /proc/self/environ (and other items in the folder) is owned by root for any application with capabilities set. This was done to prevent data leakage from privileged (user < capabilities < root) process to unprivileged user. Application'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 мар 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
```
Address sanitizer tries to open /proc/self/environ, fails (permission denied) and silently moves on. The same issue can be reproduced with simple cat utility:
```
$ cp `which cat` .
$ ./cat /proc/self/environ
XDG_VTNR=7LC_PAPER=ru_RU.UTF-8<...>XAUTHORITY=/home/ubuntu/.Xauthority_=./cat
$ sudo setcap cap_net_raw=ep ./cat
$ ./cat /proc/self/environ
./cat: /proc/self/environ: Permission denied
```
It's an open question if we want to fix this issue by switching from /proc/self/environ to some other way of fetching the environment. It's probably enough to display a warning if sanitizer can't get access to /proc/self/environ. But we shouldn't ignore ASAN_OPTIONS silently.
Contributor guide
Research direction
Start by reproducing the issue with AddressSanitizer, ASAN_OPTIONS="help=1", and a binary granted cap_net_raw=ep. Inspect the sanitizer path that reads /proc/self/environ and determine how its permission failure is handled. Done means ASAN_OPTIONS is no longer silently ignored for capability-bearing applications, with the chosen behavior covered by a regression test if the project provides one.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- security, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100