Re: thoughts on kernel security issues

[John Richard Moser]

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



Ingo Molnar wrote:
> * 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?
> 

I'm shoddy on ES details, but I was more remarking on the overlapping
functions between PaX and ES.

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

PaX has trampoline detection/emulation.  I think the toolchain spits out
libraries with -E when there's one.  It's not inherited from libraries
to the executable though; but a quick hack to trace down everything from
`ldd` or `readelf` and grab the -E would do the same thing without
giving a fully executable stack.

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

And a distribution maintainer could do the same with PaX.  Once it's
done it's fairly low maintenance.  I know because I've done it myself.
I can determine minimal pax markings on a given binary in about 15
seconds in most cases.

> 
>>[...] 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. 
> 

I've been told it maps vsyscall at a lower address, though didn't
remember until after I hit send.  Is this true?

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

I respect you as a kernel developer as long as you're doing preemption
and schedulers; but I honestly think PaX is the better technology, and I
think it's important that the best security technology be in place.  My
concerns are only with real security, and in that respect I feel that if
I didn't stand up and assert my understandings on the matter that people
may hurt themselves.  I can't put a slave collar on people and use force
feedback to control their minds, but I don't have to keep quiet either.

It doesn't much matter at this point.  If everything goes well, PaX
should show up in a fairly popular distribution soon, so we'll get to
finally see something added that this conversation lacks:  a genuine
large-scale demonstration of the deployment of PaX.  ES has that
already; but until I can see the excellence and the failings of PaX
deployed with a target on the average user as well, I can't make
assessments about which deploys better in what cases and why.

On a final note, isn't PaX the only technology trying to apply NX
protections to kernel space?  Granted, most kernel exploits aren't RCE;
but it's still a basic protection that should be in place.  Wouldn't it
be embarassing to say one day that RCE is so rare we don't need to waste
effort on kernel-level W/X separation, then the next day see an RCE
exploit?  :P  (do it murphy, do it!  >:P)  This is just a generic
observation; as I said, RCE in kernel is rare enough to not be a major
selling point, but it's still a consideration.

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

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7qhthDd4aOud5P8RAkjFAJ0YGEjbpNvu2DEr7DiRicuVcWUwawCdGXV2
/CMT3w5TL7KmnsORwIB850M=
=mrQU
-----END PGP SIGNATURE-----
-
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/