Re: thoughts on kernel security issues

[Ingo Molnar]

* John Richard Moser <nigelenki@xxxxxxxxxxx> wrote:

> Split-out portions of PaX (and of ES) don't make sense. [...]

which shows that you dont know the exec-shield patch at all, nor those
split-out portions. At which point it becomes pretty pointless to 
discuss any technical details, dont you think?

> PT_GNU_STACK annoys me :P  I'm more interested in 1) PaX' full set of
> markings (-ps for NX, -m for mprotect(), r for randmmap, x for
> randexec), [...]
>
> I guess it works on Exec Shield, but it frightens me that I have to
> audit every library an executable uses for a PT_GNU_STACK marking to
> see if it has an executable stack.

here there are two misconceptions:

1) you claim that the manual setting of markings is better than the
_automatic_ setting of markings in Fedora. Manual setting is a support
and maintainance nightmare, there can be false positives and false
negatives as well. Also, manual setting of markings assumes code review
or 'does this application break' type of feedback - neither is as
reliable as automatic detection done by the compiler.

2) you claim that you have to audit everything. You dont have to. It's
all automatic. _Fedora developers_ (not you) then check the markings and
reduce the number of executable stacks as much as possible.

> [...] ES' NX approximation fails if you relieve protections on a
> higher mapping-- which confuses me, isn't vsyscall() a high-address
> executable mapping, which would disable NX protection for the full
> address space?

another misconception. Read the patch and you'll see how it's solved. 

> Aside from that, I just trust the PaX developer more.  He's already
> got a more developed product; he's a security developer instead of a
> scheduler developer; and he reads CPU manuals for breakfast. 

this is your choice, and i respect it. Please show the same amount of
respect for the choice of others as well, without badmouthing anything
just because their choice is different from yours.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/