[ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

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



Arjan van de Ven wrote:
> On Tue, 2005-03-29 at 03:29 -0500, John Richard Moser wrote:
> 
> 
>>>>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.
> 
> 
> Hmmmm you either need an executable stack or you don't. Can you explain
> why you think there is a strong advantage for a "neutral" setting on
> this one?
> 

As I said, compatibility mode.  The toolchain should not emit
*everything* PT_GNU_STACK and leave it up to you to de-mark it; instead,
everything should be emitted without PT_GNU_STACK set, in which case
violating code would die.

An inheritable compatibility personality would be able to leave a
neutral PT_GNU_STACK meaning ON (exec stack/heap), while hardmode would
leave it meaning OFF (noexec stack/heap).  This is useful for i.e.
building mono.

Remember also I'm very much against "let the compiler guess if you need
an executable stack" and more into quality assurance and testing phases.
 Run the damn thing; when it breaks, mark it.  It's not hard, I spent
several months doing it on Gentoo with PaX.  Each time I found
something, about 15-30 seconds later I had the most restrictive flags
set on it.  Distro does that, packages it up, ships it out.

And again, beyond being a tristate, marking it for PaX would mark it for
ES and mainline (i.e. amd64) implicitly.

> 
>> 
>>
>>>>MF_PAX_EMUTRAMP:
> 
> 
>>>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,
> 
> 
> 10k lines of patch. And you introduce a mechanism to bypass non-exec-
> stack.... sometimes a 10 line patch can be "complex" in that sense.
> So I'll repeat my question about the gains of this, you only answered by
> showing something about the complexity.
> 

I had issues with a few things that simply needed emutramp, i.e. alsalib
needed it for two trampolines.

I want to find out if this even works first, but here's what I got out
of PaX for trampoline emulation:

http://thread.gmane.org/gmane.linux.ubuntu.hardened.general/33

No guarantees that that's all of it; I'm very novice at this.  The code
is very clean though; but I had to figure out wtf was with the stuff in
do_page_fault() and write my own comments.  I probably got that wrong
(it was very much PaX specific), though I'm trying to get that checked.

pax_emulate_trampoline() is a stripped down pax_handle_page_fault().

> 
> 
>>>>.
>>>>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.
> 
> 
> that's not an answer to what I said though. You propose a new
> implementation for something, for that you should say why this one is
> useful, not "because something else does it".
> 

You said you want the toolchain would need to spit out the . . .oh.  You
meant specifically mark PT_PAX_FLAGS with -r automatically.

Like I said, compatibility mode.  Non-set tristate for MF_PAX_RANDMMAP
would be off.  Mark the dang thing manually after the build is over; in
the mean time, don't bother applying any protections to the build process.

Note that in this "compatibility mode," things explicitly marked are
taken as marked (i.e. -----x is taken as psemrx; and PsEMRx is taken as
PsEMRx), so your toolchain can be explicitly protected in case of i.e.
compiler bugs that become exploits.  This of course opens a whole range
of debates about "well maybe some protections should be set by default"
or "should we mark everything" and whatnot, though marking *everything*
kinda defeats the purpose.

> 
>>Consider that PT_PAX_FLAGS are all tristates.
> 
> 
> I think that's a bad idea though.
> 

Bad idea being why?

> 
> 
>>  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. 
> 
> 
> setarch flags are inherited too (not by setuid of course); and that
> mechanism already exists. What does your proposed solution add value
> wise to that?
> 

Honestly, no idea, so I'm not even going to begin to try.

If you're saying setarch would set a certain mode of flags, consider
that I'm talking about finegrained control.  Consider five programs with
the following settings:

PT_PAX_FLAGS:

psemrx
PsE-Rx
PSeMrx
- -----x
P-E--x


Hardmode effective flags:

psemrx
PsEMRx
PSeMrx
PseMRx
PsEMRx


Softmode effective flags:

psemrx
PsEmRx
PSeMrx
psemrx
PsEmrx

Can setarch do that with any other mechanism, or can it just set an arch
where the flags are constantly "psemrx" regardless?  I'm very much into
finegrained control.

> 
>> 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.
> 
> 
> we're talking here about randomisation; I don't see where emutrap comes
> in at all????
> 

Just a comment on why soft/compatibility mode would be PSe instead of
the probably expected PSE.  I don't want you thinking I'm crazy :P

> 
> 
>>>>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. 
> 
> 
> Hmmm we'd need details in a bug report to investigate, I can't think of
> a fundamental reason for this...
> 

Inline assembly.

It may have been fixed since last year.

> (other than mplayer doing the wine thing, which indeed means it needs to
> be very careful to not trump over certain VA regions; but that is a
> separate problem)
> 

Wine should never get RANDEXEC, ever, exactly because of this.

> The rest of your comment suggests that you consider this one not too
> valueable. PIE imo is a pretty nice solution to the problem, and does
> not have the performance costs that you get with forcing non-PIE
> binaries to be randomized.
> 

Yeah, PIE is a very very nice solution.  As I said, personally I don't
like or use RANDMMAP.

Also again, if you want to go with PT_PAX_FLAGS, you can just change
PT_GNU_STACK and nuke it if PT_PAX_FLAGS isn't there; so the binary
isn't necessarily going to be PIE.  Of course, there's still the issue
of this being hackish and ugly anyway; let's just say RANDEXEC is for
demonstrating proofs of concepts or something, because nothing
legitimately good should really be controlled by RANDEXEC.

> 
> 
>>>>MF_PAX_MPROTECT:
>>>
>>>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.
> 
> 
> hmm I again might be missing the point here.... if selinux policy is
> enforcing this behavior, why would the executable need a built-in-the-
> binary flag for this *in addition* ?
> 

Because not everybody is going to use SeLinux (me for example).  I don't
personally believe that mandatory access control is proper for home
users, for example, as they may want to tinker with these settings or
whatnot if they just built something by hand.  An attacker who gets
enough access to tinker with these settings is probably already beyond
them and what they protect anyway.

> 
> 
>>>>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. . . .
> 
> 
> Alsa got fixed for one.
> 

Nice.  Did the second get fixed yet?  Not that it ever gets used
(apparently xmms can run with Alsa without emutramp, even though the
toolchain sets -E on libalsa because it detects a trampoline).

> 
> 
> 
>>>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."
> 
> 
> but the stack thing you KNOW. You either need stack exec or you don't.
> It's like your wife being pregnant, she either is or isn't. Using
> tristates when there is no real third state just looks odd to me,
> especially if the third state is the only advantage of something over an
> existing thing.
> 

Third state indicates that other logic defines this, mainly
"compatibility mode" or "softmode."  I should clarify that I've found
softmode to be immensely helpful in PaX when I didn't feel like tracking
a problem i.e. building Mono down (which would require modifying the
build system to set lt-mono to be psemrx).  It's just another workaround
system.

Also, a kernel-wide softmode allows the flags to be interpreted
different.  Hard-mode is basically "opt-out" of any protection;
soft-mode is basically "opt-in."  In hard mode, unmarked 3rd party
software is protected and may break; in soft mode, unmarked 3rd party
software is not protected and will always work.

A hard-mode scheme would mark all binaries that break to lower the
restrictions; while a soft-mode scheme marks all binaries that work with
all restrictions they work with.  The former is more easily maintained;
while the latter makes sure third party software that doesn't pass the
distribution maintainer always just works.  Obvious advantages and
disadvantages.

Softmode is also immensely helpful if i.e. glibc suddenly decides it
doesn't like PaX and init doesn't run.  Switch to softmode on the kernel
command line (pax has pax_softmode for this) and start fixing glibc.
Other libs can do this with less of a severe impact, glibc is just a
disaster example.

To create these two modes, a tristate setting is needed to store each
marking as ON (opted in), OFF (opted out), or NEUTRAL (depends on mode).
 Of course that's just a loose guide; emutramp and randexec are never
automatically on (one "may lower security" and the other is a dirty hack).
> 
> 

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

iD8DBQFCSZxAhDd4aOud5P8RAqJ0AJ9VaF6NM6P3GHmTTuKuSr9IM8uBBwCdEN91
LkchUrbVSl1B3/SUP2E4wJ4=
=tG1r
-----END PGP SIGNATURE-----