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