Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions

[josh@joshtriplett.org]

On Fri, May 02, 2014 at 03:35:28PM -0700, Andy Lutomirski wrote:
> On Fri, May 2, 2014 at 2:39 PM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Fri, May 2, 2014 at 5:27 PM, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> >> On Fri, 2014-05-02 at 17:19 -0400, Josh Boyer wrote:
> >>> On Fri, May 2, 2014 at 5:01 PM, Dave Jones <davej@redhat.com> 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.

- Josh Triplett