If a script of build project (i.e. cmake) contains setcap(8) command for a file on the actual file system instead of the build directory sandbox will not print an access violation and setcap will work as if sandbox wasn't used. I noticed this in the wild when a cmake project tried to use setcap to gain valid permissions for their program, but did not consider DESTDIR and uses setcap on the a binary already on the system (If it exists) instead of the new binary in DESTDIR. Thankfully the build process was verbose about what it was doing and I noticed despite sandbox not blocking it. Reproducible: Always Steps to Reproduce: 1. su - # gain root 2. cd /root # Sandbox should cause access violations here 3. touch foo # temporary file 4. sandbox sh ./test.sh # See additional information for the test script, it should cause an access violation and currently doesn't. 5. getcap foo # should print the new file capabilities which should have not been set: foo = cap_net_admin,cap_net_raw+eip Actual Results: Sandbox doesn't block setcap and it will alter file capabilities regardless. Expected Results: Sandbox should print verbose access violations when setcap is used on a file where access is not granted. Here a simple test script which shows the issue: #!/bin/sh setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' foo
I believe this may have security impact.
Looks like this is no longer reproducible with sys-apps/sandbox-2.18
It is still reproducible on my end with sandbox-2.20.
Let me demonstrate: # cd /root/ # cat test.sh #!/bin/sh setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' foo # touch foo # getcap foo # sandbox sh ./test.sh # getcap foo foo cap_net_admin,cap_net_raw=eip # sandbox --version Gentoo path sandbox version: 2.20 C lib: libc.so.6 (/lib64/libc.so.6) build: Jun 8 2020 15:17:43 contact: sandbox@gentoo.org via http://bugs.gentoo.org/ rtld: next is OK! :D schizo: x86_64:-m64 x86:-m32 configured with these options: --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --build=x86_64-slackware-linux build_alias=x86_64-slackware-linux CC=clang 'CFLAGS=-O2 -fPIC'
This is floating bug then. It was caught at [1] on ~amd64 for pcsx2, but I didn't see sandbox violation on amd64 at July. Now I observe sandbox violation with sys-apps/sandbox-2.18. [1] https://bugs.gentoo.org/730536
When I first made this issue it was not reproducible with pcsx2 and it seems its still the case now. However I added this to my pcsx2 build to prevent the problem. sed -i '/setcap/d' pcsx2/CMakeLists.txt
sandbox is, and never has been, a security boundary to protect against malicious code. it is trivial to disable it by simply exporting env vars, so missing coverage like this isn't a security issue.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=701486a499631955c150344559762ac301147833 commit 701486a499631955c150344559762ac301147833 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-10-22 03:20:21 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-10-22 04:15:04 +0000 libsandbox: add xattr wrappers #672566 These modify the filesystem, so don't let them do their business. Fixes: https://bugs.gentoo.org/672566 Signed-off-by: Mike Frysinger <vapier@gentoo.org> configure.ac | 5 +++++ headers.h | 3 +++ libsandbox/libsandbox.c | 24 +++++++++++++++--------- libsandbox/symbols.h.in | 4 ++++ libsandbox/wrapper-funcs/lremovexattr.c | 11 +++++++++++ libsandbox/wrapper-funcs/lsetxattr.c | 11 +++++++++++ libsandbox/wrapper-funcs/removexattr.c | 11 +++++++++++ libsandbox/wrapper-funcs/setxattr.c | 11 +++++++++++ tests/Makefile.am | 4 ++++ tests/lremovexattr-0.c | 15 +++++++++++++++ tests/lsetxattr-0.c | 24 ++++++++++++++++++++++++ tests/removexattr-0.c | 15 +++++++++++++++ tests/removexattr-1.sh | 13 +++++++++++++ tests/removexattr.at | 1 + tests/setxattr-0.c | 24 ++++++++++++++++++++++++ tests/setxattr-1.sh | 13 +++++++++++++ tests/setxattr.at | 1 + tests/tests.h | 1 + 18 files changed, 182 insertions(+), 9 deletions(-)
