On Thu, 2008-02-28 at 20:00 -0500, Christoph Hellwig wrote:
quoted text
> 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).


-- 
Stephen Smalley
National Security Agency

--
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