lkml.org 
[lkml]   [2007]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Smack: Simplified Mandatory Access Control Kernel

    --- Andi Kleen <andi@firstfloor.org> wrote:

    > Casey Schaufler <casey@schaufler-ca.com> writes:
    >
    > > Smack is the Simplified Mandatory Access Control Kernel.
    >
    > I like the simplified part.
    >
    > > +static int smk_get_access(smack_t sub, smack_t obj)
    > > +{
    > > + struct smk_list_entry *sp = smack_list;
    > > +
    > > + for (; sp != NULL; sp = sp->smk_next)
    > > + if (sp->smk_rule.smk_subject == sub &&
    > > + sp->smk_rule.smk_object == obj)
    > > + return sp->smk_rule.smk_access;
    >
    > Do I miss something, or is there really no locking for the reader side
    > of the list? That looks dangerous. Of course a global lock for readers
    > would be likely a scaling disaster. You could use RCU.

    Entries are never deleted, although they can be modified.

    > Or if you assume rules are changed only very infrequently it might
    > be more cache friendly to compile all the rules into a linear buffer
    > and then just replace the whole buffer atomically with a RCU
    > grace period on cahnges.

    Individual entries can be modified without changing the whole
    thing, but they shouldn't change often.

    > It doesn't look like it would scale to larger numbers of rules though.
    > Is that intended? Would caching of decisions fit into the design?

    I put some thought into clever schemes for supporting large rule sets
    well but decided to go ahead with the simplest possible mechanism
    because I expect that in real deployments the number of rules will
    be small. In fact, experiance says that virtually all access choices
    will be covered either by the subject==object case or the subject can
    read floor case. Cacheing, hashing, and 2D structures are all
    possibilties that I would be happy to entertain as enhancements.

    > Also in general code style would need some improvements;
    > e.g. no externs in .c; no ../.. include hacks etc.
    > You also seem weak on the Documentation front.

    Yes, it is pretty sparse.

    > Other than that it looks reasonably clean (haven't read all of it)

    Thank you for your comments. I think the next version will be improved.


    Casey Schaufler
    casey@schaufler-ca.com
    -
    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: 2007-08-12 03:39    [W:3.670 / U:0.616 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site