| Summary: | sys-apps/sandbox: executing set*id app results in warnings: ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored. | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Nikoli <nikoli> |
| Component: | Sandbox | Assignee: | Sandbox Maintainers <sandbox> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | netmon, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=537598 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
net-libs:libssh2-1.4.2:20121107-162415.log |
||
|
Description
Nikoli
2012-11-07 10:25:25 UTC
Created attachment 328706 [details]
net-libs:libssh2-1.4.2:20121107-162415.log
Confirmed, but mine looks slightly different (maybe because I ran it as normal user?).
this happens when FEATURES=userpriv is enabled and man is set*id on the upside, i've fixed sandbox so that it'll fall back to ptrace when handling set*id programs. on the downside, it is not easy to fix this warning. i cannot just unsetenv(LD_PRELOAD) because the process which is doing the exec might have been created via clone or vfork. in those situations, the child shares the same memory region as the parent, so modifying the environ in the child will also modify it in the parent. as an example, last i looked, `make` does exactly this. it vforks its targets when executing rules. so if we unsetenv, it'd break by doing: - run make as non-root (user) - top level make runs (pid=10) - make finds two rules to process - first rule reads: mount --help - make vforks (child pid=11) and tries to run mount - libsandbox detects this, sets things up to ptrace, and unsetenv(LD_PRELOAD) - mount finishes running w/out warning (since LD_PRELOAD was unset) - make moves on to 2nd rule (now with LD_PRELOAD unset in its env) - 2nd rule reads: -touch / - make vforks (child pid=12) and tries to run touch - touch fails since it doesn't have permission, but this error is not caught by sandbox because LD_PRELOAD is no longer set - make ignores the error (due to the rule starting with "-") this is a bit of a contrived case, but we've seen people run set*id programs in makefiles before as well as have errors in install targets which write to the wrong path. there's no way (that i know of) to detect this at runtime (i.e. how many other processes are sharing memory region XXX with me?), and we can't do a fork() behind the back of a vfork() or clone() because that implies C library overhead that is unsafe (grabbing locks). we also can't unset the env, do the exec, and then reset the env because this would introduce a race condition if people were using threads + clone/vfork + exec. it would also be pretty messy to get the synchronization between the child (which does the unset) and the parent (which does the set) done right. we might be able to finagle a clone(~CLONE_VM) ourselves before doing the exec. it'll be tricky, but not too hard i don't think. this doesn't silence the warning, but it does fix the lack of tracing: http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=26ad6af1a4f246bda3cd7a19a24c1767ec9c835e The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=f0d8469ab6f3a4039038bf86cc829e917b596f40 commit f0d8469ab6f3a4039038bf86cc829e917b596f40 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-10-22 00:20:58 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-10-24 00:54:46 +0000 sandbox: leverage PR_SET_NO_NEW_PRIVS when available This will lock down the ability to use set*id programs (like sudo), and will allow us to utilize seccomp bpf to speed up ptrace. Closes: https://bugs.gentoo.org/442172 Signed-off-by: Mike Frysinger <vapier@gentoo.org> configure.ac | 2 ++ headers.h | 3 +++ src/sandbox.c | 16 ++++++++++++++++ 3 files changed, 21 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=288877d0e268087dacb4b593202e28f86b6d31d4 commit 288877d0e268087dacb4b593202e28f86b6d31d4 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-10-24 01:12:13 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-10-24 01:13:05 +0000 sys-apps/sandbox: version bump to 2.27 Add USE=nnp flag to control new NO_NEW_PRIVS behavior. In case things go horribly wrong, can easily flip the flag off to keep from blowing everyone up. Bug: https://bugs.gentoo.org/442172 Signed-off-by: Mike Frysinger <vapier@gentoo.org> sys-apps/sandbox/Manifest | 1 + sys-apps/sandbox/metadata.xml | 3 ++ sys-apps/sandbox/sandbox-2.27.ebuild | 64 ++++++++++++++++++++++++++++++++++++ 3 files changed, 68 insertions(+) |