To: Trond Myklebust <trond.myklebust@...>, <casey@...>
Cc: Christoph Hellwig <hch@...>, Dave Quigley <dpquigl@...>, Stephen Smalley <sds@...>, <viro@...>, <bfields@...>, <linux-kernel@...>, <linux-fsdevel@...>, LSM List <linux-security-module@...>
Hum. Security metadata was one of the justifications for the
original implementation of the xattr interface for XFS at SGI.
The implementation was intended to be generic and allow for
storage of data that impacts system behavior. No, it is not
overloading at all, it is really supposed to be used that way.
That's how it works on CXFS, which I know is still proprietary,
but which could become an open peer of NFS someday.
Yes, I can see that having a specific interface reduces the
documentation required, and simplifies it as well. Unfortunately,
given the way that a secctx is defined for either SELinux or
Smack, and the fact that the relationships between secctx values
are defined independently on the server and client* it does not
appear that the interoperability issue has been addressed, or
even really acknowleged with the proposed scheme. Yes, the issue
of label translation has been acknowleged, but it appears to me
that a day one solution is required for the scheme to be useful.
So I suggest, again from a position of possible ignorance, that
the proposed scheme suffers from some of the same interoperability
and specification issues that a name/value pair scheme does, with
the only real improvement being that the name part is hard coded.
Perhaps that is sufficient improvement to justify the loss of
generality, but I personally wouldn't think so.
-----
* Identical SELinux policy or Smack rule specifications are not
necessaily sufficient to ensure label transparency.
Casey Schaufler
casey@schaufler-ca.com
--
