[ubuntu-hardened] Re: Collecting NX information
John Richard Moser
nigelenki at comcast.net
Tue Mar 29 13:07:54 CST 2005
-----BEGIN PGP SIGNED MESSAGE-----
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
>>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
>>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.
:( 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... :)
>>>>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
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
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).
>>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
>>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
> well you could just change the marking if you wanted.
I could, sure, there's a viable 150mS race condition:
<Mark up lt-mono>
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
>>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
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
-----END PGP SIGNATURE-----
More information about the ubuntu-hardened