[gentoo-hardened] XATTR_PAX, paxmark.sh, elog, icedtea, and maybe more

[Karl-Johan Karlsson]

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