lkml.org 
[lkml]   [2005]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 5/12] lsm stacking v0.2: actual stacker module
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-07-11 20:00    [W:2.862 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site