Re: [gentoo-hardened] Python stops working after upgrade

[Tóth Attila]

2013.Május 30.(Cs) 17:45 időpontban Magnus Granberg ezt írta:
> torsdag 30 maj 2013 11.13.45 skrev  Anthony G. Basile:
>>
>> migrate-pax also will copy PT_PAX to XATTR_PAX flags identically with
>> one exception, if PT_PAX = "-e---" then no user.pax.flags xattr is
>> created.  I am always thinking in terms of either PAX_PT_PAX_FLAGS xor
>> PAX_XATTR_PAX_FLAGS is on, not both.  When both are on, we fall back on
>> what you describe.  So I adopted the approach: don't copy "-e---" to
>> XATTR_PAX and when you reboot into a PAX_PT_PAX_FLAGS=n and
>> PAX_XATTR_PAX_FLAGS=y kernel, you'll get the desired behavior.
>>
>> A good approach or no?
> To use xattr pax flags PAX_MARKINGS need to be set to XT in make.conf
> else will portage default to PT when marking.
> Python need EMUTRAMP enable in the kernel with newer libffi and python
> and have the E mark on the binary.
> /Magnus
>
>

Thx for pointing that out.

Note, that pax-utils eclass gentoo page describes the default action
twice, differently:
http://devmanual.gentoo.org/eclass-reference/pax-utils.eclass/index.html
In the DESCRIPTION:
"To control what markings are made, set PAX_MARKINGS in
/etc/portage/make.conf to contain either "PT", "XT" or "none". The default
is to attempt both PT_PAX and XATTR_PAX."
In ECLASS VARIABLES:
"Control which markings are made: PT = PT_PAX markings, XT = XATTR_PAX
markings Default to PT markings."
It would be good to make it unambiguous.

I've appended PAX_MARKINGS="XT" to my make.conf, emerging python 3.2 dies
in install phase with the following log snippet:
---
Skipping: CDSL_CURRENT = INT_MAX
 * XT PaX marking -E with paxctl-ng
 *      python
>>> Source compiled.
>>> Test phase [not enabled]: dev-lang/python-3.2.5

>>> Install python-3.2.5 into
/var/tmp/portage/dev-lang/python-3.2.5/image/ category dev-lang
make -j3 DESTDIR=/var/tmp/portage/dev-lang/python-3.2.5/image/ altinstall
Creating directory /usr/bin
/bin/sh: line 5: 24666 Killed                 
LD_LIBRARY_PATH=/var/tmp/portage/dev-lang/python-3.2.5/work/x86_64-pc-linux-gnu:
CC='x86_64-pc-linux-gnu-gcc -pthread' LDSHARED='x86_64-pc-linux-gnu-gcc
-pthread -shared -Wl,-O1 -Wl,--as-needed -L. -Wl,-O1 -Wl,--as-needed -L.'
CFLAGS=' -DNDEBUG  -O2 -march=corei7-avx -pipe -fwrapv -O2
-march=corei7-avx -pipe -fwrapv ' ./python -E
/var/tmp/portage/dev-lang/python-3.2.5/work/Python-3.2.5/setup.py $quiet
build
make: *** [sharedmods] Error 137
make: Creating directory /usr/include
*** Waiting for unfinished jobs....
---

Let's check the marking on two python binaries.

First the python binary the install tries to execute in the arch directory:
paxctl-ng -v
/var/tmp/portage/dev-lang/python-3.2.5/work/x86_64-pc-linux-gnu/python
/var/tmp/portage/dev-lang/python-3.2.5/work/x86_64-pc-linux-gnu/python:
        PT_PAX    : -e---
        XATTR_PAX : -E---

If I try to manually execute the binary in the arch directory having XT
emutramp enabled, it results in an instant kill. If I disable emutramp for
both PT and XT, the binary executes fine.

Next the python binary located in the image directory:
axctl-ng -v /var/tmp/portage/dev-lang/python-3.2.5/image/usr/bin/python3.2
/var/tmp/portage/dev-lang/python-3.2.5/image/usr/bin/python3.2:
        PT_PAX    : -e---
        XATTR_PAX : not found

If I try to manually execute the binary in the image directory, it shows
normal behavior and display the python interpreter's prompt.

My conclusions:
On my systems XT markings make.conf entry causes troubles during the
install phase while emerging python.
The reason for the fail is that the binary gets killed instantly with
EMUTRAMP on for XT.
The binary in the image directory lack XT markings. I don't know if later
it would get further markings, but it seems to me the markings are
performed just before the install phase.

So EMUTRAMP seems to harm python's normal execution and it's possible the
necessary XT markings would not happen on the actual binary which will be
qmerged to the system - as expected.

I'm using the latest elfix from the hardened overlay, have this one
specified in my repos.conf:
---
[DEFAULT]
# eclasses provided by hardened-dev takes precedence over
# identically named eclasses that are provided by gentoo
eclass-overrides = hardened-dev

[gentoo]
eclass-overrides = hardened-dev
---
And I'm doing emerge --regen routinely after portage & layman syncs.

I would be more than happy for doing some further testing or providing
more info as needed.

Regards:
Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, [phone]