Re: [patch 5/12] lsm stacking v0.2: actual stacker module

[Stephen Smalley <sds@epoch.ncsc.mil>]

On Mon, 2005-07-11 at 12:51 -0500, serue@us.ibm.com wrote:
> 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.

Note that these particular hooks are only used for filesystems like
devpts and tmpfs where there is no underlying storage for the security
xattrs but we still need a way to [gs]et the incore inode security label
from userspace.

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

SELinux already checks the name suffix in inode_getsecurity and
inode_setsecurity, and returns -EOPNOTSUPP if it isn't selinux.  Hence,
stacker could just iterate through the modules until it gets a result
other than -EOPNOTSUPP, relying on the modules to check the name.

listsecurity is different, as it is supposed to yield the list of
attribute names concatenated together, but that shouldn't be difficult
for stacker to construct, similar to your getprocattr logic but without
the need to add tags.

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

These hooks aren't supposed to be doing permission checking; that is
handled by the separate security_inode_*xattr hooks.  They are just for
getting/setting the incore inode security label.

> 		This might have the added bonus of obviating the need
> 	for a separate cap_stack module.

I don't think so - different hooks are involved (inode_setxattr vs.
inode_setsecurity).

-- 
Stephen Smalley
National Security Agency