On Thursday 02 April 2009 09:21:08 pm Jarrett Lu wrote: > On 04/01/09 09:46, Paul Moore wrote: > > On Wednesday 01 April 2009 03:46:58 am Jarrett Lu wrote: > >> ... and probably outside the scope of labeled NFSv4 enhancement. > > > > Perhaps. Keep in mind I'm trying to think a bit more generically; if > > that isn't the goal I'll be happy to go back to my corner and sit quietly > > :) > > > >> So realistically, I think the DOI + opaque label is useful between very > >> compatible systems. > > > > Of course. I agree there are a lot of things you can do with a DOI + > > opaque label, especially if you are only concerned about end-to-end > > security issues which I believe is the case for labeled NFS. > > > >> Given that limitation, may be the "package" is small enough and can be > >> passed in RPC layer during authentication so that MLS can share files > >> with like MLS systems, and same is true for DTE, fmac, smack, .... > > > > Well, I think all that the opaque label buys you is the ability to limit > > who you share the security policy/translation "package" with, as those > > systems that participate in the labeled communication (be it NFS, generic > > IP or some other random service) still need to worry about label > > translation and security policy differences if they want to enforce > > policy locally. > > I am still trying to understand what is needed to make safe sharing > possible. BTW, are you implying that it's always necessary to do one > label translation, e.g. from on-the-wire format to a native label format? [Sorry for the delayed response.] As I said earlier I think the easiest way forward is to design systems that can interoperate with established DOI definitions and not worry about what other peer systems are using for a security mechanism. In some cases that will require translations from a native label format to a wire format and back to a label format; in some cases it may result in no translations at all. It all depends on the individual systems and the DOI. -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
