| Summary: | app-misc/pax-utils-1.1.3[seccomp] is killed when paxmarking dev-java/icedtea-7.2.6.1-r1 due to sandbox calling getcwd | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin Väth <martin> |
| Component: | Hardened | Assignee: | SpanKY <vapier> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | alexander, gnu_andrew, java, toralf |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Debugging output of a patched /usr/sbin/paxmark.sh | ||
*** Bug 563130 has been marked as a duplicate of this bug. *** Java team should have been notified about this one. This is the third case of this I've seen now and the first was by a developer. I'll leave it assigned to the Hardened team though because I'm really at a loss and I don't run a hardened system. what file system kernel config setting do you have? So we have two issues here: 1. paxctl and paxctl-ng fails for some reason 2. if sandbox is enabled and program is accessing file with relative path, then getcwd() is used. It is not allowed in security.c [1] [1] https://gitweb.gentoo.org/proj/pax-utils.git/tree/security.c (In reply to Alexander Tsoy from comment #4) > 2. if sandbox is enabled and program is accessing file with relative path, > then getcwd() is used. It is not allowed in security.c [1] Just for example: [s] vm3020 product # strace scanelf -Xxz m ${PWD}/gamma 2>&1 | grep getcwd [s] vm3020 product # strace scanelf -Xxz m ./gamma 2>&1 | grep getcwd getcwd("/var/tmp/portage/dev-java/icedtea-7.2.6.1-r1/work/icedtea-2.6.1/openjdk.build-boot/hotspot/outputdir/linux_amd64_compiler2/product", 8192) = 131 getcwd("/var/tmp/portage/dev-java/icedtea-7.2.6.1-r1/work/icedtea-2.6.1/openjdk.build-boot/hotspot/outputdir/linux_amd64_compiler2/product", 4096) = 131 I've been dragging my feet on this one because I'd have to set up a system to reproduce. So I may do that. But my first guess is that this is due to seccomp. It would save me a lot of time if the reporter could verify whether USE=-seccomp fixes the problem. Assuming that IcedTea triggers this due to the relative path then here is the problem line. http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/98167cb0c40a/make/linux/makefiles/buildtree.make#l464 It is part of OpenJDK itself rather than IcedTea and it is the only instance I could find where $(PAX_COMMAND) is called with a relative path. CC'ing gnu_andrew to see what he makes of it. (In reply to Magnus Granberg from comment #3) > what file system kernel config setting do you have? "scanelf" is only called if both "paxctl" and "paxctl-ng -L" failed or do not exist (XT paxmarking is performed later). So how this depend on filesystem or kernel config being used? (In reply to Anthony Basile from comment #6) > But my first guess is that this is due to seccomp. Please see my previous comments. I guess it is due to getcwd() which is not allowed by seccomp filter. It's only a guess because I haven't tried pax-utils-1.1* yet. :) (In reply to Alexander Tsoy from comment #8) > > (In reply to Anthony Basile from comment #6) > > But my first guess is that this is due to seccomp. > > Please see my previous comments. I guess it is due to getcwd() which is not > allowed by seccomp filter. It's only a guess because I haven't tried > pax-utils-1.1* yet. :) duh! it would have helped if I'd actually read security.c. okay we got two things going on here. 1) why are paxctl and paxctl-ng failing? and 2) we need to look at scanelf and see if something needs changing there. Minimal reproducer:
vm ~ # sandbox
[...]
[s] vm ~ # cd /var/tmp/portage/
[s] vm portage # cp /bin/ls .
[s] vm portage # scanelf -Xxz m ./ls
Bad system call
[s] vm portage # scanelf -Xxz m ${PWD}/ls
TYPE PAX FILE
ET_DYN --mxe- /var/tmp/portage/ls
Yeah, it is getcwd(): vm ~ # dmesg | tail -n1 [481757.803083] audit: type=1326 audit(1445824867.123:3): auid=1000 uid=0 gid=0 ses=3 pid=10537 comm="scanelf" exe="/usr/bin/scanelf" sig=31 arch=c000003e syscall=79 compat=0 ip=0x359a74df22a code=0x0 vm ~ # grep ' 79$' /usr/include/asm/unistd_64.h #define __NR_getcwd 79 *** This bug has been marked as a duplicate of bug 562254 *** (In reply to Anthony Basile from comment #9) 1) why are paxctl and paxctl-ng failing? Presumably due to login shell used by paxmark.sh: $ head -n1 /usr/sbin/paxmark.sh #!/bin/bash -l This excludes /sbin and /usr/sbin from the PATH. :) (In reply to Alexander Tsoy from comment #13) > (In reply to Anthony Basile from comment #9) > 1) why are paxctl and paxctl-ng failing? > Presumably due to login shell used by paxmark.sh: > > $ head -n1 /usr/sbin/paxmark.sh > #!/bin/bash -l > > This excludes /sbin and /usr/sbin from the PATH. :) got it thanks. *** This bug has been marked as a duplicate of bug 562254 *** |
Created attachment 414398 [details] Debugging output of a patched /usr/sbin/paxmark.sh With app-misc/pax-utils-1.0.3 emerging dev-java/icedtea-7.2.6.1-r1 causes no problem. However, after updating to app-misc/pax-utils-1.1.3 (with USE="caps segcomp"), compilation fails with the error cd linux_amd64_compiler2/product && ./test_gamma /usr/sbin/paxmark.sh: line 30: 4848 Bad system call scanelf -Xxz ${flags} "$f" > /dev/null 2>&1 Segmentation fault The file /usr/sbin/paxmark.sh is from sys-apps/elfix-0.9.1. The error is independent of whether sys-apps/paxctl is installed or not. To find out the cause, I patched /usr/sbin/paxmark.sh to append its arguments to a file whenever paxctl and paxctl-ng failed; that file is attached. According to that file the segfaulting command is /usr/sbin/paxmark.sh m ./gamma (in the above directory linux_amd64_compiler2/product) The strange this is that calling the above command directly works without any failure; in fact, paxctl-ng already seems to succeed. I have no idea why it fails during the icedtea ebuild. XATTR is supported by the kernel and USE=xattr is set globally; also the ext4 filesystem hosting /var/tmp/portage is mounted with user_xattr I tested with hardened-sources-4.2.3 with CONFIG_SECCOMP=y CONFIG_SECCOMP_FILTER=y