After setting kernel.yama.ptrace_scope = 2 in /etc/sysctl.conf I can't emerge some packages (for example dev-lang/go) the error is * /var/tmp/portage/sys-apps/sandbox-2.20/work/sandbox-2.20/libsandbox/trace.c:_do_ptrace():83: failure (Operation not permitted): * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted I've tried the to set the capabilities with setcap cap_sys_ptrace+ep /usr/bin/sandbox and cap_sys_ptrace portage into /etc/security/capability.conf this doesn't work. I'm still finding the right binary to give capabilities to. Then in IRC they let me notice that it's bash loading libsandbox.so so I've set setcap cap_sys_ptrace+ep /bin/bash the problem is that now it will fail loading the sandbox with ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. The same issue was reported here https://forums.gentoo.org/viewtopic-t-1103616-start-0.html but noone answered
Created attachment 687501 [details] go-1.16:20210218-212602.log buildlog
IRC excerpts (edited): <+sam_> don't set that ptrace option or see if the kernel has a way to allow certain binaries to do it <+sam_> ultimately it's a very heavy hammer <+sam_> tl;dr you've discovered a cool option which I personally would love to use too, but I am unsure that the mechanics exist in that option to allow compatibility with sandbox <+sam_> it makes sense for a lot of things, just not where we need sandbox <+sam_> and you kind of have to accept it, probably, or use SELinux or something which might let you disable ptrace more granularly <+sam_> libsandbox will use ptrace if it can <+sam_> your best bet would be to disable that <+sam_> We may or may not use ptrace in just some situations, I think it depends on the arch <+sam_> I'm also not sure that disabling ptrace is *desirable* in sandbox, it makes it less effective! <+sam_> it's kind of a bug and kind of not.. I mean, it's a fundamental issue with the kernel option <+sam_> given we can't use LD_PRELOAD with suid or caps, the alternative is just doing it as root which is horrible <+sam_> or disabling ptrace, also horrible because weaker 'protection' <grawity> Alessandro-B: I think the point is that it's not specific binaries that need it, but literally any binary which gets the libsandbox.so PRELOAD'ed into it <grawity> Alessandro-B: and as I said before, the moment you give capabilities to a binary, it can't LD_PRELOAD the sandboxer in the first place <grawity> you *might* be able to use ambient capabilities (setpriv --ambient-caps=+cap_sys_ptrace --inh-caps=+cap_sys_ptrace) rather than file caps, but no guarantee
we're moving to use ptrace more, not less -- LD_PRELOAD does not work in all cases, and is difficult to keep working smoothly. if you're familiar with tech in Linux that allows you to monitor a process for problems, feel free to highlight it here. ptrace is the only way to do this i'm aware of. keep in mind sandbox is not just a containment tool, but also a debug tool. it allows devs to find broken logic and fix it, not just have it get ignored.
Isn't possible to have a solution that will work with the capabilities?
(In reply to Alessandro Barbieri from comment #4) feel free to research Linux tracing technology and let us know what you find
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=c4bf07615cd2e2ec25a16420d8ddee2efec6f8d2 commit c4bf07615cd2e2ec25a16420d8ddee2efec6f8d2 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-10-18 06:47:59 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-10-18 06:47:59 +0000 libsandbox: add SANDBOX_METHOD setting This allows people to disable use of ptrace if their configuration does not support it. This forces older sandbox behavior where we cannot protect against static or set*id programs. Bug: https://bugs.gentoo.org/648516 Bug: https://bugs.gentoo.org/771360 Signed-off-by: Mike Frysinger <vapier@gentoo.org> etc/sandbox.conf | 11 ++++++++++ libsandbox/libsandbox.c | 10 +++++++++ libsandbox/libsandbox.h | 1 + libsandbox/wrapper-funcs/__wrapper_exec.c | 4 ++++ libsbutil/Makefile.am | 1 + libsbutil/sb_method.c | 34 +++++++++++++++++++++++++++++++ libsbutil/sbutil.h | 11 ++++++++++ src/environ.c | 3 +++ 8 files changed, 75 insertions(+)
*** Bug 640698 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=746d68ae5972575d5fd87b7bd82e318d56352d9e commit 746d68ae5972575d5fd87b7bd82e318d56352d9e Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-11-03 06:40:08 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-11-03 06:40:08 +0000 libsandbox: add YAMA checks and skip ptrace when active The YAMA ptrace_scope knob restricts access to different ptrace calls depending on the capabilities the current process holds. For now, do not try to ptrace processes when the YAMA level is incompatible with the capabilities that we have. This means we basically cannot protect against processes when they get into this state, so for now, we release them rather than abort. Bug: https://bugs.gentoo.org/771360 Bug: https://bugs.gentoo.org/821403 Signed-off-by: Mike Frysinger <vapier@gentoo.org> libsandbox/trace.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
thanks for the patch, but it's not completely correct. In static int trace_yama_level(void) you check for if (getuid() == 0) return 0; which is not correct. The values of ptrace are: 0 - classic ptrace permissions 1 - restricted ptrace 2 - admin-only attach 3 - no attach As you return 0 without checking the ptrace value, if ptrace == 3, it means that even an admin can't attach to a process. So you would first have to check if the ptrace value < 3 and if the uid== 0 you can return 0. If the ptrace value is "1" it's also possible to trace a child form a parent process.
based on this this code should get changed from: + if (yama >= 1) { + sb_eqawarn("Unable to trace children due to YAMA ptrace_scope=%i\n", yama); + ptrace(PTRACE_DETACH, newpid, NULL, NULL); + continue; + } - to - + if (yama >= 2) { + sb_eqawarn("Unable to trace children due to YAMA ptrace_scope=%i\n", yama); + ptrace(PTRACE_DETACH, newpid, NULL, NULL); + continue; + }
i'll just make yama>=3 into an abort
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=01318f0d48654425b4ea3a90520a52f774b60ead commit 01318f0d48654425b4ea3a90520a52f774b60ead Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-11-03 16:34:54 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-11-03 16:34:54 +0000 libsandbox: refine yama check to abort on level 3+ There's no way we can support level 3+ since the kernel blocks it, so give up and inform the user their setup is incompatible. Bug: https://bugs.gentoo.org/771360 Signed-off-by: Mike Frysinger <vapier@gentoo.org> libsandbox/trace.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-)
*** Bug 923798 has been marked as a duplicate of this bug. ***
