I've made an observation long before, that although PT_PAX flags are properly handled on my systems, the installed binaries and libraries lack XATTR_PAX markings. This has been the situation for a long time now. I've made a script scanning the system for inconsistent markings and issuing paxctl-ng -F for those files, where it's necessary. I have both PT and XT present in my make.conf for markings. I was told before, that I should rather opt for only one of the two possibilities - kernel-option wise and make.conf-marking-selection wise. Kinda both PT and XT are not supported at the same time using the current utilities. Moreover: there is the question if PT marking is present and XATTR is missing at the same time: which one takes precedence? I suspect the system tries to interpret the missing XATTR, falling back to apply the default flags, while paying no attention to the PT flags present. Additionally, I haven't mentioned any policy defined PAX flags. Elfutils, paxutils and all other relevant packages are keyworded on my systems. So ordinary executables are installed with an inconsistent marking by default. The new install mechanism is working on my systems. Strangely enough, I see how html files are processed during install. Ordinary binaries somehow slip through the mechanism.
It would be so good to see consistent markings on a system having both PT and XT enabled. The kernel could also behave a bit differently. These possibilities can potentially confuse some users, while I'm still fine with my scripts and have some understanding of the background. In the mean time I see some progress as well! Compile time markings definitely seem to work fine on my systems for awhile. Emerging icedtea goes flawlessly, since markings are performed in a proper fashion - even for PT & XT combo setup. I understand that compile time marking in an ebuild is a separate mechanism compared to normal ebuild file install, but I still see some room for improvements. And possibly fix this scenario. Not for me, because I think I understand the situation and I believe I know what I'm doing (just like when trying to change the multcount value for a hard drive in smartctl). But n00bs or newcomers might have a benefit from. Thanks: Dw. -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057 2014.December 14.(V) 00:52 időpontban Karl-Johan Karlsson ezt írta: > Hi list, > > I seem to have at least three problems related to PaX markings > simultaneously, > and since it's after midnight here and I need to write down some notes > anyway > so I know how to continue tomorrow, I might as well send them out to the > world > and see if someone else solves my problems for me while I'm asleep. > > It all started when I couldn't upgrade from my existing dev- > java/icedtea-7.2.4.5. Building dev-java/icedtea-7.2.5.3 failed, with the > following messages at the bottom of the log: > > > if [ -x /usr/sbin/paxmark.sh ] ; then \ > if [ -w /export/portage/portage/dev- > java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build-boot/bin/java ] ; > then \ > /usr/sbin/paxmark.sh -m /export/portage/portage/dev- > java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build-boot/bin/java ; \ > fi ; \ > fi > /usr/sbin/paxmark.sh: line 82: elog: command not found > Makefile:124: recipe for target '/export/portage/portage/dev- > java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build- > boot/classes/javax/management/ > remote/rmi/RMIConnectionImpl_Stub.class' failed > > > That's problem number one: paxmark.sh (from sys-apps/elfix-0.9.0) tries to > call elog and fails. > > That code was introduced in 0.9.0 (actually, commit 41a91c04), but I've > obviously managed to build icedtea before, so let's downgrade to 0.8.4 and > try > again. The build dies in the same location, but without the line > complaining > about elog. So paxmark.sh from 0.8.4 still fails, it's just silent about > it: > > > # /usr/sbin/paxmark.sh -m /export/portage/portage/dev- > java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build-boot/bin/java > > # echo $? > 1 > > # paxctl-ng -v /export/portage/portage/dev- > java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build-boot/bin/java > /export/portage/portage/dev- > java/icedtea-7.2.5.3/work/icedtea-2.5.3/openjdk.build-boot/bin/java: > PT_PAX : -em-- > XATTR_PAX : not found > > > So it's managed to set PT_PAX flags, but not XATTR_PAX. Looking at the > code, > paxmark.sh first tries to set PT_PAX, then XATTR_PAX, and if either fails, > the > entire thing returns failure. Unless PAX_MARKINGS is set, in which case > that > controls which type of markings is used. It isn't set on this machine. > > Problem number two: that's not what the docs say should happen. Acording > to > https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart: > > "If you decide on PaX marking method, you should adjust PAX_MARKINGS > variable > in your /etc/portage/make.conf with either XT (for extended attributes) or > PT > (for program header marking). You can set both XT PT if you wish. Default > is > PT." > > But why isn't XATTR_PAX working? I thought I completed that transition > ages > ago. > > > # paxctl-ng -v /bin/ls > /bin/ls: > PT_PAX : -e--- > XATTR_PAX : not found > > > Obviously not. Maybe I forgot this machine. Would it work? > > > # paxctl-ng -F /bin/ls > > # paxctl-ng -v /bin/ls > /bin/ls: > PT_PAX : -e--- > XATTR_PAX : -e--- > > > Yes. So why couldn't paxmark.sh set XATTR_PAX? > > > # paxctl-ng -d /bin/ls > > # paxctl-ng -v /bin/ls > /bin/ls: > PT_PAX : -e--- > XATTR_PAX : not found > > # cp /bin/ls $PORTAGE_TMPDIR > > # paxctl-ng -v $PORTAGE_TMPDIR/ls > /export/portage/ls: > PT_PAX : -e--- > XATTR_PAX : not found > > # paxctl-ng -F $PORTAGE_TMPDIR/ls > > # echo $? > 1 > > # paxctl-ng -v $PORTAGE_TMPDIR/ls > /export/portage/ls: > PT_PAX : -e--- > XATTR_PAX : not found > > # strace paxctl-ng -F $PORTAGE_TMPDIR/ls 2>&1 | grep user.pax > fsetxattr(3, "user.pax.flags", "e", 1, 0) = -1 EOPNOTSUPP (Operation not > supported) > > > OK, so XATTR_PAX works in /bin, but gets EOPNOTSUPP in $PORTAGE_TMPDIR. > They're on different mounts, so that's not unreasonable. But where do they > differ? > > > # di -h /bin > Filesystem Mount Size Used Avail %Used fs > Type > /dev/root / 75,0G 56,7G 14,5G 81% ext4 > > # di -h $PORTAGE_TMPDIR > Filesystem Mount Size Used Avail %Used fs > Type > /dev/mapper/crypt- /export 2,5T 2,2T 258,8G 90% ext3 > > # grep -E ' (/|/export) ' /proc/mounts > rootfs / rootfs rw 0 0 > /dev/root / ext4 rw,relatime,data=ordered 0 0 > /dev/mapper/crypt-export /export ext3 > rw,noatime,errors=continue,barrier=1,data=ordered 0 0 > > # tune2fs -l /dev/root | grep ext_attr > Filesystem features: has_journal ext_attr resize_inode dir_index > filetype > needs_recovery extent sparse_super large_file uninit_bg > > # tune2fs -l /dev/mapper/crypt-export | grep ext_attr > Filesystem features: has_journal ext_attr resize_inode dir_index > filetype > needs_recovery sparse_super large_file > > > So it works on ext4, but not ext3, even though both have the ext_attr flag > on > disk. Any difference in kernel support? > > > # uname -r > 3.16.5-hardened > > # gunzip -c /proc/config.gz | grep XATTR > CONFIG_EXT3_FS_XATTR=y > CONFIG_TMPFS_XATTR=y > CONFIG_PAX_XATTR_PAX_FLAGS=y > > # gunzip -c /proc/config.gz | grep EXT[34] > CONFIG_EXT3_FS=y > CONFIG_EXT3_DEFAULTS_TO_ORDERED=y > CONFIG_EXT3_FS_XATTR=y > # CONFIG_EXT3_FS_POSIX_ACL is not set > CONFIG_EXT3_FS_SECURITY=y > CONFIG_EXT4_FS=y > CONFIG_EXT4_USE_FOR_EXT23=y > # CONFIG_EXT4_FS_POSIX_ACL is not set > CONFIG_EXT4_FS_SECURITY=y > # CONFIG_EXT4_DEBUG is not set > > > Not that I can see, especially with CONFIG_EXT4_USE_FOR_EXT23=y. And it > should > be an automatic dependency anyway, since PAX_XATTR_PAX_FLAGS is set. > > Which brings us to problem number three: why aren't xattrs working in > $PORTAGE_TMPDIR on ext3 when they are in /bin on ext4? > > Problems one and two are clearly bugs, one in sys-apps/elfix and two in > sys- > apps/elfix or the documentation. Should I file them in Bugzilla, or is > this > mail enough? > > Problem three seems to be unique to this machine. Does anyone know what's > going on? > > -- > Karl-Johan Karlsson
