public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@osdl.org>
To: David Howells <dhowells@redhat.com>
Cc: Chris Wright <chrisw@osdl.org>, James Morris <jmorris@namei.org>,
	Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	keyrings@linux-nfs.org, linux-kernel@vger.kernel.org,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [Keyrings] [PATCH] Keys: Add LSM hooks for key management
Date: Fri, 7 Oct 2005 11:51:21 -0700	[thread overview]
Message-ID: <20051007185121.GS16352@shell0.pdx.osdl.net> (raw)
In-Reply-To: <21866.1128676205@warthog.cambridge.redhat.com>

* David Howells (dhowells@redhat.com) wrote:
> Chris Wright <chrisw@osdl.org> 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

  parent reply	other threads:[~2005-10-07 18:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-05 16:28 [PATCH] Keys: Add LSM hooks for key management David Howells
2005-10-05 16:44 ` [Keyrings] " James Morris
2005-10-05 16:48   ` David Howells
2005-10-05 19:31     ` James Morris
2005-10-05 18:40 ` serue
2005-10-05 21:10 ` [Keyrings] " Chris Wright
2005-10-06  8:03   ` James Morris
2005-10-06 10:54     ` David Howells
2005-10-06 15:04       ` James Morris
2005-10-06 15:18         ` David Howells
2005-10-06 16:02           ` James Morris
2005-10-07  8:50             ` David Howells
2005-10-07 18:36               ` Chris Wright
2005-10-06 17:58       ` Chris Wright
2005-10-07  9:10         ` David Howells
2005-10-07 12:59           ` Stephen Smalley
2005-10-07 18:51           ` Chris Wright [this message]
2005-10-06 10:30   ` David Howells
2005-10-06 23:10     ` Chris Wright
2005-10-07  9:57       ` David Howells
2005-10-07 19:36         ` Chris Wright
2005-10-06  8:38 ` James Morris
2005-10-06 11:06   ` David Howells
2005-10-06 14:25     ` James Morris
2005-10-06 15:11       ` David Howells
2005-10-06 16:14         ` James Morris
2005-10-07  9:03           ` David Howells
2005-10-07 14:05             ` James Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051007185121.GS16352@shell0.pdx.osdl.net \
    --to=chrisw@osdl.org \
    --cc=akpm@osdl.org \
    --cc=dhowells@redhat.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@linux-nfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox