--- Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > ... > > 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@xxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
