On Wed, Mar 15, 2006 at 11:31:01PM +0000, John Mylchreest wrote:
> Kernel Security Policy
> As the QA and Security awareness within Gentoo continues to grow, so must the
> contraints placed around distributed kernels to support it. As part of our
> progression to accompany these efforts I would like to draw your attention to
> the following policy.
> At the moment, this is heavily draft, and your opinions are most welcome. Rip
> this apart and lets see what we can come up with :)
> 1. Security Tagging
> Security tagging is an important part of marking sources as to their
> expected response time to security vulnerabilities and to their current
> Certain situations cause a weight to be added to the security tag of a
> given ebuild. A lot of this can be handled in the eclass, such as
> non-standard kernel versioning, not using K_WANT_GENPATCHES,
> genpatches version is outdated (with a 2 sectag pentalty for each
> version it falls behind this can be tracked through the eclass but
> of a high expense and might prove unfeasible), use of UNIPATCH_EXCLUDE.
> Also, a modifier can be set within the kernel ebuild to alter this,
> K_SECTAG. K_SECTAG is a signed int value.
How does the eclass know the latest genpatches so it can beancount the penalty
> 2. Naming Scheme
Naming -> Versioning
> To help keep a consistant scheme which we can easily track using KISS
> we also need to have a consitant version scheme for our sources. In
> almost every instance, this exists. However kernel sources which are
> untrackable through regular means (such as openvz-sources,
> vserver-sources) cause problems when tracing vulnerable sources in an
> automated way. This is immediate cause for a security warning to be
> 3. Genpatches-Base Support
> For as long as there is a kernel package in the tree using genpatches,
> the corresponding genpatches-base will be maintained from a security
> point of view. Announcements for each update follow the normal
> procedure, however there is a caveat. Kernel sources which use
> genpatches should not lapse more than 2 minor releases from upstream.
> IE: kernel sources should not fall behind 2.6.14 if the most recent
> upstream release is 2.6.16. In the extreme case where this is not
> technically possible, this will require it being addressed on a
> case-by-case basis, and a sectag penalty of 10 applied if appropriate.
> 4. Vanilla-sources
> This is a bit of a unique scenario. Vanilla-sources will fall directly
> under the management of upstream, and KISS. Since we add no additional
> patches to vanilla-sources and we keep it actively maintained pushing
> security fixes to stable it is almost exempt to the above.
Just upstream, we don't track vanilla-sources in KISS... but we could? Should
we? The same applies for mm-sources and any other fast-paced /experimental/
trees should they be produced by upstream. Those trees won't even be tracked
> 5. 2.4 based sources.
> Since we dont distribute genpatches for 2.4, but we do manage it
> through KISS, the only difference for 2.4 based kernels is that the
> security tag which get automagically modified is exempt to the
> genpatches test.
> 6. New kernel packages
> Kernela which are not maintained by an active member of the kernel
> herd, or by the kernel herd as a whole are not exempt from this policy.
> Every new addition should adhere to this policy.
> 7. Three Strike Removal
> Kernel packages which fall behind on security vulnerabilities without
> valid reasoning, and are not maintained by the herd will be masked. If
> a package gets masked, then unmasked repeatedly because of known
> vulnerabilities then it will get hardmasked with expectation of it
> being removed, or properly looked after. This will need to be dealt
> with by discussion on gentoo-kernel & gentoo-security, or if
> appropriate by dev-rel.
I think devrel is a bit overreactive here... QA team.
email@example.com mailing list