1 |
Alright how do we proceed to get this team started. |
2 |
|
3 |
ed*eonsec |
4 |
|
5 |
On Thu, Feb 21, 2008 at 6:55 AM, Ned Ludd <solar@g.o> wrote: |
6 |
> |
7 |
> |
8 |
> On Wed, 2008-02-20 at 13:59 -0500, Harlan Lieberman-Berg wrote: |
9 |
> > On Sunday 17 February 2008 23:12:35 Robert Buchholz wrote: |
10 |
> > > On Sunday, 17. February 2008, Eduardo Tongson wrote: |
11 |
> > > > What specific kernel knowledge is needed to get a Kernel advisory up |
12 |
> > > > and running ? |
13 |
> > > |
14 |
> > > Between becoming aware of a vulnerability in Linux and drafting an advisory |
15 |
> > > for one or all kernel sources comes the part where you review which |
16 |
> > > versions of which kernel sources are affected and unaffected. You also |
17 |
> > > need to pay attention to specifics of the added patchsets, which might |
18 |
> > > duplicate vulnerabilities. |
19 |
> > > |
20 |
> > > Parts of the job can indeed be done without Kernel and C knowledge, but |
21 |
> > > some cannot. So if we draft a new kernel security *team*, people without C |
22 |
> > > and kernel knowledge are helpful -- some others need to have it, though. |
23 |
> > > |
24 |
> > > Robert |
25 |
> > |
26 |
> > To be honest, 99% of what is done in the kernel security team can be done with |
27 |
> > no C knowledge at all. |
28 |
> > |
29 |
> > I'm not an expert C person - far from it - but I eventually became the head of |
30 |
> > Kernel Security until I retired a few months ago. |
31 |
> > |
32 |
> > Most of it is bug handling. The major problem is a social, not a technical |
33 |
> > one. Because of the manner in which our kernels are organized, a single |
34 |
> > vulnerability involves checking upstream version numbers, coordinating them |
35 |
> > into our downstream version numbers for all sources, checking to see if the |
36 |
> > sources are effected, figuring out who to CC for the bugs, then harassing |
37 |
> > them until they do it. |
38 |
> > |
39 |
> > Unlike other security sources, any attempt to hardmask the package is shutdown |
40 |
> > instantly. The chaos that would result from a kernel hardmask, even one of |
41 |
> > the lesser used ones, caused me to only successfully order one over my entire |
42 |
> > career in Gentoo Kernsec... even though more around 30 would have been |
43 |
> > needed. It is not infrequently that bugs will last six months without any |
44 |
> > action coming about them, and users are blissfully unaware. |
45 |
> > |
46 |
> > I am happy to give my input as the former head of Kernel Security, but it is |
47 |
> > my personal opinion that any advances in kernel security will require the |
48 |
> > full cooperation of security, and letting the head of kernel security be able |
49 |
> > to actually enforce threats, as that seems to be the only way bugs ever get |
50 |
> > resolved. Pleading didn't work - I tried. |
51 |
> > |
52 |
> > -Harlan Lieberman-Berg |
53 |
> > Gentoo Developer Emeritus |
54 |
> |
55 |
> |
56 |
> Every word of what you said is painfully true. The only way to |
57 |
> accomplish this would be with an Iron Fist(fail) or a team of ~15 guys |
58 |
> who do nothing but patch and push new kernels and the PR that goes along |
59 |
> with them every few days. |
60 |
> -- |
61 |
> Ned Ludd <solar@g.o> |
62 |
> |
63 |
> |
64 |
> |
65 |
> -- |
66 |
> gentoo-security@l.g.o mailing list |
67 |
> |
68 |
> |
69 |
-- |
70 |
gentoo-security@l.g.o mailing list |