Re: [Keyrings] [PATCH] Keys: Add LSM hooks for key management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* David Howells ([email protected]) wrote:
> Chris Wright <[email protected]> wrote:
> 
> > The security check is comparing key label to task label.  If it's not
> > done 100% in current context, then task must be passed to get access
> > to proper label.  So, for example, request-key is done by the special
> > privileged /sbin/request-key via usermodehelper on behalf of someone else.
> 
> Which task(s)? Both the one doing the check, and the one on whose behalf the
> check is done?

Sorry, the one who initiated the request, so rka->context in this case
(the one on whose behalf the check is done).

> > > Auditing?
> > 
> > Hmm, suppose, but auditing is not the charter of LSM.  So in this case,
> > the previous hook can audit key creation if needed.  Just looking to
> > avoid hook proliferation if possible.
> 
> But you don't know the key serial number at that point, hence why I added the
> second hook. I'll drop the second. I can always bring it back later.

You'll know the serial number any time an action is taken on the key,
and that's auditable.  I agree, if we find a need it can certainly be
resurrected.

> > > That's what I was thinking of.
> > 
> > I see, what would they used for?
> 
> I don't know. As far as I know, setxattr and co can be used to set and
> retrieve security data on files. I thought it would be desirable to have
> similar for keys. If not, I can remove both calls/hooks for the time being.

Right, that makes sense considering that data is stored on disk and
likely needs to be initialized at some point by an admin or install.
Keys are transient and I'd expect policy engine to label them when
created.  Looks like Stephen sees a use, so perhaps just dropping
surrounding conditional logic and letting module handle it same as
setxattr case.

thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux