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

[Tóth Attila]

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, [phone]

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