On Fri, 2008-02-29 at 08:30 -0500, Stephen Smalley wrote: > On Thu, 2008-02-28 at 20:00 -0500, Christoph Hellwig wrote: > > On Thu, Feb 28, 2008 at 07:32:47PM -0500, Dave Quigley wrote: > > > I can always go with the original hook name of get_security_xattr_name > > > which turns into a security_get_security_xattr_name call which seems a > > > bit ludicrous. The only other complaint that I saw from Casey besides > > > the name of the function was that there could be more than one xattr. If > > > we want to address that then I need another hook that says give me all > > > data that the LSM deems important for this file. Which is essentially > > > the same thing as taking each of the xattr names that the module will > > > provide, grabbing each of them in turn, and concatenating them together. > > > For SELinux this is no different than getsecurity with the selinux > > > suffix. The same goes for SMACK. > > > > What about Casey's suggestion of get_security_blob? For any reasonable > > module that just has a single xattr it's trivial and for those that > > have multiple or a different storage model it might get complicated > > but that's not our problem for now. > > Possibly I'm missing something, but if I'm implementing a security > module that has any security attribute at all, e.g. capability module > with security.capability, and I see a hook called "get_security_blob" or > "get_security_attr" or the like, I'll implement that hook and return my > attribute there. Which in turn will _break_ the labeled NFS > functionality because it is expecting a MAC label specifically. > > The whole point here is that we do not want modules like capability to > return their security attributes here, because this is to support > labeled NFS functionality in support of enforcing MAC. > > I don't especially care about the hook name per se, but the interface > (whatever it may be) needs to convey the proper semantics, and the > semantics truly are MAC specific (and should be). BTW, to date, "security blob" has been used to refer to the structures allocated by the security modules referenced by the void* security fields in the kernel data structures (task, inode, ...), while "secctx" (security context) and "secid" (security id) have been leveraged by subsystems like audit, netlink and labeled IPSEC to represent security labels. -- Stephen Smalley National Security Agency -- 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
