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

What happens if a symlink is involved?