[gentoo-kernel] Gentoo Kernel Security Policy (DRAFT)

[gentoo-kernel] Gentoo Kernel Security Policy (DRAFT)

[John Mylchreest]

[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]

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.

Cheers,
John

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


[-- Attachment #1.2: kernel-security-policy.txt --]
[-- Type: text/plain, Size: 3897 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-kernel] Gentoo Kernel Security Policy (DRAFT)

[Tim Yamin]

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@gentoo.org mailing list

Re: [gentoo-kernel] Gentoo Kernel Security Policy (DRAFT)

[Greg KH]

On Wed, Mar 15, 2006 at 11:31:01PM +0000, John Mylchreest wrote:
> 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.

Wow, we are commiting to support 2 kernel versions back?  Since when?
That's going to be a major effort that no one has signed up to do (even
kernel.org doesn't offer that...)  Do we _really_ want to say we are
going to do this?

If so, we're already behind with all of the recent 2.6.15 security fixes
not being backported to 2.6.14 :)

thanks,

greg k-h
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] Gentoo Kernel Security Policy (DRAFT)

[Tim Yamin]

On Wed, Mar 15, 2006 at 04:43:18PM -0800, Greg KH wrote:
> On Wed, Mar 15, 2006 at 11:31:01PM +0000, John Mylchreest wrote:
> > 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.
> 
> Wow, we are commiting to support 2 kernel versions back?  Since when?
> That's going to be a major effort that no one has signed up to do (even
> kernel.org doesn't offer that...)  Do we _really_ want to say we are
> going to do this?
> 
> If so, we're already behind with all of the recent 2.6.15 security fixes
> not being backported to 2.6.14 :)

Only they are being backported... kerframil is helping out with that task.
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] Gentoo Kernel Security Policy (DRAFT)

[Greg KH]

On Thu, Mar 16, 2006 at 02:59:56AM +0000, Tim Yamin wrote:
> On Wed, Mar 15, 2006 at 04:43:18PM -0800, Greg KH wrote:
> > On Wed, Mar 15, 2006 at 11:31:01PM +0000, John Mylchreest wrote:
> > > 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.
> > 
> > Wow, we are commiting to support 2 kernel versions back?  Since when?
> > That's going to be a major effort that no one has signed up to do (even
> > kernel.org doesn't offer that...)  Do we _really_ want to say we are
> > going to do this?
> > 
> > If so, we're already behind with all of the recent 2.6.15 security fixes
> > not being backported to 2.6.14 :)
> 
> Only they are being backported... kerframil is helping out with that task.

Ah, didn't realize that.  Ok, then I have no objections.

thanks,

greg k-h
-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] Gentoo Kernel Security Policy (DRAFT)

[John Mylchreest]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

OK so it obviously DID send and I just never recieved it! lol
Sorry, please ignore my most recent email.

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

> > > Wow, we are commiting to support 2 kernel versions back?  Since when?
> > > That's going to be a major effort that no one has signed up to do (even
> > > kernel.org doesn't offer that...)  Do we _really_ want to say we are
> > > going to do this?
> > > 
> > > If so, we're already behind with all of the recent 2.6.15 security fixes
> > > not being backported to 2.6.14 :)
> > 
> > Only they are being backported... kerframil is helping out with that task.
> 
> Ah, didn't realize that.  Ok, then I have no objections.
> 
> thanks,
> 
> greg k-h

Just to stress, its only the genpatches-based sources which are being
supported to this degree, and its mainly stable-tree backports - so
thankfully a very small footprint. :)

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


[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]