From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752626Ab3LMKXv (ORCPT ); Fri, 13 Dec 2013 05:23:51 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:35408 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752471Ab3LMKXt (ORCPT ); Fri, 13 Dec 2013 05:23:49 -0500 Message-ID: <52AADF96.4090602@oracle.com> Date: Fri, 13 Dec 2013 11:21:10 +0100 From: Vegard Nossum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: James Morris , Greg Kroah-Hartman CC: Dave Jones , Kees Cook , "Theodore Ts'o" , LKML , Tommi Rantala , Ingo Molnar , "Eric W. Biederman" , Andy Lutomirski , Daniel Vetter , Alan Cox , Jason Wang , "David S. Miller" , Dan Carpenter , James Morris Subject: Re: [PATCH 1/9] Known exploit detection References: <1386867152-24072-1-git-send-email-vegard.nossum@oracle.com> <20131212190659.GG13547@thunk.org> <20131213002523.GA20706@redhat.com> <20131213014220.GB11068@kroah.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/13/2013 06:09 AM, James Morris wrote: > On Thu, 12 Dec 2013, Greg Kroah-Hartman wrote: > >> On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote: >>> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote: >>> >>> > - who will keep adding these triggers going forward? >>> > > I think we'd need to have someone commit to maintaining this long term > before seriously considering it as part of mainline. Over time it will > become increasingly useless if new triggers aren't added. Based on your input, we (the Ksplice team) will probably set up a public git repository where we maintain these patches on top of the latest released kernel. > What happens when code is refactored, who refactors the triggers? > >>> also.. >>> >>> - Who will test the existing triggers are doing the right thing when related code changes. >> I don't think refactoring or maintenance is a huge issue. The triggers are mostly one-liners in the error path of a specific input validation check. I haven't maintained these patches for a very long time, but at least nothing came up in the six months of development that I've had these patches sitting for. I'd say the person doing the refactoring should also take care to maintain the trigger, but if it just doesn't make sense anymore, it can also just be taken out. In any case, maintaining a public git repository alongside mainline will give us some experience with overcoming refactoring/code changes. >> And: >> - how do you determine an "expoit attempt" from "userspace program >> doing something stupid" / "corrupted filesytem mounted"? >> > > Right, and if there are enough false positives, it'll end up being quite > useless. > > I suspect this kind of thing is better done in userspace anti-malware > scanning. > >> I really don't like this, it means that our normal error handling for >> userspace data will suddenly all have CVE entries on them over time. >> How is that helpful to anyone? >> >> Think ahead in 10-20 years, what is the code paths going to look like >> then? Horrible... > > Agree. > > This could make an interesting research project outside of the kernel. It > doesn't belong in mainline without at least first being proven in the > field and also properly maintained long term, if at all. > I already suggested a 5-year expiry date for any triggers we add. It's easy to retire them based on the CVE (or other) identifier that includes the year (possibly combined with git blame and friends). I also think the set of triggers should be limited to serious bugs that could lead to privilege escalation. There are not THAT many of them. There are probably fewer than 20 every year, which would cap the total number of triggers at 100 in the whole kernel at any given time. The point is NOT to add triggers in every error path in the kernel, of course not. Triggers should only be added where there's a real possibility of the bug actually being exploited. I thought about requiring a proof-of-concept exploit code to be provided with each trigger as well, but that could be too hard to be useful in practice, since actually exploiting any given potential privilege escalation bug could require a lot of ingenuity. Thanks, Vegard