Hi Everyone,
It has take a long time to finalize XATTR_PAX support in Gentoo, but I
think the final step is done. The thorniest problem was getting portage
wrappers to `/usr/bin/install` to preserve extended attributes. We
could have hacked up ebuilds to do the markings after install, but in
some cases this meant having to do double markings in ebuilds and left a
gap in our end-to-end support for other packages needing xattrs not
necessarily related to PaX. I took the harder but "correct" path and
wrote a wrapper. My first wrapper was written in python and worked
great except it was slooooow --- actually I had one in bash which used
associated arrays but that requires bash4 and portage only supports
bash3! I rewrote the wrapper in C and it worked great when I by-passed
the portage install machinary and used it directly, but the point was to
get it working in portage! I finally traced the bug down to how the
environment $PATH changes during the ebuild phases and added
intelligence to the C wrapper.
Anyhow, I'd like victims ... err ... I mean testers:
1) Have USE=xattr and PAX_MARKINGS="XT" in you make.conf file
2) Your kernel should have CONFIG_PAX_XATTR_PAX_FLAGS=y. If you are
brave have CONFIG_PAX_PT_PAX_FLAGS not set.
3) emerge =sys-apps/install-xattr-0.2, sys-apps/elfix. If you can
emerge elfix with USE="ptpax xtpax" but if you are brave try USE="-ptpax
xtpax". You must have at least xtpax in there.
4) You need to apply the following patch to portage:
https://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9089c2d755b0ecb1b340fc23dda461163f589c43
You can just manually apply it after `cd /usr/lib/portage/`
5) Then emerge any package needing pax markings (maybe not python just
in case something breaks). Like johntheripper which should give
~ # paxctl-ng -v /usr/sbin/john
/usr/sbin/john:
PT_PAX : -emr-
XATTR_PAX : -emr-
or just
/usr/sbin/john:
XATTR_PAX : -emr-
If you removed all PT_PAX above.
Let me know if you hit issues. The final step will be to just make sure
our releases have XATTR_PAX markings and that we document how to
properly installed them so you don't loose the markings.
Finally, some may wonder, why XATTR_PAX markings? The main reason is
that it doesn't touch the ELF binaries and makes them more consistent
with what other distros ship. Also, marking can be done while the ELF
is busy (eg `paxctl -m /bin/bash`, leads to "Text file busy" but you
can always do `paxctl-ng -lm /bin/bash`, ie set only XATTR_PAX). This
allows you to work with a live system which is useful if you ever need
to do a revdep-pax to migrate pax flags from a library to the
executables that link against it. The disadvantage is that xattr
support requires more work and so are more fragile.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
It has take a long time to finalize XATTR_PAX support in Gentoo, but I
think the final step is done. The thorniest problem was getting portage
wrappers to `/usr/bin/install` to preserve extended attributes. We
could have hacked up ebuilds to do the markings after install, but in
some cases this meant having to do double markings in ebuilds and left a
gap in our end-to-end support for other packages needing xattrs not
necessarily related to PaX. I took the harder but "correct" path and
wrote a wrapper. My first wrapper was written in python and worked
great except it was slooooow --- actually I had one in bash which used
associated arrays but that requires bash4 and portage only supports
bash3! I rewrote the wrapper in C and it worked great when I by-passed
the portage install machinary and used it directly, but the point was to
get it working in portage! I finally traced the bug down to how the
environment $PATH changes during the ebuild phases and added
intelligence to the C wrapper.
Anyhow, I'd like victims ... err ... I mean testers:
1) Have USE=xattr and PAX_MARKINGS="XT" in you make.conf file
2) Your kernel should have CONFIG_PAX_XATTR_PAX_FLAGS=y. If you are
brave have CONFIG_PAX_PT_PAX_FLAGS not set.
3) emerge =sys-apps/install-xattr-0.2, sys-apps/elfix. If you can
emerge elfix with USE="ptpax xtpax" but if you are brave try USE="-ptpax
xtpax". You must have at least xtpax in there.
4) You need to apply the following patch to portage:
https://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9089c2d755b0ecb1b340fc23dda461163f589c43
You can just manually apply it after `cd /usr/lib/portage/`
5) Then emerge any package needing pax markings (maybe not python just
in case something breaks). Like johntheripper which should give
~ # paxctl-ng -v /usr/sbin/john
/usr/sbin/john:
PT_PAX : -emr-
XATTR_PAX : -emr-
or just
/usr/sbin/john:
XATTR_PAX : -emr-
If you removed all PT_PAX above.
Let me know if you hit issues. The final step will be to just make sure
our releases have XATTR_PAX markings and that we document how to
properly installed them so you don't loose the markings.
Finally, some may wonder, why XATTR_PAX markings? The main reason is
that it doesn't touch the ELF binaries and makes them more consistent
with what other distros ship. Also, marking can be done while the ELF
is busy (eg `paxctl -m /bin/bash`, leads to "Text file busy" but you
can always do `paxctl-ng -lm /bin/bash`, ie set only XATTR_PAX). This
allows you to work with a live system which is useful if you ever need
to do a revdep-pax to migrate pax flags from a library to the
executables that link against it. The disadvantage is that xattr
support requires more work and so are more fragile.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
