[Ksummit-2013-discuss] Topic Proposal: Handling Security Issues in the kernel

[Kees Cook]

On Tue, Aug 13, 2013 at 12:01 AM, Greg KH <greg at kroah.com> wrote:
> On Tue, Aug 13, 2013 at 08:47:51AM +0200, Steffen Klassert wrote:
>> On Sat, Aug 10, 2013 at 07:27:36PM +1000, James Morris wrote:
>> > On Fri, 9 Aug 2013, Greg KH wrote:
>> >
>> > > The number of bugs reported to security@ is very low, only a few a month
>> > > turn out to be anything "real", and even then, most of them are quite
>> > > limited in scope.  So perhaps people are thinking there is more going on
>> > > than really is, so some more transparancy would help out here after the
>> > > fact?
>> >
>> > Probably yes, although I think we need to examine the need to keep
>> > security information out of upstream commits.  The bad guys, particularly
>> > well-funded ones, actually get an advantage when we do this, because
>> > they'll figure out pretty quickly what the problem is, while the general
>> > public is left in the dark for a time.
>> >
>> > I think we need input on this from both the industry and from security
>> > researchers.
>> >
>>
>> >From the point of view of someone who maintains vendor kernels where
>> security is by far the most important issue, i'd wish some channel
>> to get informed as soon as:
>>
>> a) A new security problem is reported, so that I can at least disable
>> the related feature temporarily if needed/possible. Not sure if this
>> should be done on a public list or on a channel where people have to
>> confirm their needs to get informed.
>
> Note that publically disabling features can be a signal to others that
> there is a problem, and then that problem can be found "easier".

I understood this to be about the time period between public
disclosure and having a fix. Some times there is a long delay between
the upstream fixes and when a distro/vendor can get a kernel rolled
out with that fix. In that time frame, doing feature disabling is a
nice way for vendors and end-users to work-around problems until the
fix is available.

> Anyway, linux-distros@ is the list for this.

Yes. Please see http://oss-security.openwall.org/wiki/mailing-lists/distros

>> b) A reported security problem is fixed with the related commit ID.
>> Currently we are watching the cve lists to track this, but a linux
>> kernel specific list would be much easier to track.
>
> linux-distros@ is the list for this.

Well, for public issues, oss-security@ is the right list.
linux-distros@ is really only used for high priority
embargo-coordinated issues.

What's missing is an upstream accounting of commit ID that introduces
a problem along with commit IDs that fix it. This can be cobbled
together by the Mitre reports, but usually requires knowledge of the
kernel area itself and some historical perspective. As yet, no one has
stepped up to do this for the upstream kernels. (Distros do this on
their own, generally.)

-Kees

-- 
Kees Cook
Chrome OS Security