# hardened-sources 2.6.24?

## bbee

I'd like to upgrade to 2.6.24 (I want some of the new features) but I don't want to lose grsec/pax from hardened-sources. I checked on the grsec page, and patches are available for 2.6.24. Someone mentioned it on this bug but I haven't seen anything since then.

It's been more than a month since 2.6.24 was released.. Is there any technical reason it's being held back?

I might end up just switching to vanilla-sources, the increased update frequency of vanilla probably more than makes up for any security that hardened provides..

----------

## schachti

 *bbee wrote:*   

> It's been more than a month since 2.6.24 was released.. Is there any technical reason it's being held back?

 

The grsecurity patch for 2.6.24 has been released on "February 19 2008 23:41:27", according to the website - less than two weeks ago.

However, I agree with you that it often takes quite a while until the hardened kernel gets updated in portage.

----------

## Hu

 *bbee wrote:*   

> 
> 
> I might end up just switching to vanilla-sources, the increased update frequency of vanilla probably more than makes up for any security that hardened provides..

 

That depends on which features of the hardened kernel you rely on.  Features like KERNEXEC and UDEREF can mitigate the effects of kernel exploits, and it is true that pulling fixes more regularly may serve a similar purpose.  However, features like non-executable pages, chroot hardening, and the GRsecurity RBAC system serve to mitigate the effects of exploits in vulnerable userland processes.  You could run an ideal kernel with no kernel security bugs, and still be vulnerable to compromise if a privileged userland process is successfully exploited.

Another possibility is that you could harden the kernel manually.  As far as I know, hardened-sources is just gentoo-sources + PaX/GRsecurity patches.  You could start by installing a gentoo-sources package, then manually apply the PaX/GRsecurity patches on top of that.  If the patches do not apply cleanly, you can solicit help here or on the GRsecurity forums.

----------

## wyv3rn

Expect the first hardened-sources-2.6.24 release to hit the tree pretty soon.

In the future.. remember first the kernel has to come out then grsec patch before any attempt to put together a hardened-sources can even begin.  Also, if there are (and usually this IS the case) a lot of changes to the kernel or grsec at the beginning of a release cycle, Gentoo devs may test, find something unsatisfactory and decide to hold off for a bit until things settle and become portage-tree worthy.  Also, if you take a look at the ChangeLog for hardened-sources, you'll see they've been busy giving some final, important, love to 2.6.23.  Remember, the hardened-patches is quite a large patchset to the kernel sources and being more server/security oriented, the Hardened Project tends to be conservative as to what it puts out for kernel releases.

Occasionally you may have to wait an extra week or two for brand-new kernel series, but the Hardened team works hard to make sure a good level of quality is always reflected.

 *Quote:*   

> I might end up just switching to vanilla-sources, the increased update frequency of vanilla probably more than makes up for any security that hardened provides..

 

Ummm, I'd have to disagree completely.

----------

## richard.scott

Does anyone know where the kernels previous to hardened-sources-2.6.23 have gone?   :Shocked: 

```
# ls /usr/portage/sys-kernel/hardened-sources/ -l

total 68

-rw-r--r-- 1 root root 46897 Feb 27 16:07 ChangeLog

-rw-r--r-- 1 root root  2491 Feb 27 16:07 Manifest

-rw-r--r-- 1 root root   742 Dec 24 13:36 hardened-sources-2.4.35-r2.ebuild

-rw-r--r-- 1 root root   732 Feb 18 00:08 hardened-sources-2.6.23-r7.ebuild

-rw-r--r-- 1 root root   865 Feb 27 16:04 hardened-sources-2.6.23-r8.ebuild

-rw-r--r-- 1 root root   550 Feb 18 00:08 metadata.xml
```

The rest have been removed from portage!   :Crying or Very sad: 

----------

## schachti

I think they've been removed because it is too much work for the hardened team to maintain many different versions.

----------

## richard.scott

 *schachti wrote:*   

> I think they've been removed because it is too much work for the hardened team to maintain many different versions.

 

That's what I like about Gentoo.... giving the user a choice!   :Rolling Eyes: 

----------

## wyv3rn

 *richard.scott wrote:*   

> Does anyone know where the kernels previous to hardened-sources-2.6.23 have gone?  
> 
> The rest have been removed from portage!  

 

 *schachti wrote:*   

> I think they've been removed because it is too much work for the hardened team to maintain many different versions.

 

 *richard.scott wrote:*   

> That's what I like about Gentoo.... giving the user a choice!  

 

No, they were removed because they were vulnerable to vmsplice() root exploit.  2.6.23-r7 and 2.6.23-r8 also resolve other CVE, among tons of other bug fixes.

Edit: Actually I take that back.  If you had KERNEXEC and UDEREF turned on, you had some protection from the exploit.  It became a DoS instead of rooting your box.  This is a perfect example of why I do not agree that you are safer with vanilla-sources.

----------

## bbee

Well it's been another 10 days and I'm switching to vanilla. Grsec patches have been out for nearly a month; it can't possibly be that hard to cook a patchset. It's a shame really, this is the exact same reason I stopped using the other hardened features (like the gcc patches): lack of maintenance & support. I'd bake my own kernel like someone suggested, but I don't have the time to keep up to date on the latest kernel exploits.

I don't blame the hardened team if they are unable to do it, but IMHO if that's the case they should just drop hardened-sources altogether and not leave it lingering, that's much worse than just killing it off. That way the users would atleast know what they're in for. And while they're at it, might as well just drop the entire hardened subproject, since the kernel is the main deliverable..

Some outward communication could have helped a lot, but I don't want to redo the whole debate we had during that "gentoo is dying" scare.

If someone knows of a way to keep using grsec&friends (some trustworthy overlay that's kept up to date?), I'd love to hear about it.

----------

## Hu

How is it more time efficient to require that you upgrade every time a kernel exploit is disclosed than to require that you apply the GRsecurity patches by hand, and thereby enjoy some level of protection against some types of exploits?

As of this posting, none of the *-sources packages have marked a 2.6.24 kernel stable.  I agree it would be nice to have a 2.6.24 testing patch for sys-kernel/hardened-sources, but I think it is premature to accuse them of being unmaintained.  If there is no progress on sys-kernel/hardened-sources by the time =sys-kernel/gentoo-sources.2.6.25* goes stable, then such charges could carry some weight.

I disagree with regard to dropping the project.  Users can see kernel releases and monitor GRsecurity releases from its homepage, as you are clearly doing.  If they care about falling behind, they can switch to another source set or patch the source by hand as appropriate.  In the meantime, users who do not need the latest kernel features have the convenience of a Gentoo package maintaining the hardened sources.

As far as I know, sys-kernel/hardened-sources is sys-kernel/gentoo-sources + the hardened patchset.  Assuming no patch conflicts between the Gentoo patches and the GRsecurity patches, you could probably roll your own kernel in less time than it takes to argue the point of whether the project is unmaintained.

----------

## richard.scott

 *Hu wrote:*   

> ....you could probably roll your own kernel in less time than it takes to argue the point of whether the project is unmaintained.

 

Yes, it doesn't take long to patch and build a vanilla kernel to your requirements..... but why should I? You don't take your car to the mechanic and ask to borrow his tools to fix it? You want and need his experience on working on cars. Likewise, the whole point of installing via portage and ebuilds is that we are benefiting from a developers knowledge and experience on doing this task that we are all greatly thankful they are doing.

If its a case that the dev's are too busy in life to give time to the project then that's fair enough. If that is the case then perhaps Gentoo should be more proactive and advertise the fact they need more developers or maintainers! 

I'm sure there are loads of people (me included) who would like to help out where we can.

----------

## schachti

Did anyone succeed in applying the latest grsecurity patch to gentoo-sources-2.6.24-r3? I tried to do so, but got some rejects - so before I invest a lot of time tackling this problem, maybe someone has tried before?

----------

## kerframil

 *bbee wrote:*   

> I don't blame the hardened team if they are unable to do it, but IMHO if that's the case they should just drop hardened-sources altogether and not leave it lingering, that's much worse than just killing it off. That way the users would atleast know what they're in for. And while they're at it, might as well just drop the entire hardened subproject, since the kernel is the main deliverable.. 

 

I must say that I find this to be an immensely flippant remark. We are well aware that the kernel is an important deliverable. It could be reasonably argued that it has never received greater care over its most recent iterations. I would invite you to review the changes made in the patchset from 2.6.23-r7 through 2.6.23-r9 in detail if you are in any doubt as to that - changes that have been the product of hours of deliberation and debate. We foward ported the grsecurity patch in order to make it functional from 2.6.23.15 onwards, backported numerous fixes from later branches (closing numerous bugs in the process), and made various changes to make the process of succesfully employing this kernel far easier for new Hardened Gentoo users. This is hardly a process that could be described as leaving it "lingering".

Can you really point to a specific reason as to why not having the patchset presently based on 2.6.24 is undermining your security and why you'd be better off with vanilla? Of course, it doesn't and you wouldn't - you cite in you very first post that what you really want is "some of the new features". Well, that's understandable. New features are good. But do also try and understand that we're dealing with a demographic that is not necessarily obsessing over whether they've running atop the latest kernel.org release fresh off the block.

If having the "new features" is of the utmost importance to you above and beyond all else then I would question how greatly you value the security enhancements that the patchset brings in the first instance. 2.6 has plenty of bugs in general - every now and again someone shakes the tree hard enough as the recent vmsplice debacle so aptly demonstrated. There are 49MB worth of source-level changes between 2.6.23 and 2.6.24 which, while fixing existing bugs, will introduce new ones ... and so it goes on.

 *bbee wrote:*   

> Some outward communication could have helped a lot, but I don't want to redo the whole debate we had during that "gentoo is dying" scare.

 

It's probably fair to say that the movers and shakers in terms of the development process don't pay a great deal of attention to the forums. In any case, if you feel that the outward communication has been sub-standard then hopefully this post goes some way towards redressing the balance.

 *richard.scott wrote:*   

> If its a case that the dev's are too busy in life to give time to the project then that's fair enough. If that is the case then perhaps Gentoo should be more proactive and advertise the fact they need more developers or maintainers!

 

Anyone who has been hanging out on the IRC channel (which is, in general, the preferred mode of communication for most people involved in the project) or who is subscribed to the gentoo-hardened mailing list will be aware that there is a need for more staff. However, this mainly concerns the future direction of the toolchain. Having said that, I notice that there is no mention made of it on the official Staffing Needs page so it's a valid criticism.

As solar has said on a few occasions, "self motivated people" who get on with it are very welcome.

 *richard.scott wrote:*   

> Yes, it doesn't take long to patch and build a vanilla kernel to your requirements

 

On a personal basis perhaps. We're responsible for pushing out something that will be consumed by many users, often in mission critical environments. Also, the quality of the grsecurity patch itself is not always consistent, particularly when it's undergoing major changes. It's very hard to track and to make a judgement call as to when the time is right to introduce a new major release (and which snapshot to use in that event).

 *schachti wrote:*   

> Did anyone succeed in applying the latest grsecurity patch to gentoo-sources-2.6.24-r3? I tried to do so, but got some rejects - so before I invest a lot of time tackling this problem, maybe someone has tried before?

 

Of course. Unless anything serious crops up, 2.6.23-r9 is going to be the last release in that series. We have had a 2.6.24 trunk in the works since before 2.6.23-r8 was committed. I had hoped that it would be committed sooner (as per my comment on bug 210026) but things don't always bear out as planned.

Still, as it stands, we are very happy with the quality of the trunk and a release is feasible. The only thing that's holding it back now is that we are probably going to revamp the manner in which the GIDs for various options (GRKERNSEC_PROC_GID, GRKERNSEC_PROC_ADD, GRKERNSEC_EXECLOG ...) are defined. We'd really like to be able to enable some of these options by default in the "Gentoo [Hardened]" security level and to have standard groups that user can employ to control the behaviour of related options (for example, a "grsectpe" group for those users for whom trusted path execution should be enforced). Once that's out of the way, a release will be forthcoming. I'm not going to make promises in terms of timescales but I can say that we are looking to do that as soon as possible.

EDIT: corrected a typo

----------

## guero61

Just another long-timer seconding what kerframil says.  There has been more care and control put into the last several revisions of hardened-sources than most ricers care.  Yes, .24 has some nice features that are greatly anticipated, but the core audience for this kernel tree is not people who ooh and aah over the latest $foo - we are serious, often enterprise customers with a real desire for stability and control.

If new features are so important to you that you would actually consider switching to vanilla-sources after only a couple of months, I'm willing to venture that you made an arbitrary choice of a perceived security level in the form of the hardened profile and didn't actually evaluate your threat model and understand what you're defending against.  If so, you may be well-served by abandoning the profile anyway, as it's likely imposing unnecessary pain on you.

Maybe the problem is that even though ebuilds are trivial to write, most users don't realize that most gentoo devs put as much (or more) QA into packages as the original developers do, particularly for critical components like a kernel mostly destined for border and critical applications.  They don't simply bump the revision/patchset and throw it to the wolves, they actually have test plans, validate as many different configurations as they can, and generally put a lot of TLC into them.  You may consider that duplication of effort, but you'd be surprised how many problems they expose and mitigate.

How you can help: get on #gentoo-hardened and find out what needs tested; submit working reports and bumped ebuilds via bugzilla.  I can't tell you how many times I've posted a 'bump' ticket with a tested ebuild (or diff) and had it integrated within a few days.  The combination of bugzilla and the ability to maintain my own local overlay (in conjunction with sunrise/layman) add up to give the end-user incredibly precise control over what they're running.  With a little effort (much less than others), this distro is hardly one you have to wait for developer action to do what you want.

----------

## kerframil

I've opened a bug detailing a proposed 2.6.24 release.

----------

