On 2/7/2011 8:12 AM, David Howells wrote:
> Casey Schaufler wrote:
>>> For SELinux vs the rest of the world, you might be able to guess just
>>> looking at the security context. I'm assuming that, say, Smack's
>>> labels are a single text label rather than SELinux's
>> Unless they exceed 23 characters SELinux security contexts are perfectly
>> legitimate Smack labels.
> I suppose it doesn't make sense to have a pool of shared security context
> labels and security IDs shared by all the LSMs on the system with
> between them.
Let's see if I can describe my thinking without making anyone's
brain (including mine) explode...
The good news is that a secid never comes out of thin air, meaning
that before a secid can be meaningful one of the hooks that returns
a secid has to have been called and the LSM has to have generated
one. Although error checking has to be done, there is no legitimate
case where an incoming secid won't have been seen in some previous
The Glass approach (not quite working yet, or I'd likely have put
code out by now) is that on a call to a secid providing hook (e.g.
glass_inode_getsecid()) each LSM hook is called and the secids are
stored in a vector along with a secid generated by Glass. The Glass
secid is returned. For a secid consuming hook (e.g. glass_task_kill())
the secid is found in the mappings and each LSM is called with its
This requires that a mapping table be maintained, which is the
obvious approach, but not an especially appealing one. I am open
to alternatives. It would be really helpful if secids were real
resources so that we could detect when we're done with them, but
glass_secctx_to_secid and glass_secid_to_secctx are unwholesome
but simple with the mapping data hanging around. I am consoled by
looking at the SELinux avc code.
>> If a hook is context laden and hence must be called by each LSM as
>> just until one finds against granting the access, and multiple LSMs
>> fail the access, you want the audit record to include both failures, not
>> just the one. I think.
> At least that's a fairly easy design issue:-)
A matter of a little code and a little data. And callbacks. Yeah.
Just so that nobody gets the wrong idea, David and I are not butting
heads here. We're refining requirements and identifying approaches.
David lead with code, which is the right thing to do. We're primarily
discussing the merits of that base because it's available, and I need
to take a few steps before I may put mine out. I think that we may be
able to get past the problems that have held multiple LSMs back this
To unsubscribe from this list: send the line "unsubscribe
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html