1 |
On Wed, Mar 15, 2006 at 11:31:01PM +0000, John Mylchreest wrote: |
2 |
> ============================ |
3 |
> Kernel Security Policy |
4 |
> ============================ |
5 |
> |
6 |
> As the QA and Security awareness within Gentoo continues to grow, so must the |
7 |
> contraints placed around distributed kernels to support it. As part of our |
8 |
> progression to accompany these efforts I would like to draw your attention to |
9 |
> the following policy. |
10 |
> |
11 |
> At the moment, this is heavily draft, and your opinions are most welcome. Rip |
12 |
> this apart and lets see what we can come up with :) |
13 |
|
14 |
:) |
15 |
|
16 |
> 1. Security Tagging |
17 |
> |
18 |
> Security tagging is an important part of marking sources as to their |
19 |
> expected response time to security vulnerabilities and to their current |
20 |
> situation. |
21 |
> |
22 |
> Certain situations cause a weight to be added to the security tag of a |
23 |
> given ebuild. A lot of this can be handled in the eclass, such as |
24 |
> non-standard kernel versioning, not using K_WANT_GENPATCHES, |
25 |
> genpatches version is outdated (with a 2 sectag pentalty for each |
26 |
> version it falls behind this can be tracked through the eclass but |
27 |
> of a high expense and might prove unfeasible), use of UNIPATCH_EXCLUDE. |
28 |
> Also, a modifier can be set within the kernel ebuild to alter this, |
29 |
> K_SECTAG. K_SECTAG is a signed int value. |
30 |
|
31 |
How does the eclass know the latest genpatches so it can beancount the penalty |
32 |
scores correctly? |
33 |
|
34 |
> 2. Naming Scheme |
35 |
|
36 |
Naming -> Versioning |
37 |
|
38 |
> To help keep a consistant scheme which we can easily track using KISS |
39 |
> we also need to have a consitant version scheme for our sources. In |
40 |
> almost every instance, this exists. However kernel sources which are |
41 |
> untrackable through regular means (such as openvz-sources, |
42 |
> vserver-sources) cause problems when tracing vulnerable sources in an |
43 |
> automated way. This is immediate cause for a security warning to be |
44 |
> displayed. |
45 |
> |
46 |
> 3. Genpatches-Base Support |
47 |
> |
48 |
> For as long as there is a kernel package in the tree using genpatches, |
49 |
> the corresponding genpatches-base will be maintained from a security |
50 |
> point of view. Announcements for each update follow the normal |
51 |
> procedure, however there is a caveat. Kernel sources which use |
52 |
> genpatches should not lapse more than 2 minor releases from upstream. |
53 |
> IE: kernel sources should not fall behind 2.6.14 if the most recent |
54 |
> upstream release is 2.6.16. In the extreme case where this is not |
55 |
> technically possible, this will require it being addressed on a |
56 |
> case-by-case basis, and a sectag penalty of 10 applied if appropriate. |
57 |
> |
58 |
> 4. Vanilla-sources |
59 |
> |
60 |
> This is a bit of a unique scenario. Vanilla-sources will fall directly |
61 |
> under the management of upstream, and KISS. Since we add no additional |
62 |
> patches to vanilla-sources and we keep it actively maintained pushing |
63 |
> security fixes to stable it is almost exempt to the above. |
64 |
|
65 |
Just upstream, we don't track vanilla-sources in KISS... but we could? Should |
66 |
we? The same applies for mm-sources and any other fast-paced /experimental/ |
67 |
trees should they be produced by upstream. Those trees won't even be tracked |
68 |
by KISS. |
69 |
|
70 |
> 5. 2.4 based sources. |
71 |
> |
72 |
> Since we dont distribute genpatches for 2.4, but we do manage it |
73 |
> through KISS, the only difference for 2.4 based kernels is that the |
74 |
> security tag which get automagically modified is exempt to the |
75 |
> genpatches test. |
76 |
> |
77 |
> 6. New kernel packages |
78 |
> |
79 |
> Kernela which are not maintained by an active member of the kernel |
80 |
> herd, or by the kernel herd as a whole are not exempt from this policy. |
81 |
> Every new addition should adhere to this policy. |
82 |
|
83 |
Kernels :) |
84 |
|
85 |
> 7. Three Strike Removal |
86 |
> |
87 |
> Kernel packages which fall behind on security vulnerabilities without |
88 |
> valid reasoning, and are not maintained by the herd will be masked. If |
89 |
> a package gets masked, then unmasked repeatedly because of known |
90 |
> vulnerabilities then it will get hardmasked with expectation of it |
91 |
> being removed, or properly looked after. This will need to be dealt |
92 |
> with by discussion on gentoo-kernel & gentoo-security, or if |
93 |
> appropriate by dev-rel. |
94 |
|
95 |
I think devrel is a bit overreactive here... QA team. |
96 |
|
97 |
Great otherwise, |
98 |
|
99 |
Thanks, |
100 |
|
101 |
Tim |
102 |
-- |
103 |
gentoo-kernel@g.o mailing list |