Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Sa, 2016-07-30 at 18:36 +0200, Luis R. Rodriguez wrote:
> On Fri, Jul 29, 2016 at 03:25:09PM -0700, Andy Lutomirski wrote:
> > On Fri, Jul 29, 2016 at 3:10 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > > On Do, 2016-07-28 at 16:57 +0000, Jason Cooper wrote:
> > >> Hi Andy,
> > >>
> > >> On Wed, Jul 27, 2016 at 01:09:37PM -0700, Andy Lutomirski wrote:
> > >> ...
> > >> > I would like someone to explain why using the keyring mechanism for
> > >> > this in the first place is a good idea.
> > >> >
> > >> > As far as I can tell, the design goals of "keys trusted by the kernel
> > >> > for modules, firmware, etc" are:
> > >> >
> > >> >  - Keys are added at build time or, according to potentially
> > >> > system-specific rules, at boot time.
> > >> >
> > >> >  - Keys should specify what they're trusted *for*.
> > >>
> > >> Well, I'd argue that keys should specify what they are *intended* for by
> > >> the keyholder.  A useful security system could further restrict the key
> > >> as needed.
> > >
> > > We've already started.  Currently the kernel_read_file() and family of
> > > functions provide the LSM hooks needed for verifying file signatures of
> > > files read by the kernel.  The kernel_read_file_id enumeration is used
> > > to differentiate between callers.  Based on this enumeration, the
> > > *intended* for could be defined.  It would make sense to extend the IMA
> > > policy language to support *intended* for.
> > >
> > 
> > Having kernel_read_file know the purpose is a big step in the right
> > direction, although, as I think I and others have pointed out, just an
> > enum is insufficient -- for firmware, at least, the *name* is
> > relevant.

> The name is passed for firmware, the wrapper kernel_read_file_from_path()
> is used. So if we wanted an LSM extension on name I think we can do that
> on kernel_read_file_from_path() ?

It shouldn't make a difference whether kernel_read_file() is called
directly, or the kernel_read_file_by_path/fd() are called.  The pathname
is accessible from the "file" argument.

> > But this is almost orthogonal to what I'm talking about.  I'm saying
> > that, before seriously considering any extensions to using keyrings to
> > decide which files are okay for kernel_read_file() and similar, we
> > should first consider whether using keyrings *at all* for this is a
> > reasonable long-term approach.
> 
> It sounds like an LSM decision ?
> 
> Of course, part of the issue with signing / keyring stuff here is
> module signing wasn't designed as an LSM, I've discussed with David
> the possibility of LSM'ifying kernel signing infrastructure, with
> a lot of works it seems possible. With LSM stacking this then should
> group up together in a sensible way. Then for instance eventually
> module signing and firmware singing could be stackable LSM decisions,
> and not a kconfig final decision -- as they are today. To me though
> having module signing or firmware signing be LSM'ifable is not a hard
> requirement given its just ways to do things, so its not a requirement,
> architecturally its just better to have long term. So when I say this
> sounds like an LSM decision I'm projecting on to how this question
> of keyrings then becomes a stackable LSM question.
> 
> > Elsewhere in this thread, Jason Cooper
> > mentioned keyholders.  For this type of verification key, the holder
> > isn't even on the same machine as the kernel on which
> > kernel_read_file() is called.
> 
> When you run a distro kernel your kernel key holder isn't on the
> same machine either. Then for that shiny mobile OS that runs Linux,
> they use LoadPin LSM, so they have opted out of the keyholder/keyring
> thing but punted it in another way.
> 
> In the stackable LSM context, what is not possible then?
> 
> > Sure, one might want to configure a system so IMA is used for
> > kernel_read_file(), and one might want to configure IMA to use
> > keyrings, but that's far from being the only sensible configuration.
> 
> If we LSM'ify it all, then I think anything should be possible so long
> as we pass on to the LSM enough context. Since we already pass context
> of how something is read that should help. Path seems like the next
> target ? Anything else ?

One issue that repeatedly comes up, at least for IMA, is key management.
Will the keys be used solely for code provenance or to also provide
version control?

Mimi