grsecurity forums

Hey Guys,

I'm interested in your thoughts on having every hunk in the entire grsecurity patch wrapped in ifdef or ifndef statements as needed for it's context. This way, disabling CONFIG_PAX and/or CONFIG_GRKERNSEC will have the same effect as if the patch wasn't even there in the first place; it skips over the code at compile time.

Now for grsecurity itself (w/o pax) there is the grsec_disabled.c which is used to replace all the functions with simple returns (effectivly making that function as if it didn't exist) which I guess is OK. Not so much worried about this one, and it only touches 123 files.

It CONFIG_PAX that I'm more concerned with. The PAX patch spans a grand total of 480 files in the kernel source, and *does* change kernel behaviour even when completly turned off (an example; see the thread on Xen viewtopic.php?f=1&t=1913&start=15 )

This basically boils down to two things:

1) is this something you guys want to do
2) if not sooner then later, would you mind if I made these changes and submitted the patch to you for review?

Thoughts / criticism welcome.

cormander wrote:It CONFIG_PAX that I'm more concerned with. The PAX patch spans a grand total of 480 files in the kernel source, and *does* change kernel behaviour even when completly turned off (an example; see the thread on Xen viewtopic.php?f=1&t=1913&start=15 )

first, there's diff -D even though i don't see the point in taking out PaX this way, you might as well just use vanilla then. second, if you want a pure grsec sans PaX then spender is the one to convince, not me (this may very well happen by 2.6.25 anyway as i won't be maintaining PaX the way i used to in the future).

PaX Team wrote:first, there's diff -D

Yes diff -D does help, but there's 480 files that change, and -D doesn't support -r. Even if scripted, it'll take some effort to recreate the pax patch in this way and test it. And that's time away from other developments, unless this was desired and/or someone else could help with it.

PaX Team wrote:i don't see the point in taking out PaX this way, you might as well just use vanilla then

Thing is, grsecurity comes with PaX included. If the pax patch causes problems, even if not enabled; which I see with Xen and hear mention of on other threads on the forum with UML, then this kind of diff format should solve those issues.

PaX Team wrote:if you want a pure grsec sans PaX then spender is the one to convince, not me

I'll wait for his comments I've already been able to merge out the PaX and grsec patches for a grsec-nopax patch, which solves my problems, but the ifdef/ifndef format inside the grsec patch itself would do the work for anyone else who needed PaX disabled in the way I need it disabled in certain situations. And on top of that I won't have recreate the grsec-nopax patch each time a new test patch comes out

PaX Team wrote:this may very well happen by 2.6.25 anyway as i won't be maintaining PaX the way i used to in the future

That's a bummer. I honestly do really like what PaX does for security on my systems, I am just not able to use it everywhere at the moment (and I imagine I'm not the only one). With those situations, grsec-nopax is better then no grsec at all, since I use the RBAC system quite heavily.

The kind of stuff PaX defends against makes me wish it was merged into the kernel tree outright so we wouldn't have to deal with these kinds of things; give everyone else in the world the added benefit/headache that the additional security provides. And I'd bet a good deal of money that the kernel dev guys would merge the PaX patches with the diff -D format long before they'd take it as-is (and probably leave it disabled by default). But then again, that's just the world through my eyes.

Hope you keep up the good work.

If I am not mistaken much of the code in the vanilla PaX patch is fixes to the mainline kernel, so you would not want to ifdef all of it out anyway.