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
(716) 829-8197
