[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: exec-shield (maybe ITP kernel-patch-exec-shield)


> It seems that exec-shield does 99% of what PaX does (PaX is the most desirable 
> feature in GRSec).  Exec-shield also has support for 2.6 and looks like it 
> will be a standard feature in Red Hat.

This comment is false, unfounded, and a slap in the face of both me and 
the PaX team.  Apparently you've not read my presentation slides here:
comparing PaX to W^X and Exec-shield.  Had you read it, you would 
understand that Exec-shield doesn't even do 50% of what PaX does.  
Exec-shield doesn't support the architectures PaX does.  Exec-shield 
doesn't do kernel stack randomization or non-executable kernel pages.  
It can't guarantee that when a task is fully loaded, that its mappings 
are W^X, even if it didn't request such mappings.  It has less 
randomization than PaX in all areas.  HOW do you figure that exec-shield 
does 99% of what PaX does?  Where's your research?  You have clearly 
done no research whatsoever, so please spare the debian users of your 
ignorant tripe.

> Maybe we should solve the debate about grsec and standard kernels by adding 
> exec-shield to the standard Debian kernel source?

Go ahead and do it.  I could frankly care less if your users get owned.  
Give them a false sense of security by telling them that Exec-shield 
is a substitute for grsecurity and PaX.


> Exec-shield is apparently in Fedora already, and has been tested extensively 
> inside Red Hat.

Apparently not too extensively.  Maybe you forgot a few weeks ago an 
exploitable bug was fixed in Exec-shield.  It had been in the code since 
it was first written.  Was this found by the "extensive testing" by 
RedHat?  No, they were just lucky that someone ran paxtest on it, and 
found the 4k of writable and executable bss/data.  There's another 
exploitable bug in Exec-shield that I've known of for months.  Maybe 
you'll find it after you put it into Debian.  Maybe not.  This is what 
happens when you make rush judgements and choose to use something based 
solely on who developed it.  Where's the attack model?  Where's the 
explanation of why the randomization is done the way it is?  They don't 
exist.  How do you expect to make any kind of informed decision if 
you have no idea what you're talking about?  Why should anyone listen to 
what you have to say when you've done no research?  "It works for 
RedHat" and "I've been using it for 2 days" is not research.

> We have recently discussed grsec, and it seems that we will not get grsec as 
> either a default part of the Debian kernel, or as a patch that can be applied 
> to a Debian kernel.

I've read the post regarding grsecurity and Debian, and I must say 
that I've never seen a bigger bunch of lazy whiners in my life.  Maybe if you 
actually put a kernel hacker in charge of these patches, you'd realize 
you have been whining for months for no reason.  Did you ever think that 
putting someone in charge who can code in C might help?  Or were you 
planning on relying on diff fuzz for the next couple years?


> I quickly checked out paxtest, there are a number of issues listed as 
> "Vulnerable", but I believe that some of those are necessary for full 
> functionality of programs such as X servers.

You believe incorrectly.  You work at RedHat.  You must know they've 
modified X so that it works properly with Exec-shield.  You must know 
that PaX doesn't break X, but rather that the bug in X causing the 
problem is only visible when PaX is used.  Stop spreading these lies, 
and blowing off the ineffectiveness of Exec-shield.


Since this is probably the fourth time I've had to correct you on making 
false, unresearched statements publicly, I'm cc'ing this one to the 
list, to show your users who's making their security decisions for them.
I've tried to do it in a more professional manner before by not 
embarrassing you in front of your peers, however you don't seem to want 
to stop this habit, which at this point I believe verges on 

I'm going to point out your mails to the PaX team, and they will comment 
on them as well if they see fit.

Feel free to reply after you have done the research I've done on the 
subject and can make a factual counter-argument.


Attachment: pgppEhY1blOel.pgp
Description: PGP signature

Reply to: