linux-kernel - Re: [ANNOUNCE] linux-stable security tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Apr 2016 14:58:37 -0400
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	stable <stable@...r.kernel.org>, lwn@....net
Subject: Re: [ANNOUNCE] linux-stable security tree

On 04/11/2016 02:41 PM, Greg KH wrote:
> On Mon, Apr 11, 2016 at 01:53:41PM -0400, Sasha Levin wrote:
>> Hi all,
>>
>>
>> I'd like to announce the linux-stable security tree project. The purpose
>> is to create a derivative tree from the regular stable tree that would
>> contain only commits that fix security vulnerabilities.
> 
> And how are you going to define "security vulnerabilities"?

In general, anything that qualified for a CVE plus anything exploitable
by a local unprivileged user.

> Also, what kernel branches are you going to do this for, and for how
> long?

All active -stable kernels, for as long as those corresponding kernels
are supported. This isn't a brand new tree, but is a subset of it's
corresponding -stable tree.

>> Quite a few users of the stable trees pointed out that on complex deployments,
>> where validation is non-trivial, there is little incentive to follow the
>> stable tree after the product has been deployed to production. There is no
>> interest in "random" kernel fixes and the only requirements are to keep up
>> with security vulnerabilities.
> 
> "random" is in the eye of the beholder :)

It's not "random" for us building the tree, but it's very much "random"
for the users for see fixes for drivers they've never even heard of before.

> Everyone's definition of that is different, I think you will find that
> it's best to just do the full tree, or pick and choose what you want
> from the tree based on your own needs, instead of trying to judge what
> those needs are.

It would probably be ideal if everyone could cherry pick correctly only and
all the commits they require, but reality is quite far from this ideal, which
is why we have things like the stable trees - to simplify the process.

>> Given this, a few projects preferred to delay important kernel updates, and
>> a few even stopped updating the tree altogether, exposing them to critical
>> vulnerabilities.
> 
> What projects are those?  Is it really that hard to take the current
> stable trees for these projects?  Why is this tree going to somehow be
> easier?

I can give you an example offlist (mostly because I don't want to start listing
projects in production with outdated kernels who could use security updates).

>> This project provides an easy way to receive only important security commits,
>> which are usually only a few in each release, and makes it easy to incorporate
>> them into existing projects.
> 
> Define "important".  Now go and look at the tty bug we fixed that people
> only realized was "important" 1 1/2 years later and explain if you
> would, or would not have, taken that patch in this tree.

Probably not, but I would have taken it after it received a CVE number.

Same applies to quite a few commits that end up in stable - no one thinks
they're stable material at first until someone points out it's crashing
his production boxes for the past few months.

> Good luck with this, personally, I think projects should just take the
> stable tree as really, it's not that much churn at all, given the % of
> the mainline tree.

Thanks,
Sasha