[grsec] consider splitting grsecurity

[Peter S. Mazinger]

On Mon, 8 Nov 2004, John Logsdon wrote:

> 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 real target is to have following situation:
if I patch a kernel w/ only pax and another w/ grsec, and diff these, I 
should see only the grsec part. There is only one place that can be 
argued for where accounting is left of for VM_MIRROR, that should have any 
CONFIG_PAX in it, the rest is not necessary and is prone to errors.I don't 
want to compare all the time a release is made (or the cvs) to see if 
something was missed, that happened too many times in the past.

I do not know cvs, but is it not possible to have 2 trees mixed, one 
containing only the pax part, and the full one containing both. The pax 
part can be maintained by the PaX Team, and the rest by Brad/others.

Peter

> 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
> > 
> 
> _______________________________________________
> grsecurity mailing list
> grsecurity at grsecurity.net
> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
> 
> 

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