Ubuntu Hardened work, implementation and deployment schema
John Richard Moser
nigelenki at comcast.net
Sun Mar 27 13:16:53 CST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brandon Hale wrote:
> On Sat, 2005-03-26 at 23:18 -0500, John Richard Moser wrote:
>
> You have PaX by default, but not PT_PAX_FLAGS. Perhaps that should be
> on by default too. It's quite well tested in gentoo.
>
>
>> PaX by default at this point would be a maintainability nightmare. I'm
>> sure you'll recall the maintainence problems in Gentoo.
yes, but PaX is set on by default in Lorenzo's diagram. I was
suggesting PT_PAX_FLAGS to be default as well, as it's well tested to do
nothing to a vanilla and to work with PaX.
>> This will be
>> greatly worsened by the retirement of PageExec, and the Ubuntu kernel
>> team will surely not appreciate great delays and/or extra work for every
>> upstream release (and some security issues, you will recall binfmt_elf).
>> I've demoted PaX to Universe on our wiki page, but include PT_PAX_FLAGS
>> in Main.
Alright
>> This will still require a good discussion of the pros and cons
>> of PT_PAX_FLAGS over PT_GNU_STACK, which is currently less intrusive and
>> supported by ES and mainline NX code.
Couldn't binutils emit both in the interim? Also as I said before in
another post, it may be more robust to patch vanilla and ES to use
PT_PAX_FLAGS, as PT_PAX_FLAGS supports a wider range of options, some of
which map well back to mainline NX code and ES. I'd like to see
everything maintained once; if it works in PaX, then ES and mainline
should also work with it.
>> Besides the binutils patch I can't
>> imagine any overhead added by simply supporting PT_PAX_FLAGS as well,
>> however. If we begin marking packages at build/install time the
>> duplication will be apperant however.
duplication with chpax/paxctl? It's called a "transitional phase" I
believe, which would continue until the PT_PAX_FLAGS can make it to
mainline binutils and everyone catches up. As I said above, forming a
good mapping between PT_PAX_FLAGS and PT_GNU_STACK for ES and Mainline
and then eliminating PT_GNU_STACK would probably be the most robust
solution.
>
>> PS, why did we make our own list and continue to CC -devel?
>> Let's stop this on the next thread please.
>
>
> Lorenzo Hernández García-Hierro wrote:
>
>>Hi,
>
>>I've made available the schema that explains how the Ubuntu Hardened
>>project is organized in terms of implementation, deployment and work.
>
>>It's a relation of the changes made or going to be made to both userland
>>and kernel level, the packages related with them, what they provide and
>>the priority or importance that they have.
>
>>It's currently available at
>>http://pearls.tuxedo-es.org/misc/ubuntu-hardened-schema.png
>
>>Comments appreciated ;)
>
>>Cheers,
>
>
> --
> All content of all messages exchanged herein are left in the
> Public Domain, unless otherwise explicitly stated.
>
> Creative brains are a valuable, limited resource. They shouldn't be
> wasted on re-inventing the wheel when there are so many fascinating
> new problems waiting out there.
> -- Eric Steven Raymond
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCRwalhDd4aOud5P8RAnm6AJ95uOQtM2doFs/H/2Qnglmj4mBtLACfcHqW
hDAuTFQdEDPu/4DbM8ewxLo=
=h1b4
-----END PGP SIGNATURE-----
More information about the ubuntu-devel
mailing list