| Summary: | sys-apps/sandbox: sandbox breaks when installing musl libc in qemu-user chroot due to use of ptrace | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David Flogeras <dflogeras2> |
| Component: | Current packages | Assignee: | Sandbox Maintainers <sandbox> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | floppym, mgorny, sam, sandbox, tamiko, virtualization |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
David Flogeras
2018-02-22 13:28:31 UTC
This doesn't seem like a bug in sandbox, but rather missing functionality in qemu. I suggest disabling sandbox support in portage as a workaround. I think that the problematic part in the musl ebuild might get changed soon. See bug 645626. Now that sandbox-2.12 is stable, I've seen more of this type of failure. Latest was glibc, and I think I had trouble with glib as well. I agree this is a deficiency of qemu, but as ptrace is not likely to ever be implemented in qemu according to what I've read, I'm wondering how best to workaround. Is there a more conservative thing to do than just disable sandbox altogether? @Mike Gilbert In my qemu chroot(s), I've rebuilt sandbox, but during configure I removed #define HAVE_PTRACE from config.h, thus cutting out the ptrace logic. I _think_ I still get any other benefits of sandbox (NB I don't even pretend to understand what the ptrace stuff does, but I still get things like directory write protection) On my real hardware, I still have the sandbox with full ptrace support, so it would catch anything my qemu chroot did not when I install the binaries? Is this a reasonable approach? Sorry to nag, but I'm just of the mind that some protection is better than none. Hmm, maybe we should add 'ptrace' USE flag for this. Possibly package.use.force it for everyone, leaving unmasking and disabling as an alternative for people using qemu-user. Actually, I am not sure what I was thinking when I grabbed the bug. Reassigning to sandbox maintainers. *** This bug has been marked as a duplicate of bug 300679 *** 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(+) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=d8b9a41d76de38cab079951cd494cdb491b55126 commit d8b9a41d76de38cab079951cd494cdb491b55126 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-10-31 23:50:01 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-10-31 23:50:01 +0000 libsandbox: do not use ptrace if it returns ENOSYS QEMU's linux-user does not implement ptrace for any architecture, and any attempt to call it fails with ENOSYS. Detect that scenario. Closes: https://bugs.gentoo.org/648516 Signed-off-by: Mike Frysinger <vapier@gentoo.org> libsandbox/trace.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) |
