Re: [ubuntu-hardened] Re: Collecting NX information

[John Richard Moser <nigelenki@comcast.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Arjan van de Ven wrote:
>>You need to consider that in the end I'd need PT_GNU_STACK to do
>>everything PaX wants
> 
> 
> why?
> Why not have independent flags for independent things?
> That way you have both cleanness of design and you don't break anything.
> 

In the end I want to fine-tune for what the best behaviors are, and then
define exactly what the flags should do.

Right now, my rough sketch is:

MF_PAX_PAGEEXEC
  ON:   ET_EXEC enforced.  Stack NX.  Heap NX.  Code PROT_EXEC.
  OFF:  Stack and heap default to +X
  The PAGEEXEC flag will basically mandate the automated non-executable
  setting for the stack and heap.  When off, these areas are executable
  (like when PT_GNU_STACK is on)
MF_PAX_EMUTRAMP:
  ON:  Trampolines (in NX stack) and PLT will be detected and emulated
  OFF: Stack needs to be +X for trampolines to work
  The EMUTRAMP flag will basically allow certain known exceptional
  conditions to be trapped and allowed somehow automatically.  This
  includes mainly nested functions on a non-executable stack, and parisc
  procedural linkage tables (binutils patch can fix these apparently).
  This is off by default in hardmode, but on by default in soft or
  compatibility mode if PAGEEXEC is manually on.
MF_PAX_RANDMMAP:
  ON:  stack, heap, mmap() base randomized
  OFF: Nothing is randomized in memory
  RANDMMAP should probably be called "RANDADDR" instead.  When set, the
  kernel randomizes anything that can be randomized in the address
  space (support determining).
MF_PAX_RANDEXEC:
  ON:  Fixed-position things are also randomized
  OFF: Fixed-position things are at fixed positions
  RANDEXEC allows things that normally can't be placed randomly to be
  placed randomly if hacks exist to do it.  Any hacks 100% safe that
  don't cause excess overhead are for RANDMMAP; any that may cause
  instability or excessive overhead go under RANDEXEC.  OFF BY DEFAULT
  in any mode.
MF_PAX_MPROTECT:
  ON:  Enforce certain mprotect() restrictions
  OFF: Normal mprotect() restrictions
  A certain defined set of transitions and creation states are banned
  when this is on.  PaX has these now, nobody else has them and
  apparently nobody else wants them.
MF_PAX_SEGMEXEC:
  Absolutely no effect, reserved for PaX or anything else that
  implements PaX' specific SEGMEXEC emulation method.

Obviously mainline and ES won't do anything with RANDEXEC, MPROTECT, or
SEGMEXEC.

RANDMMAP will be useful to control ES and mainline ASLR (on-off switch).

PAGEEXEC being OFF will act exactly like PT_GNU_STACK being ON for
mainline and ES.

EMUTRAMP. . . I think I've got a patch for trampoline emulation, which
should let red hat use Exec Shield with fewer PT_GNU_STACK markings.
Mainline should benefit from this too.  It feels like porting this was
way too easy, so I'll ask pipacs to give it a quick look.

I also don't have a soft/hard mode for mainline.  I expect that mainline
will be more into making softmode (compatibility mode) into a
personality, which makes sense for softmode shells (which I've needed
before, i.e. to compile mono without softmoding my whole system).

Soft/Hard mode controls what flags are set by default.  Each flag has
ON/OFF/NEUTRAL settings (thus each is 2 bits).

HARDMODE:
 MF_PAX_PAGEEXEC, MF_PAX_RANDMMAP, MF_PAX_MPROTECT
SOFTMODE:
 (MF_PAX_EMUTRAMP if MF_PAX_PAGEEXEC is ON)
> 
>>The point is
>>to not break anything, yet to still make things easier for those
>>projects and distributions like Hardened Ubuntu.
> 
> 
> to achieve that you need to get the toolchain to omit this stuff
> automatically somehow. 
> 

Emit.

And there's a patch for binutils that Gentoo uses.  Ubuntu can use it too.

Remember that the way I'm doing it, PT_GNU_STACK is used if there is no
PT_PAX_FLAGS header.  Distributions not using PT_PAX_FLAGS will not care
about the kernel's ability to read PT_PAX_FLAGS, because it will still
behave the same with PT_GNU_STACK.  In other words, if Red Hat updated
the kernel with this stuff today (assuming it's non-buggy), it won't do
shit, and Fedora will still work exactly as expected.

> 

- --
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

iD8DBQFCSQlqhDd4aOud5P8RAgCIAJ4hGeiHD/wcB+B6u9up4v37CT0bAwCeKgcA
zX00s0dqVkkRhnxmmzQLZq0=
=4EMG
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/