[ubuntu-hardened] Re: Collecting NX information
John Richard Moser
nigelenki at comcast.net
Tue Mar 29 02:29:51 CST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
> On Tue, 2005-03-29 at 02:53 -0500, John Richard Moser wrote:
>
>
>>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)
>
>
> how is this one different from PT_GNU_STACK
>
PT_GNU_STACK is on/off, PT_PAX_FLAGS settings are all on/off/neutral.
The neutral state becomes on or off depending on whether some kind of
compatibility mode is used.
>
>>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
>
>
> do you actually need this? the number of apps that have actual
> trampolines is *really really* low. At that point you get to a balance
> between complexity and very limited added security. And the answer is
> really not straight forward since complexity is a security risk in
> itself; or more direct, by allowing this at all you in theory can open
> other security holes. (note the "can" here. I'm not saying the
> implementation does, but there sure is added complexity which in turn
> means added chances for bugs. If the number of things that need this is
> really low (and it should be) the balance isn't so clear).
>
- -rw-r--r-- 1 root src 10485 Mar 29 00:47 emu_tramp.diff
I was surprised it wasn't that complex, but I still need to verify that
I got everything. This emulates the PLT on parisc as well, though I
question if I got it all.
I'm confused because I only found stuff on x86 and parisc (two archs,
10k). Either way, per arch it's not very much.
>
>>.
>>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).
>
>
> This one could in theory be useful. However need info on what breaks. I
> know that if you do full blown ES/PaX level randomisation the build
> process of some older emacsen, and build process won't benefit from such
> a flag unless you can make the toolchain insert it automatic (I suspect
> that will be hard); once it's manual and during build only using setarch
> is sufficient to cover that one.
There's a patch that makes the toolchain spit out PT_PAX_FLAGS.
Consider that PT_PAX_FLAGS are all tristates. A compatibility mode
personality (think linux32 for 64 bit systems) could allow for a shell
to be spawned (`nopax make` or something dumb like that) which puts
everything into softmode. Anything not marked (binutils with the patch
emits ----x- PT_PAX_FLAGS, hard-disabling RANDEXEC because it's a bad
hack) will of course run as if it had psemrx (emutramp is useless anyway
with an executable heap/stack) in softmode and PSeMrX (emutramp isn't
used by default, near nothing needs it so why risk a "potential security
risk" if it even is) in hardmode.
Just remember to mark whatever needs it after it's built, i.e. Oracle.
>
>
>
>>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.
>
>
> Is this what PIE would be for? Eg if you change binaries why not just
> change them to be PIE ?
>
Not everything (mplayer! And last year KDE really hated it too)
compiles PIE. Of course, RANDEXEC in PaX and probably any other bad
hacks falling under this are probably "avoid at all costs" anyway, but
if you *really* want to. . . .
This is more "PaX has it, let's keep it" than anything really useful. I
personally hate RANDEXEC because it's like a lottery; sometimes it kills
things, sometimes it runs slow as ass, and sometimes it manages to do
what it's supposed to do. Any other unfriendly, ugly hacks to randomly
place stuff that can't be randomly placed will probably behave the same.
>
>>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.
>
>
> Actually SELinux currently has stuff for this. Does this need to be in
> the binary or would SELinux policy be enough (I assume that any hardened
> linux distro nowadays also enables selinux so this question is quite
> relevant).
>
See my other reply, an LSM hook would be nice for reading PT_PAX_FLAGS,
controlling them just before they're finally applied.
>
>
>
>>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.
>
>
> actually fc4 and such don't have that many markings so I wonder what the
> usefulness is. (most of the spurious markings we had in the past were
> due to assembly files not being correctly marked, not due to recursive
> functions)
>
To get rid of the rest of those few markings? Particularly Alsa used to
have TWO nesteds. . . .
>
>>>to achieve that you need to get the toolchain to omit this stuff
>>>automatically somehow.
>>>
>>
>>Emit.
>
>
> eh yeah need coffee ;)
>
3:30 AM here, should sleep :) Next reply in 10 hours.
>
>>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.
>
>
> since you duplicate PT_GNU_STACK exactly it seems (well inverse meaning
> but a ! in C is cheap) I think there's no point in obsoleting
> PT_GNU_STACK. I realize some people see PT_GNU_STACK as an Exec-Shield
> thing and thus evil, but lets ignore all that politics and stick to
> facts here: No need to obsolete/remove existing things if they're not
> broken and are good enough.
No, it's not that. I have no problem with PT_GNU_STACK doing what it
does, but it's a whole field where PaX already has a 2 bit tristate.
I'm also told that PT_GNU_STACK is on/off, not tristated. No need to
maintain 2 fields; and the tristate is perfectly perfect for making a
compatibility mode/personality that actually honors "we definitely know
this is good so we marked it hard."
Again, I'm interested in falling back to PT_GNU_STACK when PT_PAX_FLAGS
isn't there. PT_GNU_STACK support will probably hang around quite long;
it can be moved off of in the same way a.out was moved off of-- slowly
and painlessly, as everyone feels like it.
>
>
>
- --
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
iD8DBQFCSRH9hDd4aOud5P8RAsVDAJ9/UpFtawuKUhEA4ipKusqL3KgRMQCfcDEo
+1p00Js7m+baDLQg+wB/ZP4=
=E+5A
-----END PGP SIGNATURE-----
More information about the ubuntu-hardened
mailing list