Mailing List Archive

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