From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id CC31E979 for ; Fri, 9 May 2014 18:22:29 +0000 (UTC) Received: from mail.zytor.com (terminus.zytor.com [198.137.202.10]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7F18B20344 for ; Fri, 9 May 2014 18:22:29 +0000 (UTC) Message-ID: <536D1CCE.3060708@zytor.com> Date: Fri, 09 May 2014 11:22:06 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 To: Andy Lutomirski , Josh Triplett References: <5363E8E1.9030806@zytor.com> <20140502193314.GA24108@thunk.org> <20140502194935.GA9766@redhat.com> <20140502204141.GB24108@thunk.org> <20140502210123.GA13536@redhat.com> <1399066024.2202.72.camel@dabdike> <20140506171807.GA20776@cloud> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Josh Boyer , Sarah Sharp , "ksummit-discuss@lists.linuxfoundation.org" , Greg KH , Julia Lawall , Darren Hart , Dan Carpenter Subject: Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 05/06/2014 10:31 AM, Andy Lutomirski wrote: > > I have two main objections to "root != kernel". The bigger is that > I'd like to see the security argument for it so that people can think > about whether it makes sense. The smaller is that "root != kernel" > isn't necessarily well-defined. > > For example, should root be able to write to the filesystem from which > the kernel loads? Should root be able to kexec a new kernel, if that > clears some key known to the current kernel in the process? Should > root be able to start a KVM instance that passes essentially all > hardware through? Should root be able to talk directly to the > system's embedded controller? Should root be able to read all > physical memory? How about reading just enough to learn the kernel's > semi-secret randomized addresses? How about running perf without > restrictions? > > In the past, the actual security goal seems to have been "root shall > not be able to do anything that would anger Microsoft and/or > Verisign", which is far-enough removed from actual security that I > don't want it anywhere near my system. But if I could have a > reasonable policy that "root shall not be able to persistently > compromise the machine", then I think this could be great. > > Note that the latter goal does not actually require that root be > unable to modify the running kernel. > The first aspect of this is that the kernel needs to *be able to* lock out root from select functions. These things will be system configuration dependent. Once you have the separation you can define exceptions. -hpa