| Summary: | paxmark.sh (from sys-apps/elfix-0.9.1) called from inside build systems always uses scanelf, which fails due to sandbox | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Karl-Johan Karlsson <creideiki+gentoo-bugzilla> |
| Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | martin |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
(In reply to Karl-Johan Karlsson from comment #0) > Creating a symlink /usr/bin/paxctl-ng -> /usr/sbin/paxctl-ng makes > paxmark.sh select paxctl-ng instead of scanelf, which makes the build > processes work. This workaround did it for me too. But sbcl then failed on something else. Thanks! Its easy enough for me create the sym link, but do we understand why. I don't want just start littering the file system with sym links without good justification. There must be some reason why the type command fails. *** Bug 562862 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 562206 *** *** Bug 562862 has been marked as a duplicate of this bug. *** |
I have three hardened AMD64 machines that cannot build packages which call paxmark.sh from deep within their build systems. /usr/sbin/paxmark.sh checks which of paxctl, paxctl-ng, scanelf, and setfattr are available by running "type -p $COMMAND", with unqualified command names. On my machines, the only ones it finds are scanelf and setfattr, even though /usr/sbin/paxctl-ng exists and /usr/sbin seems to be in the build environment's PATH: # grep 'declare -x PATH' /var/tmp/portage/dev-java/icedtea-7.2.6.1/temp/environment declare -x PATH="/usr/lib64/icedtea7/bin:/usr/lib/portage/python3.4/ebuild-helpers/xattr:/usr/lib/portage/python3.4/ebuild-helpers:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/opt/cuda/bin" Creating a symlink /usr/bin/paxctl-ng -> /usr/sbin/paxctl-ng makes paxmark.sh select paxctl-ng instead of scanelf, which makes the build processes work. Using scanelf instead of paxctl-ng is a problem, because when called it fails with the error message "Bad system call". This seems to be because of Sandbox, since scanelf works as an unprivileged user on the same filesystem without sandbox: ~ $ cd /var/tmp/ tmp $ touch foobar tmp $ scanelf -Xxz em foobar tmp $ sandbox ============================= Gentoo path sandbox ============================== Detection of the support files. Verification of the required files. Setting up the required environment variables. The protected environment has been started. -------------------------------------------------------------------------------- Process being started in forked instance. /var/tmp $ scanelf -Xxz em foobar Bad system call /var/tmp $ strace -f scanelf -Xxz em foobar 2>&1 | tail unshare(CLONE_NEWUTS|CLONE_NEWIPC) = -1 EPERM (Operation not permitted) brk(0) = 0x7439adda90 brk(0x7439afea90) = 0x7439afea90 brk(0x7439aff000) = 0x7439aff000 prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, {len = 53, filter = 0x7439ae3370}) = 0 unshare(CLONE_NEWPID) = -1 EPERM (Operation not permitted) newfstatat(AT_FDCWD, "foobar", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0 stat("foobar", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap(NULL, 8200, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x34625aac000 +++ killed by SIGSYS +++ /var/tmp $ exit Cleaning up sandbox process ============================= Gentoo path sandbox ============================== The protected environment has been shut down. -------------------------------------------------------------------------------- However, after removing "sandbox" and "usersandbox" from FEATURES the packages still fail to emerge, so there's some other subtlety going on. I first saw this on dev-java/icedtea-7.2.6.1. I did a quick grep through the Portage tree for "paxmark.sh", and the only other packages that seems to call it from within the build system instead of from top-level Portage are dev-lisp/sbcl (all versions) and www-client/luakit-9999. I tried building them, and paxmark.sh selects scanelf and setfattr for both of them as well. Original build failure (dev-java/icedtea-7.2.6.1): gmake[6]: Leaving directory '/var/tmp/portage/dev-java/icedtea-7.2.6.1/work/icedtea-2.6.1/openjdk.build/hotspot/outputdir/linux_amd64_compiler2/product' cd linux_amd64_compiler2/product && ./test_gamma /usr/sbin/paxmark.sh: line 30: 9522 Bad system call scanelf -Xxz ${flags} "$f" > /dev/null 2>&1 ./test_gamma: line 86: 9539 Killed ./${GAMMA_PROG} -Xbatch -showversion Queens < /dev/null www-client/luakit-9999 (whose build system doesn't consider it a fatal error, so Portage completes the emerge operation, but the installed binary has the wrong PaX markings so it doesn't run): paxmark.sh -m luakit /usr/sbin/paxmark.sh: line 30: 4808 Bad system call scanelf -Xxz ${flags} "$f" > /dev/null 2>&1 and, for completeness, here's dev-lisp/sbcl-1.2.15 (including some debug printouts I added to paxmark.sh): + paxmark.sh -mr ./src/runtime/sbcl /usr/bin/scanelf /usr/sbin/paxmark.sh: line 30: 22991 Bad system call scanelf -Xxz ${flags} "$f" /bin/setfattr + ./src/runtime/sbcl --core output/cold-sbcl.core --lose-on-corruption --no-sysinit --no-userinit make-target-2.sh: line 49: 22993 Killed ./src/runtime/sbcl --core output/cold-sbcl.core --lose-on-corruption --no-sysinit --no-userinit < make-target-2.lisp Reproducible: Always