On 10/21/2013 03:03 AM, Allan Wegan wrote:
But, after we drop PT_PAX, this is only *worse* for the people in
(1.a). That's a much smaller group than /everyone/ who switches to
hardened.
There seems to be the theoretical possibility of dropping XT_PAX instead
of PT_PAX. The correct work of PAX markings would then not depend on the
file system used. Therefore users with and without capable file systems
could switch to hardened freely, since all the pax-markings would have
been succeessfully applied to the executables.
I am only a user of Gentoo Hardened (amd64) and do not know, why that
option seems would not be a viable path.
Is it because of self-checking binary blobs?
Yes and things like the programming language 'go' who's linker did not
produce a PAX_FLAGS program header --- it does now after we got upstream
to add it etc. The problem is that a PAX_FLAGS program header is not
standard while user defined xattrs are. eg. EI_PAX used to put the
markers in the ELF header (in a non-standard way) until that got
clobbered by a commit in glibc; similarly pax markings in the program
header cause issue in cases like the above. XT_PAX has the advantage of
not violating a standard while the disadvantage of needing end-to-end
xattr support.
Pick your poison.
Perhaps, it should be at least a valid choice to not drop (legacy?)
PT_PAX markings - just in case you want to use hardened without xattr or
want to upgrade from vanilla.
I have no intentions of dropping PT_PAX anytime soon. toolchain did
indicate a desire to do so because the program header causes issues in
binutils' test suite, but dropping PT_AX is a long range plan if it will
ever happen.
The current issue, in my opinion, is how to spead up the install wrapper
which is written in python and slow as hell.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
