From: David Sommerseth <gentoo.list@topphemmelig.net>
To: gentoo-hardened@lists.gentoo.org
Cc: Michael Orlitzky <michael@orlitzky.com>
Subject: Re: [gentoo-hardened] kernel no longer in hardened-development overlay?
Date: Mon, 19 Apr 2010 21:45:24 +0200 [thread overview]
Message-ID: <4BCCB2D4.5040503@topphemmelig.net> (raw)
In-Reply-To: <4BCCA18C.60600@orlitzky.com>
On 19/04/10 20:31, Michael Orlitzky wrote:
> On 04/19/10 13:16, Ed W wrote:
>> I guess others will disagree, but I have never been a huge fan of the
>> kernel ebuilds. I'm just not clear what they buy you over downloading
>> and compiling your own? I think there are a few extra patches in the
>> case of gentoo-sources, but that seems to be about it?
>>
>>
>> If you don't yet have an alternative in place then my choice is for the
>> vserver+grsec patches that you can grab from the linux-vserver.org site
>> and this gives you a very easy way to setup chroot style jails with
>> lightweight virtualisation, plus all the grsec patches. If you just want
>> Pax then it's a fast moving target and you are best to grab and patch
>> your own kernel anyway, and don't forget to keep an archive of pax
>> patches used since they don't archive them on the site (annoying if you
>> are trying to diff the diff or whatever)
>>
>>
>> I realise everyone has different needs, but perhaps try pulling your own
>> kernel down and applying your own patches - I think it's about easier to
>> maintain in most cases?
>
> * The ebuilds for e.g. hardened-sources do all the patching for you,
> which is nice.
>
> * The fact that the kernel shows up in emerge output reminds me to
> compile a new one.
>
> * If a kernel is marked stable in Portage, it means that test dummies
> have been running it for a while and they survived. It also means
> no bugs were reported regarding integration with other in-tree
> packages.
>
> * Other packages in portage can require certain (versions of) kernels.
> If you compile your own, Portage doesn't know about it. Easy enough
> to fix via package.provided, but still a mild headache, especially if
> we're talking about a large number of machines.
>
> That's all I got.
Yes, you are right. But still ... it's now closer to one year *without*
any updates for the stable kernel. Which means, compiling the latest
upstream 2.6.33.2 kernel might be a lot safer, than the 2.6.28-r9 which
is marked stable now.
As a comparison, Red Hat comes regularly with security fixes to their
kernels, some RHEL based kernels almost have an update with security
fixes every month. Of course you can blame it on the amount of
resources and equipment available for testing. On the other hand RHEL
do backport patches from newer kernels to older kernels (to maintain
certifications) with (mostly) security fixes. That do take a lot of
manpower to manage. Anyhow, being able to release a new kernel for a
"stable marked" as RHEL aims at, containing security fixes, tells
something about the amount of vulnerabilities found in the kernel.
But, the hardened-sources really touches the nerve now in regards to
what I feel is safe. The PaX patches do provide some extra security
which not many else have. But still ... I am not as confident with
Hardened Gentoo as I once was. I honestly think that the hardened
sources now are more vulnerable than gentoo-sources, just because of the
age of the kernel. Granted, gentoo-sources do not have the PaX patch
set, but it is still fresher with more CVE and other security fixes than
what the current stable hardened-sources do have.
Fair enough, the Gentoo portage kernels do add some fixes which is not
in upstream yet ... but that's only valid when the kernel is not as old
as this one.
I have no problem accepting if the Hardened team withdraws the current
hardened-sources. It will most probably create a lot more noise for
some time. But the current situation is unsustainable, in my honest
opinion. In fact, it would be a more honest approach if the Hardened
team withdraw the sources - giving advises to which stable kernel to run
instead or which approach to take to get a better solution.
The only reason I do not switch kernel yet (or distro), is that I still
have a hope that a newer kernel is just around the corner. But my hope
is fading... and lately faster than earlier.
kind regards,
David Sommerseth
next prev parent reply other threads:[~2010-04-19 19:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 16:53 [gentoo-hardened] kernel no longer in hardened-development overlay? Joseph C. Lininger
2010-04-19 17:16 ` Ed W
2010-04-19 18:31 ` Michael Orlitzky
2010-04-19 19:37 ` Mike Edenfield
2010-04-19 23:02 ` Ed W
2010-04-19 19:45 ` David Sommerseth [this message]
2010-04-19 22:27 ` [gentoo-hardened] " Kerin Millar
2010-04-19 23:15 ` [gentoo-hardened] " Ed W
2010-04-20 5:14 ` Kai Dietrich
2010-04-20 11:57 ` Darknight
2010-04-20 13:34 ` Ed W
2010-04-20 13:46 ` Pavel Labushev
2010-04-19 17:46 ` [gentoo-hardened] " Kerin Millar
2010-04-19 20:12 ` Guillaume Castagnino
2010-04-19 22:56 ` Ed W
2010-04-19 23:05 ` [gentoo-hardened] " Mansour Moufid
2010-04-19 23:24 ` Ed W
2010-04-19 23:43 ` Mansour Moufid
2010-04-20 12:36 ` [gentoo-hardened] " Kerin Millar
2010-04-20 15:36 ` David Sommerseth
2010-04-19 23:35 ` [gentoo-hardened] " klondike
2010-04-20 0:00 ` Anthony G Basile
2010-04-20 5:08 ` Tóth Attila
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BCCB2D4.5040503@topphemmelig.net \
--to=gentoo.list@topphemmelig.net \
--cc=gentoo-hardened@lists.gentoo.org \
--cc=michael@orlitzky.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox