[grsec] consider splitting grsecurity

[John Logsdon]

While I can see arguments for separating grsec and PaX, I suggest instead
a more sensible way forward.  This could include, for example, changing
the CONFIG variables back to the PaX variable names or at least including
the up-to-date PaX patches (almost) automatically.  Fragmentation of the
code would lead to fragmentation of the community which is not a good
idea.

What happens for example where a new version of the kernel 'breaks' some
part of grsec or PaX (as I gather has happened in 2.6)?  Do you end up
with a half-way house or is it not better to fix the issue?  

It depends on the source of the break.  If the origin of the break were in
grsec or PaX then it should be fixed anyway.  

But if it is in the kernel and the kernel-managers (Linus, Alan etc) take
the view that because grsec and PaX are not mainline kernel then that is
not their problem, the argument would have to be made to change the
kernel.  Separation of grsec from PaX would weaken this argument to
correct the kernel 'error' because individual users could run one without
the other and so may chose to reduce their protection.  ie the user group
would have become fragmented.

There is also a problem in separating PaX from grsec as seen by the user.
The gradm administration program already provides facilities to control
both grsec and PaX.  What would happen for example if this were run on a
kernel from which PaX had been excluded yet the appropriate subject flags
had been included?  Appropriate checks could be inserted and these flags
ignored with a warning message but the more fragmented both the kernel
patches and administration code becomes the more difficult it becomes to
maintain.

I recognise that there is an issue of developer community - which was
essentially Brad alone but now with some help from Michael in userland -
but there have been patches suggested by others incorporated and all
projects need an overall project manager or again forking will occur.

For example, nothing really gets put into the vanilla kernels that doesn't
have Linus' agreement even if the actual patches are written by others.  
Given that grsec is a lot smaller than the kernel so most of the patching
can be done by Brad who understands the code in complete depth, I don't
see too much of a problem here.

In principle it must be better to keep the parts together but Peter's
concerns are real.  There is a need to improve the maintainability to that
grsec+PaX is always up to date from a PaX point of view.  That way we keep
a community of users.  Separation is a route to fragmentation and
division.

My £0.02-worth anyway.

John

John Logsdon                               "Try to make things as simple
Quantex Research Ltd, Manchester UK         as possible but not simpler"
j.logsdon at quantex-research.com              a.einstein at relativity.org
+44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com


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

> > 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.
> 
> I've gone through an entire check of the differences between grsec and 
> PaX and copied over the changes (page.h, fixed pageexec config, amd64, 
> mips, mips64, ia64 support).
> 
> -Brad
> _______________________________________________
> grsecurity mailing list
> grsecurity at grsecurity.net
> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
>