Future of 2.6 support

[Hal9000]

It is not clear if the PaX Team will be able to continue supporting future versions of the 2.6 kernels, given their rapid rate of release and the incredible amount of work that goes into porting such a low-level enhancement to the kernel (especially now in view of the reworking of the i386/x86-64 trees). It may be necessary that grsecurity instead track the Ubuntu LTS kernel so that users can have a stable kernel with up-to-date security fixes. I will update this page when a final decision has been reached.

That's a great idea. I actually quit using vanilla 2.6 kernels cause I was tired of having to upgrade so often, and the grsec patch always being behind, creating new problems etc. I am now using a self-compiled kernel from debian sources, without grsec patch.

If you're going to maintain the patch for Ubuntu LTS and Debian Stable systems, I will be the very first one applying grsec to my kernels again

Greets

Hal

[djGrrr]

if this is what happens, i will most likely never use grsec again

and as far as grsec being behind all the time, recently thats not at all true, the test patches were always really close behind, and usually quite stable.
all my servers run fedora, so unless either the vanilla kernel support is continued, or a fedora patch is maintained (which is unlikely considering that fedora always uses close to the latest vanilla kernel with a tonne of patches) i won't be using something for debian/ubuntu

[cormander]

A distribution that freezes their kernel's version and maintains it via back-ported patches is essentially a fork of the linux kernel. Most mainstream linux distributions do this at least to some extent; RHEL and SLES have kerenls as old as 2.6.9 and 2.6.8 respectively, they still haven't reached their end-of-life, and there are still patches being maintained for them.

Now that development of grsecurity and PaX may not move forward along with the mainstream vanilla kernel, it will have to also essentially be a fork of the linux kernel. This isn't a bad thing, look at some virtualization tools; Xen and OpenVZ. Those are forks of the linux kernel as well, they haven't officially upgraded from 2.6.18 yet (as far as I know). And I have checked a few times, Xen does back-port CVE security patches.

If development can't continue moving forward in the 2.6 tree, then we pretty much have to stick with the 2.6.24.x version. Whether or not Brad chooses to follow a distribution's set of security patches, or maintain his own set, this isn't such a great big deal. It's still a linux kernel, it'll still boot machines which that kernel has drivers for.

I've booted sles9 and opensuse-10.3 with a RHEL5 kernel. I've booted RHEL5 with a fedora 8 kernel. I've booted debian sarge with a RHEL4 kernel. The list goes on and on. I've booted all of the above with both a vanilla kernel and with a grsecurity kernel. I don't believe following patches of a particular distribution are going to break the kernel's ability to boot and serve another particular distribution.

As long as Brad makes his latest grsecurity patch successfully patch a vanilla kernel, he could already be following patches from other distributions and including them inside the grsecurity patch, and you wouldn't have even known it because you patch and build the kernel with grsecurity and it still boots your machine.

It's all about how you package the kernel. If you build a kernel on debian using debian tools, it's far more likely to succeed on that server then if you used a pre-compiled kernel from a completely different distribution. And since all users of grsecurity compile their own kernels on their own systems, we're not going to have a problem.

Right now I'm maintaining the grsecurity kernel as an RPM. It boots CentOS/RHEL 4 and 5, OpenSuSE 10, SLES9, Fedora 8; I haven't tried debian yet but I have no doubt that it'll boot that too (if compiled on a debian server). It all boils down to whether or not your mkinitrd correctly grabs all the kernel modules required to boot your machine. I had a problem the other day where my grsecurity RPM booted my local CentOS machine, but it didn't boot the same CentOS version with all the same packages on a different server with different hardware. I had a look at the initrd that was created at install time, added some modules in there, rebooted, and it came up just fine. For some reason, a module got excluded when the mkinitrd ran; and this could happen to anyone. I've even seen this happen with kernel updates from kernel vendors themselves.

If you actually look at the hundreds of patches inside a big vendor's kernel like RedHat or Novell, most of them are one of the following:

1) fixes to drivers for certain kinds of hardware; software vendors like RedHat have deals with hardware vendors and have to support them
2) fixes to bugs which cause kernel panics (which are generally driver fixes anyway)
3) kernel feature additions such as exec-shield, app-armor, and xen virtualization
4) security fixes, both CVE and non-public/ambiguous patches

Watch a distribution's set of patches, and pick out security relevant ones and throw them into the grsecurity patch. Somebody is going to have to do this to keep the project alive, It's all up to Brad whether or not he does this himself, and either in the form of just patching an already-patched distribution kernel, or patching a vanilla kernel with grsecurity + patches from that distribution included.

I'm perfectly willing to help maintain back-ported security additions to the grsecurity kernel. I'm an avid RedHat user, but personally wouldn't mind if he does choose to follow Debian or Ubuntu because the kernel will still work on machines running a RedHat based OS.

[Hal9000]

I don't know much about the RPM world, but what I can say is that a patch maintained for the debian stable kernel sources would be great. Would not require much effort by the grsec devels, the kernel sources are being maintained by debian, and only security fixes get in, most of which have no impact on grsec's patches. So the debian grsec maintainer just has to check if the patch still can be applied / compiles when the kernel-source package gets updated. Same goes for Ubuntu LTS, of course.
In my opinion it would be easier to maintain a grsec patch for say, 3 or 4 stable distro kernels (debian stable, ubuntu lts, redhat...) rather than always having to keep up with new vanilla kernel releases. The grsec guys could focus on the patch itselt, and adaptations would not be required so frequently and not require a lot of effort.

[cormander]

One thing I failed to mention was, although I would support Brad's decision to lock the grsecurity kernel version and follow a distribution or two for security updates, it would be tragic.

If the PaX Team is unable to continue forward development in the 2.6 tree, then we simply need more people on the PaX Team. I'd join myself, but my kernel development skills are limited at this point.

I'm currently headed in the direction of coding more regression tests for grsecurity, pre-configured policies for various systems, and write a policy configuration program (as an extension to the grlearn). But editing the kernel source, particularly in the area of PaX, is way beyond my area of focus.

I've been speaking to different professionals I have contacts with, and there is quite a bit of buzz on this subject beyond what's happening on the forums and mailinglist. It's my hope that grsecurity ends up with more people actually contributing code. But for the time being, if no one else steps in to help, looks like grsecurity might be forced to follow 3rd party security patches so that it at least stays afloat.

[Kp]

Another avenue to consider for this is to try to push some of the PaX/grsecurity changes upstream. I've read in other threads here that Brad / PaX Team tried this a few years ago and encountered fairly heavy resistance. However, it's not clear whether the attempt then was a few large patches or many tiny patches. If someone has the time and motivation to try this, pushing changes upstream could simplify maintenance of the grsecurity kernel since it would be closer to vanilla. I'd suggest picking a few of the smaller fixes and pushing them as one submission per feature. If that works out, move on to bigger and harder things.

Brad's comments about LSM make me think that upstream will never accept the grsecurity ACL model, but as I understand it, even getting large chunks of PaX pushed upstream would be a big timesaver for the grsecurity project. If I recall correctly, PaX is usually much more sensitive to the rampant subsystem rewrites than the grsecurity code.

[cormander]

I agree fully. Since LSM is the "de facto" for manditory access control, grsecurity RBAC wouldn't make it. Perhaps some of the other features like chroot hardening, kernel memory/io protections, TPE, and proc restrictions could be submitted little by little.

I was speaking with someone who was a kernel contributor about this subject a few months ago, and from what I remember, the kernel dev guys needed a compelling reason to put all these in. Not quite sure what that means... it should be compelling enough reason that grsecurity has such a large userbase.

If PaX was pushed into upstream, I would be bouncing off the walls. Even if it was disabled by default and marked EXPERIMENTAL it would be an enormous win. The PaX patch does touch a far greater number of files then just grsecurity does. Problem is, I don't think the rest of the kernel maintainers want to deal with such sudden and extensive patch. It would probably affect them all, at least in some way. I don't know how possible it would be to submit one piece of PaX at a time - perhaps Brad or the PaX Team can comment on this....

Also a matter of note, even the presence of the PaX patch breaks some key features of the linux kernel such as Xen. Patch a vanilla kernel with PaX, enable xen domU support, and try to boot it; it doesn't work. It crashes badly. This is why I maintain a grsec-nopax version of the kernel, so it can boot a grsecurity kernel under Xen. IMHO grsec w/o PaX is better then nothing at all.

Too bad I'm not close buds with any upstream kernel maintainers. Perhaps it's time to start making some new friends

[spender]

We've gone over this many times. Neither PaX nor grsecurity will be accepted into the kernel. Just getting it into the mainline kernel doesn't solve any problems anyways. If there is no maintainer for some code, it gets removed. If no one will work on PaX outside of the mainline kernel, no one will work on PaX when it's in the mainline kernel.

-Brad

[Kp]

This isn't about foisting maintainership off on the mainline devs. I recognize that you'd still need to find a maintainer for PaX, mainline or not. Various posts from the PaX team have implied that a lot of the maintenance for PaX is because mainline keeps changing areas that PaX touches. At minimum, this means that the patch doesn't apply cleanly and someone has to look at the source, fix up the patch, and maybe rewrite some or all of it to cope with the new semantics in mainline.

There's no guarantee that any particular kernel is buildable in all possible configurations, but I thought it's generally accepted that you don't submit changes that clearly break mainline configurations (i.e. a state you can reach just by choosing a particular set of .config options, without patching the source, is a "mainline configuration"). If the patch is in mainline, then there's an implied burden on mainline committers not to break the PaX code without good reason. In particular, I'm thinking of the features that result in snippets like

Code: Select all

#ifdef CONFIG_PAX_KERNEXEC
    pax_open_kernel(cr0);
#endif

scattered through parts of the kernel. There's zero burden on mainline to let those fragments sit there (yes, I know KERNEXEC is more than just that, and mainline might object to having the meat of KERNEXEC sitting around unmaintained), and there's a win for the PaX team if somebody moves the function and brings the PaX patch along since it happens to be there. If the PaX patch is out of tree, then the out of tree maintainer has to track down where the function went and hand patch the new version. It may not be hard to do those updates, but it's menial work that could be avoided.

[nkukard]

Why not GIT grsecurity and get some of us competent coders (or distro maintainers) to help you out??

Don't under estimate how much grsecurity is being used or what the people packaging it are capable of.

Rather ask for help, and ideas on how to continue the project and keep it up to date rather than shutting out most of the people using patches on vanilla kernels for non-mainstream distro's.

[john_anderson_ii]

I'm not opposed to PaX & GRSecurity only following a few popular distributions' kernel. PaX & GRSecurity are a lot of work, and the 2.6 kernel is changing constantly. The mainline kernel is no longer maintaining a 'stable' version and backporting bug fixes into it. They are just forging ahead and letting the distributors deal with maintaining an up-to-date steady kernel version. I can understand how much of a challenge it would be to keep up.

However, nkukard is right, the users of unsupported distributions don't have to be out of luck. PaX/GRSecurity has fairly talented and fairly large community. It just needs to be leveraged. For instance, bplant & I have already got the GRSecurity patch set running on vanilla Xen. I'm almost certain that there are members on this forum who could take the 'official' patch for Debian and port it over to Fedora's stable kernel or something like that. With the support of Spender & the PaX team, who will have a lot more free time I don't think community customized versions of the 'official' patches for other distributions is out of the question.

The other approach to leverage the community is also a good idea. I'm sure the PaX team could use more developers. However, I'm of the opinion that it takes a much higher skillset to actively develop PaX/GRsecurity than it takes to kludge patches and fix rejects. So finding developers with both the required skills and the desire to contribute to PaX/GRSec is going to be more difficult than finding users with the required skills to port over the 'official' patch to their distribution of choice, and then share the port.