Gentoo Archives: gentoo-kernel

From: Tim Yamin <plasmaroo@g.o>
To: gentoo-kernel@l.g.o
Subject: Re: [gentoo-kernel] Gentoo Kernel Security Policy (DRAFT)
Date: Wed, 15 Mar 2006 23:43:01
In Reply to: [gentoo-kernel] Gentoo Kernel Security Policy (DRAFT) by John Mylchreest
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 > situation. > > 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 scores correctly?
> 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 > displayed. > > 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 by KISS.
> 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.
Kernels :)
> 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. Great otherwise, Thanks, Tim -- gentoo-kernel@g.o mailing list