linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: serue@us.ibm.com
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: serue@us.ibm.com, lkml <linux-kernel@vger.kernel.org>,
	Chris Wright <chrisw@osdl.org>, James Morris <jmorris@redhat.com>,
	Andrew Morton <akpm@osdl.org>,
	Michael Halcrow <mhalcrow@us.ibm.com>,
	David Safford <safford@watson.ibm.com>,
	Reiner Sailer <sailer@us.ibm.com>,
	Gerrit Huizenga <gerrit@us.ibm.com>
Subject: Re: [patch 5/12] lsm stacking v0.2: actual stacker module
Date: Mon, 11 Jul 2005 12:51:35 -0500	[thread overview]
Message-ID: <20050711175135.GD15292@serge.austin.ibm.com> (raw)
In-Reply-To: <1121092828.12334.94.camel@moss-spartans.epoch.ncsc.mil>

Thanks Stephen.

More comments below.  This finally proves that I need to provide some
documentation for each hook under stacker showing how modules are
expected to interact.  This hopefully will help me catch things like
this.  Hopefully it would also be useful to module writers in general.

Quoting Stephen Smalley (sds@epoch.ncsc.mil):
> On Thu, 2005-06-30 at 14:50 -0500, serue@us.ibm.com wrote:
> > Adds the actual stacker LSM.
> <snip>
> > +static int stacker_inode_getsecurity(struct inode *inode, const char *name, void *buffer, size_t size)
> > +{
> > +	RETURN_ERROR_IF_ANY_ERROR(inode_getsecurity,inode_getsecurity(inode,name,buffer,size));
> > +}
> > +
> > +static int stacker_inode_setsecurity(struct inode *inode, const char *name, const void *value, size_t size, int flags)
> > +{
> > +	RETURN_ERROR_IF_ANY_ERROR(inode_setsecurity,inode_setsecurity(inode,name,value,size,flags));
> > +}
> > +
> > +static int stacker_inode_listsecurity(struct inode *inode, char *buffer, size_t buffer_size)
> > +{
> > +	RETURN_ERROR_IF_ANY_ERROR(inode_listsecurity,inode_listsecurity(inode,buffer, buffer_size));
> > +}
> 
> These hooks pose a similar problem for stacking as with the
> [gs]etprocattr hooks, although [gs]etsecurity have the benefit of
> already taking a distinguishing name suffix (the part after the
> security. prefix).  Note also that inode_getsecurity returns the number
> of bytes used/required on success.
> 
> The proposed inode_init_security hook will likewise have an issue for
> stacking.

I can imagine a few ways of fixing this:

	1.	We simply expect that only one module use xattrs.  This
	is probably unacceptable, as we will want both EVM and selinux
	to store xattrs.

	2.	A module registers an xattr name when it registers
	itself.  Then only the registered module is consulted on one of
	these calls.  If no module is registered, all are consulted as
	they are now.

		This prevents a module like capability from deciding
	based on its own credentials whether another module's hook
	should be called.  Is that a good or bad thing?

		This might have the added bonus of obviating the need
	for a separate cap_stack module.
	
	3.	We return an error <0 only if all modules return <0.
	Otherwise we do the obvious thing:  setxattr, return 0.
	getxattr: do we return the first nonzero and stop there, or
	do we return a concatenation of the results?  I assume the
	former...

thanks,
-serge

  reply	other threads:[~2005-07-11 17:56 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30 19:44 [patch 0/12] lsm stacking v0.2: intro serue
2005-06-30 19:48 ` [patch 1/12] lsm stacking v0.2: don't default to dummy_##hook serue
2005-06-30 19:48 ` [patch 2/12] lsm stacking v0.2: replace void* security with hlist serue
2005-06-30 19:49 ` [patch 3/12] lsm stacking v0.2: introduce security_*_value API serue
2005-06-30 19:49 ` [patch 4/12] lsm stacking v0.2: stacker documentation serue
2005-06-30 19:50 ` [patch 5/12] lsm stacking v0.2: actual stacker module serue
2005-07-01  2:32   ` James Morris
2005-07-01 19:24     ` serge
2005-07-01 20:35   ` Greg KH
2005-07-03  0:24     ` serge
2005-07-03 18:25       ` Tony Jones
2005-07-03 18:53         ` James Morris
2005-07-03 19:09           ` Tony Jones
2005-07-03 20:44           ` [PATCH] securityfs Greg KH
2005-07-04 12:39             ` serge
2005-07-04 15:53             ` serge
2005-07-05  6:07               ` Greg KH
2005-07-06 12:25                 ` serge
2005-07-06  6:52             ` James Morris
2005-07-06  7:04               ` Greg KH
2005-07-06 12:29               ` Stephen Smalley
2005-07-06 15:35                 ` James Morris
2005-07-06 16:06                   ` Stephen Smalley
2005-07-06 16:16                     ` Greg KH
2005-07-06 18:01                     ` Chris Wright
2005-07-06 22:08             ` serue
2005-07-06 22:22               ` Greg KH
2005-07-06 23:32                 ` serge
2005-07-07 17:30                 ` serge
2005-07-07 17:48                   ` Greg KH
2005-07-07 18:27                     ` serue
2005-07-07 22:46                       ` serge
2005-07-07 23:06                         ` Greg KH
2005-07-07 23:12                           ` serue
2005-07-08 20:44                           ` serue
2005-07-08 20:49                             ` Greg KH
2005-07-08 21:03                               ` Chris Wright
2005-07-04  3:18   ` [patch 5/12] lsm stacking v0.2: actual stacker module Tony Jones
2005-07-04 11:51     ` serge
2005-07-04 19:37       ` Tony Jones
2005-07-04 20:06         ` serge
2005-07-04 20:41           ` Tony Jones
2005-07-05 18:17             ` serge
2005-07-08 21:43     ` serue
2005-07-08 22:12       ` serue
2005-07-11 14:40   ` Stephen Smalley
2005-07-11 17:51     ` serue [this message]
2005-07-11 19:03       ` Stephen Smalley
2005-07-13 16:39     ` serue
2005-07-13 18:27       ` serue
2005-06-30 19:51 ` [patch 6/12] lsm stacking v0.2: stackable capability lsm serue
2005-06-30 19:52 ` [patch 7/12] lsm stacking v0.2: selinux: update security structs serue
2005-06-30 19:53 ` [patch 8/12] lsm stacking v0.2: selinux: use security_*_value API serue
2005-06-30 19:53 ` [patch 9/12] lsm stacking v0.2: selinux: remove secondary support serue
2005-06-30 19:54 ` [patch 10/12] lsm stacking v0.2: hook completeness verification serue
2005-06-30 19:55 ` [patch 11/12] lsm stacking v0.2: /proc/$$/attr/ sharing serue
2005-06-30 19:55 ` [patch 12/12] lsm stacking v0.2: update seclvl for stacking serue

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=20050711175135.GD15292@serge.austin.ibm.com \
    --to=serue@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=chrisw@osdl.org \
    --cc=gerrit@us.ibm.com \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@us.ibm.com \
    --cc=safford@watson.ibm.com \
    --cc=sailer@us.ibm.com \
    --cc=sds@epoch.ncsc.mil \
    /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;
as well as URLs for NNTP newsgroup(s).