Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 771360 - sys-apps/sandbox: please allow sandbox to work with kernel.yama.ptrace_scope = 2 (i.e. disabling ptrace)
Summary: sys-apps/sandbox: please allow sandbox to work with kernel.yama.ptrace_scope ...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Sandbox (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Sandbox Maintainers
URL:
Whiteboard:
Keywords:
: 640698 (view as bug list)
Depends on: 821499
Blocks:
  Show dependency tree
 
Reported: 2021-02-18 22:10 UTC by Alessandro Barbieri
Modified: 2021-11-03 16:57 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
go-1.16:20210218-212602.log (go-1.16:20210218-212602.log,9.17 KB, text/plain)
2021-02-18 22:11 UTC, Alessandro Barbieri
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alessandro Barbieri 2021-02-18 22:10:14 UTC
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
Comment 1 Alessandro Barbieri 2021-02-18 22:11:08 UTC
Created attachment 687501 [details]
go-1.16:20210218-212602.log

buildlog
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-02-18 22:14:02 UTC
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
Comment 3 SpanKY gentoo-dev 2021-10-18 05:01:12 UTC
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.
Comment 4 Alessandro Barbieri 2021-10-18 05:07:54 UTC
Isn't possible to have a solution that will work with the capabilities?
Comment 5 SpanKY gentoo-dev 2021-10-18 06:56:03 UTC
(In reply to Alessandro Barbieri from comment #4)

feel free to research Linux tracing technology and let us know what you find
Comment 6 Larry the Git Cow gentoo-dev 2021-10-18 08:48:45 UTC
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(+)
Comment 7 SpanKY gentoo-dev 2021-11-03 03:13:24 UTC
*** Bug 640698 has been marked as a duplicate of this bug. ***
Comment 8 Larry the Git Cow gentoo-dev 2021-11-03 06:59:23 UTC
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(+)
Comment 9 Herbert Wantesh 2021-11-03 13:15:25 UTC
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.
Comment 10 Herbert Wantesh 2021-11-03 13:35:15 UTC
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;
+			}
Comment 11 SpanKY gentoo-dev 2021-11-03 16:20:42 UTC
i'll just make yama>=3 into an abort
Comment 12 Larry the Git Cow gentoo-dev 2021-11-03 16:40:28 UTC
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(-)