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

[Anthony G. Basile]

On 05/29/2013 07:55 PM, PaX Team wrote:
> On 28 May 2013 at 21:29, Anthony G. Basile wrote:
>
>> Unfortunately it is very difficult to find everything that links against
>> everything on a system.  First there's just a simple logistic problem,
>> going through all ELF on a system and running ldd (or readelf -d) is
>> time consuming and likely to miss stuff.  On gentoo with portage (not
>> paludis!) we have linkage info in NEEDED.ELF.2 in vdb created at build
>> time by examing linkage info, but this also can't be everything.
>> Consider plugins that dlopen-ed at runtime.
>
> PaX already has code for textrel handling where it looks at mapped libraries,
> it'd be easy to add detection for mismatched process vs. library PaX flags
> at the same time.
>
> let me know if you could use this (users would have to send you logs so that
> you can build a database or perhaps some tool run locally could do it for
> everyone) and i'll code it up.

Yes, that would be excellent!  The kernel is the obvious place to catch 
actual linkings rather than the sort of userland guesswork that I've 
been grappling with.  What might this exe dlopen next?

>
>> That's not what's happening there.  No XATTR_PAX flags implies the
>> default markings which is "-e---".
>
> actually no pax.flags xattr on the file means that it'll be ignored and
> the other mechanisms will be used (which can ultimately be -e--- if no
> other mechanism is configured). now what you do in paxctl-ng is another
> matter, i thought that it'd keep these two flags in sync, at least when
> an already existing PT_PAX one is not the default value like it wasn't
> in his case (EMUTRAMP was on for softmode).
>

When marking PpEeMmRrSs with paxctl-ng, it does keep the two sets in 
sync, although there are options that allow you to change one and not 
the other and so desynchronize.  But it goes out of its way, where it 
can, to keep the two in sync.

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?


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]