On Thursday 02 April 2009 11:24:24 am Nicolas Williams wrote: > On Wed, Apr 01, 2009 at 12:46:33PM -0400, Paul Moore wrote: > > My only comment was that figuring out how to transfer information over > > the network isn't really that important yet. Reading through the thread > > I don't think there is general agreement on what we even need to send to > > enable proper label translation/encoding/etc. > > I think we all agree that a client and server have to agree on the > meaning of any given DOI number so that they can properly encode labels. > > In order to interop this means we need a common label encoding for any > given DOI. > > I think we agree on that, no? Yep. Although I don't think we should try to force a single label encoding for all DOIs (couldn't tell from your reply how far you wanted to take this); using some combination of DOI+<opaque label> seems reasonable. > That leaves this problem: how to ensure that the client and server do > actually agree as to a given DOI's label encodings? > > That's a big problem that to date has been solved by out-of-band > mechanisms. That solution leaves interoperability in a lurch: it's up > to vendors to cooperate to obtain a common security policy for use on > the wire. Well, I think the trick is you define a security policy and label format in the DOI and then leave it up to the various implementations to handle the necessary internalization and import/export of the DOI. Perhaps we are in a six-of-one/half-dozen-of-the-other discussion right now. > I think Jarret's quite right to ask that we do better than that. I'm not arguing that we try to do better than has been done before, I'm a big fan of "better". My only concern is that if we do "better" we do "better" for more than just NFS. > Doing better means: a) coming up with a common labeled security policy > language for MLS and DTE At this point I'm glad there is an option "B" :) > b) ensuring that clients and servers agree on a DOI's policy. As you point out, this seems much more reasonable of a goal. > > > ... 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 > > :) > > Parts of the solution will be outside the scope of the NFSv4 WG. That > doesn't mean we can't undertake a solution. Assuming (a) (see above) we > need only specify (b) (see above) for NFSv4 -- we can leave (a) to > another WG. I guess I personally don't really care about WG boundaries right now, I'm mostly interested in arriving at a decent, complete solution. My belief is that once we arrive at a good idea we can divide it up amongst whatever WGs are appropriate. -- 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.
