The linux-stable security tree project [LWN.net]

From:		Sasha Levin <sasha.levin-AT-oracle.com>
To:		LKML <linux-kernel-AT-vger.kernel.org>, stable <stable-AT-vger.kernel.org>
Subject:		[ANNOUNCE] linux-stable security tree
Date:		Mon, 11 Apr 2016 13:53:41 -0400
Message-ID:		<570BE4A5.20200@oracle.com>
Cc:		lwn-AT-lwn.net
Archive‑link:		Article

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.

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.

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.

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.

The tree is available at:

	https://git.kernel.org/cgit/linux/kernel/git/sashal/linux...

Support is provided for all active -stable trees (https://www.kernel.org/category/releases.html).
Branches/tags for unsupported versions of >=3.0 kernels were also generated for reference.


Thanks,
Sasha

to post comments

The linux-stable security tree project

Posted Apr 11, 2016 21:02 UTC (Mon) by cryptoknight (guest, #108170) [Link] (12 responses)

Having a place to track known security-relevant patches to the kernel sounds like a great idea, but the stated purpose sounds kind of suspect. Is this only for high-visibility vulnerabilities that e.g. have a CVE number attached? Seems to me that almost all bug fixes at the kernel level are potentially security relevant, whether it's known at the time of fix or not. If companies want to only update and revalidate their products when they have to ship a security fix, fine, but they ought to be pulling the entire stable tree at the time.

The linux-stable security tree project

Posted Apr 12, 2016 2:54 UTC (Tue) by torquay (guest, #92428) [Link] (4 responses)

Is this only for high-visibility vulnerabilities that e.g. have a CVE number attached?

Indeed, this raises a question: what about all the security fixes which are deliberately obfuscated by kernel devs?

The linux-stable security tree project

Posted Apr 12, 2016 2:59 UTC (Tue) by corbet (editor, #1) [Link] (3 responses)

It might help the discussion if you could point to a few of those in the recent commit history? Then we'd know what you're talking about...

The linux-stable security tree project

Posted Apr 12, 2016 5:08 UTC (Tue) by torquay (guest, #92428) [Link] (2 responses)

For examples, see https://lwn.net/Articles/631319/ and http://arstechnica.com/security/2013/05/critical-linux-vulnerability-imperils-users-even-after-silent-fix/

There is no reason to believe that the obfuscation practices by Linux kernel devs have changed since then.

The linux-stable security tree project

Posted Apr 12, 2016 22:02 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

three year old articles hardly count as recent.

The linux-stable security tree project

Posted Apr 12, 2016 22:17 UTC (Tue) by PaXTeam (guest, #24616) [Link]

they do if nothing changed since then. do you have evidence to the contrary perhaps?

The linux-stable security tree project

Posted Apr 12, 2016 3:03 UTC (Tue) by sashal (✭ supporter ✭, #81842) [Link] (6 responses)

In general, I'm aiming to get anything exploitable by a local unprivileged user (or better), and not just CVEs.

The linux-stable security tree project

Posted Apr 12, 2016 11:47 UTC (Tue) by tao (subscriber, #17563) [Link]

Based on what goes into a typical -stable kernel update that would be at least half the fixes.

* Unitialized variables an in some cases be security issues, as can undefined behaviour.
* File system corruption and network packet corruption can definitely be security issues.
* Severe performance issues allows for denial of service.
* A lot of driver bugs can allow for crashing the system.

... the list goes on.

While I understand that security folks are frustrated that the kernel people don't tend to tag things as security issues, it's by and large because from a kernel point of view most fixes are fixes for potential security issues. Pretty much anything that fixes data corruption, race conditions, works around weird behaviour in hardware, resource starvation, etc., can be regarded as improving security. Then there's of course information leaks, etc.

I think it'd be easier to tag non-security fixes. Documentation fixes (unless of course it's documentation that in its old version would cause people to do insecure things -- for instance manual pages for userland interfaces that warn about insecure functions are, in a sense, security fixes), adding new hardware ID's., typo fixes, compile time fixes, new features added (they probably add security issues though, OTOH new features normally shouldn't go into -stable kernels), etc.

The fixes in the -stable series (at least past x.y.z+1) that lack potential security ramifications tend to be so unobtrusive that removing them probably causes more issues than keeping them.

If this project aims to identify potential security issues fixed in HEAD and backport those fixes, then might I suggest just backporting them to -stable instead. If the fixes are well-contained enough to allow for backporting, and important enough to warrant it, then they should be in -stable too.

The linux-stable security tree project

Posted Apr 12, 2016 15:51 UTC (Tue) by pabs (subscriber, #43278) [Link] (4 responses)

Could you also add introduced-CVE-XXXX-YYYY and fixed-CVE-XXXX-YYYY tags?

The linux-stable security tree project

Posted Apr 12, 2016 16:22 UTC (Tue) by sashal (✭ supporter ✭, #81842) [Link] (3 responses)

Keep in mind that most CVEs get assigned after the commit was already merged (this is usually the case unless the fix is embargoed), so adding these tags won't work well with git.

The linux-stable security tree project

Posted Apr 12, 2016 23:11 UTC (Tue) by vonbrand (guest, #4458) [Link]

I remember a recent discussion on the hassle to get a CVE assigned, and the interested party just gave up on this. Just a tiny fraction of vulnerabilities get tagged thusly.

The linux-stable security tree project

Posted Apr 13, 2016 1:15 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

I'm talking about git tags (or possibly git notes), not about modifying git commit messages.

The introduce-CVE-XXXX-YYYY tag could hardly be added by the commit author :)

The linux-stable security tree project

Posted Apr 14, 2016 7:56 UTC (Thu) by iq-0 (subscriber, #36655) [Link]

I think this is the only sane way to work with security fixes.

Fixes are fixes, their is nothing "security inherent" of them. They fix a problem, lots of different problems can be used directly or indirectly to make a working security vulnerability. Some of the best write-ups I've read used obscure bugs for some side-effect they needed. Was fixing that bug really a security fix? In and on itself is was worthless, but combined with X, Y and Z it could be used for some nefarious purpose.

So I side with the kernel developers on the "this commit fixes this problem" and not "this is a security fix", that is an orthogonal problem space. Refer from an security tracker to the commit or build a repository that tags commits with security related tracking (which are both effectively the same thing only tracked from the other side).

Note that this does not mean (kernel) developers should actively ignore relations security issues and bug fixes, just that it's reasonable that they should not necessarily be intertwined. Just make it easy for them to report the relation between a security issue and the bugfix (patch in message id on mailinglist X; commit id on repository Y; problem report in message id on mailinglist Z; problem report at some url).

There is no excuse to just fully ignore some information you have about security related issues and fixes "because that's their problem", but that's also true the other way around (they won't have to go out of their way to ensure that there is a security issue being tracked if they are not aware of one). So if some group wants to track "possible security issues", perhaps what is needed is a sort of closed "linux-possibly-security-related" mailinglist where developers can easily report that some patch addresses something security related so that the tracking group can follow it (the fix goest through the normal development process).

So somebody really consider doing something like that, they would almost certainly need their own vulnerability tracker (LVE?) because their is often a whole lead time until something becomes a CVE (if ever). The interesting problem around this idea will probably be when things become visible (on release? on CVE disclosure? on known exploit?) and who has access to this information trove from the start. Getting that right will probably determine if developers are willing to report possible issues this way or simply can be bothered because it would only (from a possible point of view) only lead to problems being exploited (thus causing more harm than not reporting them).