[grsec] consider splitting grsecurity

[Peter S. Mazinger]

On Sun, 7 Nov 2004 spender at grsecurity.net wrote:

> > I am poking on this issue again, because I began to look into grsec-2.x 
> > (yes, I have used and will use grsec-1.x until gradm2 won't fail on 
> > learning ;) and found too much discrepancy between pax and grsec (compared 
> > the latest cvs, where pax-2.4.27 is added).
> > It would be easier to maintain and keep in sync.
> > 
> > Why can't we "build" a community who makes development on grsec?
> 
> I've already said why I won't split up the patches, but I'll repeat the 
> reasons again:
> 
> 1) grsecurity is not meant to be separated into multiple parts.  
> Splitting it up into multiple parts encourages improper usage.  If the 
> reason is that you want to use SELinux or RSBAC, go ahead and use them.  
> Their fans claim that these are flexible systems that could do anything 
> grsec does, so clearly there is no reason for using grsec at all.  Just 
> put SELinux and PaX together and your system will be secure.  Promise.

better combination would pax+grsec-non-acl + any other ACL ;)

> 2) I don't see any evidence to suggest that splitting them up will be 
> easier to maintain.  Since all of the patches modify similar areas, it 
> looks in fact that I would have to supply 7 separate patches, for all 
> possible grsec combinations so that these patches could apply cleanly 
> and properly.  In fact, in 2.6 I use the PaX patch directly and it 
> requires much more work to do that than it does to update based on diffs 
> from the pax tree in CVS.

well, then check your diffs, because you have much left out from current 
pax. That's why I say, split it. PaX is maintained separately. There is 
almost no conflict between PaX and the rest of grsec, only where you 
decided to not account from VM_MIRROR (and that haven't changed much in 
the last time), so that conflict can be easily adapted (not considering 
the changes you have done not using asm/page.h and similar, changed to 
use grsecurity/Config.in instead of what was provided by 
PaX, but that does not change any functionality), and it's more accurate, 
consider only the fact that some time ago some PaX option that was
allowed only on 586_TSC was possible on grsec w/o this condition, 
producing some noise/failures.
 
> 3) You have the source, why are you asking me to do the work?  Having me 
> do something that causes more maintainance with no real benefit doesn't 
> sound like a good way to 'build a community'.

I haven't asked you to do the work, I have asked if you are willing to 
develop in a community. I would be glad to do parts of the work (those I 
understand). I would also do the first split of pax and grsec, the 
splitting between non-acl and acl part is more difficult, because since 
you removed the GRKERNSEC_ACL option, you mixed up the used functions.

Would anybody else be interested in such development?

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2