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

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



On Mon, 3 Nov 2003 23:42, spender@grsecurity.net wrote:
> > 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.

The problem is that we don't have anyone who has the time and ability to merge 
PaX with the Debian kernel patches.

The exec-shield patch applies with the Debian patches and with LSM.  I am 
prepared to maintain it.  Unless someone volunteers to maintain PaX support 
for Debian kernels then the best available option for Debian users will be 
exec-shield.

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

Debian is not a company, we can't "put someone in charge", we rely on 
volunteers.  If you wish to volunteer to become a Debian developer and 
maintain such things then your contributions would be welcome.

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

Actually I didn't know about the details of X modifications.

The X server does some unusual things and therefore does not get protected in  
a default configuration.  We can get such changes into Debian, but I think 
that we need the kernel patch first.

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

Actually I don't want to make security decisions for users.  This is why I 
initially maintained the Debian patch package for grsec, I have promoted 
OpenWall, I packaged RSBAC (but had to dump it because I didn't have the 
resources to test it and no-one else was interested), and now I'm working on 
SE Linux.

I want the users to have as many choices as possible.

But in the case of memory protection I think that we need to have the default 
kernel offer something.  Surely you will agree that adding exec-shield is 
significantly better than the current situation.

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

The Debian social contract specifies that we will not hide problems.  The 
project is based on free and open discussion.

I have no problems with matters such as this being discussed publically.  If 
someone believes that they can maintain a package better than an existing 
Debian developer then they are welcome to join in.  If you volunteer to do 
PaX work for Debian then I am sure that you can make a good case for PaX in 
the default Debian kernel.

If you choose not to do such work and no-one else who has appropriate skills 
volunteers then I guess that exec-shield will be likely to become default in 
Debian.

This is nothing personal, it's a matter of practicality.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



Reply to: