[ubuntu-hardened] Re: Collecting NX information

[John Richard Moser]

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



Arjan van de Ven wrote:
>>>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.
> 
> 
> actually right now the toolchain marks things automatically correct.
> If gcc emits a stack trampoline, it gets marked needing executable
> stack, if gcc can prove it doesn't need executable stack, it gets marked
> as such as well. 
> 

And the toolchain emits a -E library with PT_PAX_FLAGS if there's a
stack trampoline :)  But it's defficient right now, doesn't inherit when
you link to a library with -E. . . you can fix that right?  :)

The result would of course be executing trampolines on a no-exec stack.

> I *really* don't understand why you want to get away from automatic
> marking to something manual, which *has* to be more fragile.
> 

/me shrugs.  It's a security blanket for him mostly; he fears automagic
security maintainence.

> 
>>Remember also I'm very much against "let the compiler guess if you need
>>an executable stack"
> 
> 
> it's not guessing. the *compiler* emits the stack trampoline. So the
> *compiler* knows that it needs that stack.
> 

With a trampoline, things like Grub and a few libs need PT_GNU_STACK.
The EMUTRAMP stuff will let you modify the toolchain with the
PT_PAX_FLAGS patch and a bit of your own ingenuity (as linking against
an EMUTRAMP marked lib won't mark the binary emutramp yet, but should)
to leave the stack non-executable.

Of course you can't just suddenly say "OH!  Well PT_GNU_STACK should do
this instead!" because you'll break everything.

> 
>> 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.
> 
> 
> the problem is that code coverage is about 10% at most that way.
> Sorry...
> 

:( yeah, no turring complete tests.

>>And again, beyond being a tristate, marking it for PaX would mark it for
>>ES and mainline (i.e. amd64) implicitly.
> 
> 
> again what does tristate mean.. "I don't know" ? But gcc does know, with
> very very very few exceptions. Eg old mono is the exception because it
> didn't do a proper mprotect. Saying "I don't know" doesn't solve you
> anything, since in the end there needs to be a policy enforced anyway,
> it's just postponing the inevitable to a point with less knowledge.
> 

Remember I'm also thinking of restricted mprotect() situations as well,
because I'm trying to get it to the point where one set of markings has
a predictable effect on any kernel, be it vanilla, pax, or ES.

>>>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.
> 
> 
> it's better to just fix alsa lib like we did... :)
> 

Obviously, always.

> 
>>>>Consider that PT_PAX_FLAGS are all tristates.
>>>
>>>
>>>I think that's a bad idea though.
>>>
>>
>>Bad idea being why?
> 
> 
> because unless you have a clear reason for tristate it makes no sense in
> my book. If an admin wants a different effect of a flag he can change
> it, but for this kind of thing "maybe" doesn't really exist. (Ok you
> could argue that total absence of a flag means maybe, that I'll agree
> with).
> 

Absence of a flag means "Secure in hardmode, compatible in softmode."
It's a failsafe for "somebody did something new in a lib I -need- and
GCC can't detect it!"  Just boot in softmode if the machine becomes
unbootable; or make a softmode personality if you're having issues with
a build system (mono under PaX for instance; obviously this doesn't
apply to ES).

> 
>>>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
> 
> 
> what I'm saying is that your proposal about what to do with "I don't
> know" doesn't make sense to me. Sure it's a nice theory, being able to
> say "I don't know you sort it out". However at the end of the day (well
> in the kernel that actually needs to make a decision), a decision needs
> to be made ANYWAY. Postponing is NOT the right thing if you can know the
> result, or assume a reasonable and safe default. All these things have
> 99%+ "safe" with very few exceptions, and those exceptions aren't "I
> don't know" they are "I know they need this off".
> 

You keep saying non-set tristate is "I don't know," but I'm quite aware
that:

H  S
P  p
s  s
e  e
M  m
R  r
x  x

There's a defined difference.  I've leveraged that quite a bit
(especially when PaX wants to kill mono as it builds, or when I don't
feel like marking up Java yet but want to build db).

> 
> 
>>Inline assembly.
>>
>>It may have been fixed since last year.
> 
> 
> non-PIC assembly is a problem sure
> 
> 
>>>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.
> 
> 
> well you could just change the marking if you wanted.
> 

I could, sure, there's a viable 150mS race condition:

make
build lt-mono
<STOP!!!!!!!!>
<Mark up lt-mono>
<send SIGCONT>
use lt-mono to continue building.

I couldn't find out how to run paxctl on lt-mono while vgrepping mono's
hell of a build system, so I'd have to SIGSTOP it just after lt-mono was
written.

> 
>>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.
> 
> 
> My experience in the last few years is that you can get this right
> without such opt-in behavior.  Postponing the decision doesn't help.
> 
> 

*shrug*  My perfect world is one where we say "screw them, they can mark
or fix their shit like everyone else" for anything outside the
distribution's control, i.e. independent vendors.  I don't think this is
viable yet.

> 

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

iD8DBQFCSaeJhDd4aOud5P8RAvOvAJ9f8PtciD7zZso3GrIG76AmE74XLQCcCEFo
GVBGgHVI9cKXHlVbJLyF/U0=
=mGGD
-----END PGP SIGNATURE-----