[ubuntu-hardened] Re: Collecting NX information
Arjan van de Ven
arjan at infradead.org
Tue Mar 29 12:42:30 CST 2005
> > 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.
I *really* don't understand why you want to get away from automatic
marking to something manual, which *has* to be more fragile.
> 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.
> 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.
> 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.
> > 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
> > 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".
> 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
well you could just change the marking if you wanted.
> 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.
More information about the ubuntu-hardened