Re: die() required on pax-mark?

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