1 |
On 19/04/10 20:31, Michael Orlitzky wrote: |
2 |
> On 04/19/10 13:16, Ed W wrote: |
3 |
>> I guess others will disagree, but I have never been a huge fan of the |
4 |
>> kernel ebuilds. I'm just not clear what they buy you over downloading |
5 |
>> and compiling your own? I think there are a few extra patches in the |
6 |
>> case of gentoo-sources, but that seems to be about it? |
7 |
>> |
8 |
>> |
9 |
>> If you don't yet have an alternative in place then my choice is for the |
10 |
>> vserver+grsec patches that you can grab from the linux-vserver.org site |
11 |
>> and this gives you a very easy way to setup chroot style jails with |
12 |
>> lightweight virtualisation, plus all the grsec patches. If you just want |
13 |
>> Pax then it's a fast moving target and you are best to grab and patch |
14 |
>> your own kernel anyway, and don't forget to keep an archive of pax |
15 |
>> patches used since they don't archive them on the site (annoying if you |
16 |
>> are trying to diff the diff or whatever) |
17 |
>> |
18 |
>> |
19 |
>> I realise everyone has different needs, but perhaps try pulling your own |
20 |
>> kernel down and applying your own patches - I think it's about easier to |
21 |
>> maintain in most cases? |
22 |
> |
23 |
> * The ebuilds for e.g. hardened-sources do all the patching for you, |
24 |
> which is nice. |
25 |
> |
26 |
> * The fact that the kernel shows up in emerge output reminds me to |
27 |
> compile a new one. |
28 |
> |
29 |
> * If a kernel is marked stable in Portage, it means that test dummies |
30 |
> have been running it for a while and they survived. It also means |
31 |
> no bugs were reported regarding integration with other in-tree |
32 |
> packages. |
33 |
> |
34 |
> * Other packages in portage can require certain (versions of) kernels. |
35 |
> If you compile your own, Portage doesn't know about it. Easy enough |
36 |
> to fix via package.provided, but still a mild headache, especially if |
37 |
> we're talking about a large number of machines. |
38 |
> |
39 |
> That's all I got. |
40 |
|
41 |
Yes, you are right. But still ... it's now closer to one year *without* |
42 |
any updates for the stable kernel. Which means, compiling the latest |
43 |
upstream 2.6.33.2 kernel might be a lot safer, than the 2.6.28-r9 which |
44 |
is marked stable now. |
45 |
|
46 |
As a comparison, Red Hat comes regularly with security fixes to their |
47 |
kernels, some RHEL based kernels almost have an update with security |
48 |
fixes every month. Of course you can blame it on the amount of |
49 |
resources and equipment available for testing. On the other hand RHEL |
50 |
do backport patches from newer kernels to older kernels (to maintain |
51 |
certifications) with (mostly) security fixes. That do take a lot of |
52 |
manpower to manage. Anyhow, being able to release a new kernel for a |
53 |
"stable marked" as RHEL aims at, containing security fixes, tells |
54 |
something about the amount of vulnerabilities found in the kernel. |
55 |
|
56 |
But, the hardened-sources really touches the nerve now in regards to |
57 |
what I feel is safe. The PaX patches do provide some extra security |
58 |
which not many else have. But still ... I am not as confident with |
59 |
Hardened Gentoo as I once was. I honestly think that the hardened |
60 |
sources now are more vulnerable than gentoo-sources, just because of the |
61 |
age of the kernel. Granted, gentoo-sources do not have the PaX patch |
62 |
set, but it is still fresher with more CVE and other security fixes than |
63 |
what the current stable hardened-sources do have. |
64 |
|
65 |
Fair enough, the Gentoo portage kernels do add some fixes which is not |
66 |
in upstream yet ... but that's only valid when the kernel is not as old |
67 |
as this one. |
68 |
|
69 |
I have no problem accepting if the Hardened team withdraws the current |
70 |
hardened-sources. It will most probably create a lot more noise for |
71 |
some time. But the current situation is unsustainable, in my honest |
72 |
opinion. In fact, it would be a more honest approach if the Hardened |
73 |
team withdraw the sources - giving advises to which stable kernel to run |
74 |
instead or which approach to take to get a better solution. |
75 |
|
76 |
The only reason I do not switch kernel yet (or distro), is that I still |
77 |
have a hope that a newer kernel is just around the corner. But my hope |
78 |
is fading... and lately faster than earlier. |
79 |
|
80 |
|
81 |
kind regards, |
82 |
|
83 |
David Sommerseth |