linux-kernel - Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <515984.88226.qm@web36611.mail.mud.yahoo.com>
Date:	Sat, 11 Aug 2007 18:36:02 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Andi Kleen <andi@...stfloor.org>, casey@...aufler-ca.com
Cc:	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...l.org, torvalds@...l.org
Subject: Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel


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

> Casey Schaufler <casey@...aufler-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@...aufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/