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

From: serue
Date: Mon Jul 11 2005 - 12:58:27 EST


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@xxxxxxxxxxxxxx):
> On Thu, 2005-06-30 at 14:50 -0500, serue@xxxxxxxxxx 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/