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:	Tue, 12 Apr 2016 14:52:34 +0200
From:	Willy Tarreau <w@....eu>
To:	Eddie Chapman <eddie@...k.net>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Sasha Levin <sasha.levin@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	stable <stable@...r.kernel.org>, lwn@....net
Subject: Re: [ANNOUNCE] linux-stable security tree

Hi Eddie,

On Tue, Apr 12, 2016 at 01:31:21PM +0100, Eddie Chapman wrote:
> None-the-less, I applaud and thank Sasha for this new effort, and I
> personally will find it very useful.  Yes, the lines between bug fix and
> security fix are very blurred, and so this tree won't have every "security"
> fix. But I believe and trust it *will* at least contain fixes for bugs that
> have the most severe security impact.

It will only contain them if they are already in the respective stable trees,
which means that when I miss a fix (common), it won't appear there either.
At first I thought "oh cool, a repository of known things that must absolutely
be fixed, that will help me do my backports" and in the end I fear it will be
blindly used by end users who don't understand what they're missing but who
still believe they limit the risk of upgrades. Just this morning I saw a
report of a user saying that haproxy crashes is 2.6.24 kernel which is
"otherwise perfectly stable and achieves multi-years uptime"... Imagine
what such users will do when backporting fixes into they multi-thousands-bugs
kernel!

> Where I will find this very useful is in having a "place" where I can see
> what are probably the most important security fixes applicable to the stable
> trees I am interested in.  Because if I may offer one criticism of the
> kernel stable trees in general, it is that it is very hard to find and
> identify fixes for known security vulnerabilities. Whenever I want to update
> the kernel in one of my projects, I find myself having to hunt around a lot
> for information, stringing together bits from bug reports, mailing lists,
> git commits, to track down whether or not a particular vulnerability is
> fixed in a stable tree.  Not always, sometimes it is very clear that a
> particular fix in a particular stable release fixes a known vulnerability,
> especially with commits e.g. referencing CVEs in the header or commit
> message. At other times there might be absolutely nothing in the fix to
> indicate this fixes a known vulnerability.

I agree with this and it's not inherent to the stable trees but to the fact
that vulnerability IDs are assigned via a parallel process and often after
a fix gets merged, so the link between the commit and the CVE ID is easily
lost. Yes a central repo of known bugs by kernel branch and the commits
which fix them would be immensely useful including to the maintainers, but
it's a huge work and I hardly see who would work on such a thing. Note that
it doesn't necessarily need to focus on security only. Any painful bug should
be referenced as present first, then fixed with the relevant commit IDs once
the backports are merged. The "fixes" tag in upstream commits is already a
step forward, but in any case we'd need post-documentation since it regularly
happens that a bug happens to be accidently fixed by some later changes.

Regards,
Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ