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

[Mimi Zohar]

On So, 2016-07-31 at 09:19 -0700, Andy Lutomirski wrote:
> On Sun, Jul 31, 2016 at 8:31 AM, Mimi Zohar <zohar at linux.vnet.ibm.com> wrote:
> > On Sa, 2016-07-30 at 20:09 -0700, Andy Lutomirski wrote:
> >> On Jul 30, 2016 8:08 PM, "Mimi Zohar" <zohar at linux.vnet.ibm.com> wrote:
> >> >
> >> > 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 at 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.
> >> >
> >>l
> >> What happens if a symlink is involved?
> >
> > For callers of kernel_read_file_by_path(), like firmware, we could pass
> > the pathname, but for the other callers of kernel_read_file/_by_fd() we
> > could use d_absolute_path().
> 
> That seems pointlessly fragile to me, and this issue has been known
> for longer than the code in question has even existed.  How about:
> 
> struct kernel_trusted_file_description {
>   enum kernel_read_file_id type;
>   const char *specific_purpose;  /* may be NULL for KEXEC_IMAGE, etc. */
> };
> 
> int kernel_read_file(struct file *, void **, loff_t *, const struct
> trusted_file_description *);
> 
> rather than trying to guess.
> 
> Also, are there any plans to move module signature verification into
> .kernel_post_read_file?

The whole point of defining the kernel_read_file() family of functions
was to close a class of measurement/appraisal gaps.   To answer your
question, yes IMA measures and/or appraises files on the security post
kernel read hook, based on policy.

Andy, other than IMA-appraisal being xattr based,  I'm not sure why
you're so against it.   if you're going to be at LinuxCon/LSS, perhaps
we could speak in person there.

Mimi