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

[Andy Lutomirski <luto@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4525 bytes --]

On Jul 31, 2016 10:29 AM, "Mimi Zohar" <zohar@linux.vnet.ibm.com> wrote:
>
> On So, 2016-07-31 at 09:19 -0700, Andy Lutomirski wrote:
> > On Sun, Jul 31, 2016 at 8:31 AM, Mimi Zohar <zohar@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@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@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.

And to enable firmware verification?

>   To answer your
> question, yes IMA measures and/or appraises files on the security post
> kernel read hook, based on policy.

I wasn't asking anything about IMA.

>
> 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.

I have nothing against IMA.  I have plenty of objection to the core hooks
being simultaneously messy and not supplying enough information to provide
the security properties they should provide.

If IMA doesn't want or need to verify the purpose of the loaded file, fine.

I'll be at KS but not LSS.

--Andy

[-- Attachment #2: Type: text/html, Size: 6831 bytes --]