--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

quoted text
> 
> ...
> > The paradigm is* a security "blob" which is meaningfull only to the
> > security module proper. This is what allows SELinux to use secids and
> > Smack to toss around text strings. It's not MAC data and it's not
> > an NFS label, it's private to the LSM. It makes a lot of sense to use
> > an xattr to store a blob but, as the AppArmor people have been known
> > espouse, it's not the only way. The blob could be referenced from a
> > table using the inode number (it has been done on other systems and
> > works fine) rather than an xattr, in which case the whole "name" may
> > be meaningless.
> 
> I think it might help for you to look at how the hook is actually used.
> It is specific to MAC labeling, and we do not want some random other
> security attribute name returned here that is for some purpose other
> than MAC labeling, like security.capability.

I can see how it's being used just fine, thank you.
If you only want this interface for SELinux put it in
SELinux. Don't clutter up the LSM with it. If it's an
LSM interface it should be potentially useful for any
and all LSMs, be they label based or not, MAC or DAC.
Even within a label based MAC scheme it may not be
sensible, given that a MAC scheme could use multiple
xattrs (e.g. a B&L sensitivity label and a Biba integrity
label) to store its blob.

If what you want in LSM terms is a name to give the blob
make your interface be security_blob_name(). The LSM can
deal with this as it sees fit, and NFS can determine if
it's a blob that it wants to deal with independently.
Such an interface could even support stacking should
that ever come about.

LSM is not supposed to be only for MAC and it's not supposed
to be only for label based schemes. It's supposed to be
for additional security restrictions. Providing an interface
that should be generally applicable with a name that
constrains it to a specific subset of those schemes is wrong.



Casey Schaufler
casey@schaufler-ca.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html