============================
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.
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
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.
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.
|
