Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-kernel
Lists: gentoo-kernel: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-kernel@g.o
From: John Mylchreest <johnm@g.o>
Subject: Gentoo Kernel Security Policy (DRAFT)
Date: Wed, 15 Mar 2006 23:31:01 +0000
Hey guys,

Please take a read through this and feed back any comments. This is
starting to become more important as we are growing with relation to
Gentoo's attention to QA and in particular our security practices.

I'd like to think that we run all over the "secure" distros with a lot
ot his stuff, and we all do it anyways - generally speaking. But at
least by having an official doc (that will be published) we have
something to fall back on when the time comes to kick ass.

At the moment there is nothing discussing kernel-modules. Thats going to
be something different I suspect.

As mentioned, this is very much draft, plus - it's late and I've likely
made a lot of mistakes during my distractions. Comments, ideas, changes,
deletions, etc etc all on list please.


Role:            Gentoo Linux Kernel Lead
Gentoo Linux:
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515

   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.

	If the ebuild sectag score is above or equal to 10, it generates a 
	warning in pkg_setup explaining that this kernel source fails with
	<report of score breakdown> and that alternatives should be considered
	if security is an important issue for the user. However the security 
	score should be evaluated and displayed in pkg_setup regardless.

2.	Naming Scheme

	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.

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.
pgpjyccAOLoaQ.pgp (PGP signature)
Re: Gentoo Kernel Security Policy (DRAFT)
-- Greg KH
Re: Gentoo Kernel Security Policy (DRAFT)
-- Tim Yamin
Lists: gentoo-kernel: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
[ANNOUNCE] genpatches-2.6.14-11 release
Next by thread:
Re: Gentoo Kernel Security Policy (DRAFT)
Previous by date:
[ANNOUNCE] genpatches-2.6.14-11 release
Next by date:
Re: Gentoo Kernel Security Policy (DRAFT)

Updated Jun 17, 2009

Summary: Archive of the gentoo-kernel mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.