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 9C4B58AF for ; Tue, 6 May 2014 17:32:03 +0000 (UTC) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BDB27201B3 for ; Tue, 6 May 2014 17:32:02 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id jx11so11341097veb.28 for ; Tue, 06 May 2014 10:32:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140506171807.GA20776@cloud> 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> From: Andy Lutomirski Date: Tue, 6 May 2014 10:31:40 -0700 Message-ID: To: Josh Triplett Content-Type: text/plain; charset=UTF-8 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 Tue, May 6, 2014 at 10:18 AM, wrote: > On Fri, May 02, 2014 at 03:35:28PM -0700, Andy Lutomirski wrote: >> On Fri, May 2, 2014 at 2:39 PM, Josh Boyer wrote: >> > On Fri, May 2, 2014 at 5:27 PM, James Bottomley >> > wrote: >> >> On Fri, 2014-05-02 at 17:19 -0400, Josh Boyer wrote: >> >>> On Fri, May 2, 2014 at 5:01 PM, Dave Jones wrote: >> >>> > On Fri, May 02, 2014 at 04:41:41PM -0400, Theodore Ts'o wrote: >> >>> > >> >>> > > And I think we can also further break this down into the classes of >> >>> > > code which require root privs (i.e., like kexec), and those which can >> >>> > > be used by any userid. >> >>> > >> >>> > In the brave new world of secure boot, we kind of have to care about >> >>> > even the root cases now too [*], but I agree in the general case. >> >>> >> >>> Speaking of that... is it worth my time to propose a "What to do about >> >>> the secure_modules/trusted_kernel/whatever patch set that distros are >> >>> carrying to support Secure Boot? I thought we had agreement and a >> >>> path forward at LPC last year, but things seem to have gotten derailed >> >>> again. >> >> >> >> Would you believe we're just discussing with the distros how we might >> >> re-engineer the Linux secure boot process. Unfortunately the details >> > >> > I would believe it. >> > >> >> depend on a UEFI forum proposal that are UEFI confidential at this time, >> >> but you can probably pick them up from Peter Jones, since you're a Red >> >> Hat employee. One of the side effects of this, if it happens, will be >> > >> > OK. >> > >> >> to separate Linux secure boot policy from Microsoft's binary signing >> >> requirements which might take some of the heat out of the arguments >> >> about which parts of the patch are to please microsoft and refocus the >> >> debate towards how we make better use of secure boot. I'll try and >> >> ensure that either the proposals are public by KS or that we have >> >> permission to share the details. >> > >> > The objectionable parts having to do with signing aren't even in the >> > patchset Matthew has posted. That's the initial set he tried to get >> > pulled in and failed. If the proposal drastically changes that >> > approach I'd be surprised (maybe pleasantly). >> >> FWIW, I really don't like the approach where we say that the kernel >> must be inviolate but that user code can do whatever it likes as long >> as the kernel isn't compromised. This may be needed to comply with >> current MS/UEFI policy, but I think it largely misses the point wrt >> actual security. >> >> If the policy can change, then that might be a huge win. > > We shouldn't give up on securing userspace, either; protecting the > kernel is necessary but not sufficient. But I do think it's worthwhile > to enforce "root != kernel", quite apart from any "secure boot" > requirements. That's what Matthew's patches primarily serve to do: make > root not kernel-equivalent. > 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. --Andy