linux-kernel - Re: [PATCH 1/9] Known exploit detection

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:	Fri, 13 Dec 2013 10:37:14 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dave Jones <davej@...hat.com>, "Theodore Ts'o" <tytso@....edu>,
	vegard.nossum@...cle.com, LKML <linux-kernel@...r.kernel.org>,
	Tommi Rantala <tt.rantala@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andy Lutomirski <luto@...capital.net>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Alan Cox <alan@...ux.intel.com>,
	Jason Wang <jasowang@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	James Morris <james.l.morris@...cle.com>
Subject: Re: [PATCH 1/9] Known exploit detection

On Fri, Dec 13, 2013 at 10:14 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Dec 13, 2013 at 9:58 AM, Kees Cook <keescook@...omium.org> wrote:
>>
>> These locations tend to be very hard to reach accidentally
>
> Not necessarily.
>
> Don't get me wrong - I think that it's a good idea to at least have
> the option to complain about certain errors, and leave markers in the
> logs about things that look suspicious.
>
> But looking through the recent list of commits that explicitly mention
> a CVE, the only one I find where a syslog message would make sense is
> the HID validation ones. There, adding a warning about malicious HID
> devices sounds like a good idea.
>
> But a *lot* of the rest is just checking ranges or making sure we have
> proper string handling etc that just wouldn't be practical to check.
> So the error itself may be "hard to reach accidentally", but
> *checking* it would be so complex/painful that it would likely just
> introduce more room for bugs.
>
> So I think the "WARNING" thing is a good idea, but I think it is a
> good idea if it's used very judiciously. IOW, not for "random CVE"
> (because quite frankly, most of them seem to be utter shit), but for
> serious known issues. And for those issues *only*.
>
> If I start seeing patches adding warnings "just because there's a
> CVE", then I'm not in the least interested. But if there is some known
> root-kit or similar, then by all means..

Yeah, totally agreed. Doing it for all CVEs (or even most) would be a
disaster. Stuff like memory content leak CVEs are usually on common
paths that userspace uses all the time. Vegard proposed only doing it
for serious privilege escalation issues, and I couldn't agree more.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/