Re: [ubuntu-hardened] Re: Collecting NX information
From: Arjan van de Ven (arjan_at_infradead.org)
Date: 03/29/05
- Previous message: Jens Axboe: "Re: [patch] optimization: defer bio_vec deallocation"
- In reply to: John Richard Moser: "Re: [ubuntu-hardened] Re: Collecting NX information"
- Next in thread: John Richard Moser: "Re: [ubuntu-hardened] Re: Collecting NX information"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: John Richard Moser <nigelenki@comcast.net> Date: Tue, 29 Mar 2005 10:09:21 +0200
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
> 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).
> .
> 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.
> 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 ?
> 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).
> 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 achieve that you need to get the toolchain to omit this stuff
> > automatically somehow.
> >
>
> Emit.
eh yeah need coffee ;)
>
> 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.
-
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/
- Previous message: Jens Axboe: "Re: [patch] optimization: defer bio_vec deallocation"
- In reply to: John Richard Moser: "Re: [ubuntu-hardened] Re: Collecting NX information"
- Next in thread: John Richard Moser: "Re: [ubuntu-hardened] Re: Collecting NX information"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
