Re: die() required on pax-mark?

> 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.

I think the issue here is not, that a non-standard way is used. It is,
that the best way to use PAX markings is not standardized. It should be
added to the ELF standard (in a generalized way, so that other runtime
exploit mitigation suites could use that standard too).

I do not know, whether there are valid use cases for using PAX-marked
binaries on non-xattr-capable file systems. It just feels like that
markings belong more to the binary itself than to the reference to that
binary in the file system.

> 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.

I am relieved to read that. So i do not have to rebuild the kernels yet
(i may have configured Grsec to only use the markings in the ELF header
- but i am not sure about that).

> The current issue, in my opinion, is how to spead up the install
> wrapper which is written in python and slow as hell.

Has the bottleneck already been identified? Python should not be much
slower than other languages for solving mostly IO-based problems.



-- 
Allan Wegan
Jabber: [email protected]
ICQ: 209459114

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJSZnHMAAoJEMO3lVyIy1QuD/kQAKAeA2cVE+kilG/8QdIhjkHY
kX/vVFUJHHKGdjqzUqAkBi9kJ8gQyDXROIoqkgePCBEJHEhC6CybZO0Y5zQFWCuU
+kH7S0X6MaBY0tdL2RLG4y5jzvZV55oGO5vusmnvNOrGZ7MSTSuVW/Pq3zpaEmLX
ZEeHPDfLBU+T4qQn2GKWgv5Co9knPTniC9w74/eqij3Wv8GL9FcSapCNtrxzWWPT
IqtwsrUZG39wVhtp0AKGHVPht9shYr4IrlJpLmhHKZKJwMq0PX8afq8WQG9FSbRQ
DZdH9Cnnysq+IwrfieFh2fqf1tp/GFQZSOv3QqKJkL8Ky0xD92zVerrgVdsvjMjL
QpvgiwFfMG3y2bAiqsS1brSE026ZMUoO+7/c8BLxQOtoFx5RX+2XLFFEU1+KnZi1
5a5tp9Qv0QlNS+Q//rzgzL97CELTKN/htjMEKdCjFBiw8DijjwIUKaR2URQZe9wT
t6QNeXCc2CdAB1IF5cBANvZV/t2C7i4Q5IV7LtJtKeubFdVpN491rTC+zM0k4lBf
sIF3rXrj4PNeiVU7iR7nij2zuqUtqnw6TilrI+Q7x6IzuT47MNLKevyfYaQIdE7s
sWlX0sq4jCJz3lP5oCyJWztDkXZ7ardl+faYH9hMmQNBGtWfD3EMf/AAnLfxMnvh
aOJzq/v9Y1lda6BFfG2M
=PCPE
-----END PGP SIGNATURE-----