Since libsandbox.so is not set[ug]id, it doesn't get preloaded for set[ug]id executables. Which not only means their access isn't restricted within ebuilds but also causes a lot of ugly ld.so errors: ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. If the code is safe enough, I think it should be made set[ug]id. CC-ing security@ for opinion on that.
heh, it is not safe at all for set*id context, nor is it a goal to be safe. generally speaking, you shouldn't be running set*id inside ebuilds in the first place. we should be able to change the logic in wrapper-funcs/__wrapper_exec.c to use ptrace when running a set*id ELF. it would mean some might break (like sudo will crap out), but that's probably for the best anyways.
Well, I don't need this anymore, just left the bug in case. Wouldn't it be better to prohibit setuid in ebuilds completely? Any idea how to do that?
(In reply to Michał Górny from comment #2) i described where we can catch that. i don't think it's possible to ban execution of set*id entirely because some packages run like `mount --help`. as long as we ptrace them, the kernel won't grant the runtime env set*id permission.
i've implemented ptrace for pretty much every arch now in sandbox-2.11 (ignoring sparc's disable due to bug 293632 which i think is kernel related). not much else to be done here. ftr, 2.11 supports (and passes tests on): alpha amd64 arm hppa ia64 ppc ppc64 s390 s390x if i can get a real system to test on, an arm64 port will be pretty quick. i guess i'm also missing mips, but eh.
