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