> 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
signature.asc
Description: OpenPGP digital signature
