1 |
AFAICS the thing missing is a leader. Someone to make a starting point |
2 |
for the followers to make use of (not necessary inside of gentoo, I |
3 |
believe it can always be integrated later if there are devs enough to |
4 |
pick things up and integrate), a place for him to collect and keep list |
5 |
and contact with interested people (also to keep "me too"-noise from |
6 |
this list). |
7 |
|
8 |
This does not even have to be a integrated gentoo solution, am I right? |
9 |
Anybody having a hosting space could host a db with the |
10 |
information/advisories. |
11 |
And the hosting one could let anyone he/she trusts write info to that |
12 |
db. |
13 |
That db could be like "This vournable exists, these are the problems, |
14 |
these are the workarounds/patches and there are no fixed kernel |
15 |
versions/these kernel versions are fixed" where info could be updated as |
16 |
they get along. |
17 |
And anybody that has the time and skill could write a applications that |
18 |
fetch info from this db about the currently running kernel and presents |
19 |
the user with the text "No known vournables" or "These vournables |
20 |
exists" with links to the information in the db about that advisory. |
21 |
This way a user can run the application, get a message, read the |
22 |
advisories and decide "I need to update to at least this version" or "I |
23 |
do not need to update". |
24 |
|
25 |
The thing needed after that is persons to keep this db up to date and |
26 |
maybe bug devs to get fixed versions into portage. |
27 |
But these people needs a central collection point where they could |
28 |
"meet" and start moving things. |
29 |
|
30 |
And anybody can bug any dev in bugzilla if a kernel is not fixed, but |
31 |
the chances over-worked devs will notice and be more helpful if you are |
32 |
more helpful with what, when and why this kernel thing should be fixed |
33 |
(i.e. come well prepared). |
34 |
|
35 |
|
36 |
tor 2008-02-21 klockan 11:16 +0800 skrev Eduardo Tongson: |
37 |
> Alright how do we proceed to get this team started. |
38 |
> |
39 |
> ed*eonsec |
40 |
> |
41 |
> On Thu, Feb 21, 2008 at 6:55 AM, Ned Ludd <solar@g.o> wrote: |
42 |
> > |
43 |
> > |
44 |
> > On Wed, 2008-02-20 at 13:59 -0500, Harlan Lieberman-Berg wrote: |
45 |
> > > On Sunday 17 February 2008 23:12:35 Robert Buchholz wrote: |
46 |
> > > > On Sunday, 17. February 2008, Eduardo Tongson wrote: |
47 |
> > > > > What specific kernel knowledge is needed to get a Kernel advisory up |
48 |
> > > > > and running ? |
49 |
> > > > |
50 |
> > > > Between becoming aware of a vulnerability in Linux and drafting an advisory |
51 |
> > > > for one or all kernel sources comes the part where you review which |
52 |
> > > > versions of which kernel sources are affected and unaffected. You also |
53 |
> > > > need to pay attention to specifics of the added patchsets, which might |
54 |
> > > > duplicate vulnerabilities. |
55 |
> > > > |
56 |
> > > > Parts of the job can indeed be done without Kernel and C knowledge, but |
57 |
> > > > some cannot. So if we draft a new kernel security *team*, people without C |
58 |
> > > > and kernel knowledge are helpful -- some others need to have it, though. |
59 |
> > > > |
60 |
> > > > Robert |
61 |
> > > |
62 |
> > > To be honest, 99% of what is done in the kernel security team can be done with |
63 |
> > > no C knowledge at all. |
64 |
> > > |
65 |
> > > I'm not an expert C person - far from it - but I eventually became the head of |
66 |
> > > Kernel Security until I retired a few months ago. |
67 |
> > > |
68 |
> > > Most of it is bug handling. The major problem is a social, not a technical |
69 |
> > > one. Because of the manner in which our kernels are organized, a single |
70 |
> > > vulnerability involves checking upstream version numbers, coordinating them |
71 |
> > > into our downstream version numbers for all sources, checking to see if the |
72 |
> > > sources are effected, figuring out who to CC for the bugs, then harassing |
73 |
> > > them until they do it. |
74 |
> > > |
75 |
> > > Unlike other security sources, any attempt to hardmask the package is shutdown |
76 |
> > > instantly. The chaos that would result from a kernel hardmask, even one of |
77 |
> > > the lesser used ones, caused me to only successfully order one over my entire |
78 |
> > > career in Gentoo Kernsec... even though more around 30 would have been |
79 |
> > > needed. It is not infrequently that bugs will last six months without any |
80 |
> > > action coming about them, and users are blissfully unaware. |
81 |
> > > |
82 |
> > > I am happy to give my input as the former head of Kernel Security, but it is |
83 |
> > > my personal opinion that any advances in kernel security will require the |
84 |
> > > full cooperation of security, and letting the head of kernel security be able |
85 |
> > > to actually enforce threats, as that seems to be the only way bugs ever get |
86 |
> > > resolved. Pleading didn't work - I tried. |
87 |
> > > |
88 |
> > > -Harlan Lieberman-Berg |
89 |
> > > Gentoo Developer Emeritus |
90 |
> > |
91 |
> > |
92 |
> > Every word of what you said is painfully true. The only way to |
93 |
> > accomplish this would be with an Iron Fist(fail) or a team of ~15 guys |
94 |
> > who do nothing but patch and push new kernels and the PR that goes along |
95 |
> > with them every few days. |
96 |
> > -- |
97 |
> > Ned Ludd <solar@g.o> |
98 |
> > |
99 |
> > |
100 |
> > |
101 |
> > -- |
102 |
> > gentoo-security@l.g.o mailing list |
103 |
> > |
104 |
> > |