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? 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. I think Jarret's quite right to ask that we do better than that. Doing better means: a) coming up with a common labeled security policy language for MLS and DTE, b) ensuring that clients and servers agree on a DOI's policy. (a) is hard because we'd have to harmonize the differences between exiting operating systems' labeled security policies, but I doubt it's infeasible. (b) is easy: exchange name+version of a DOI's security policy and you're done (this can be a URL, a hash of the policy document, whatever). > > True. The first question is whether we should try to solve, or at least > > ease, the label interpretation / translation problem in the context of > > NFSv4 protocol. I don't know if we can solve it, but it seems worthwhile > > to explore further, to gain more understanding if nothing else. > > I've been trying to look at this problem in a more generic sense and not just > from a labeled NFS point of view. While the current pain point is labeled NFS > the idea of label translation/encoding/etc is not exclusive to NFS or network > filesystems in general; I'm sure we can all agree on this. While we may need > to solve (as best we can) the label translation issues on a per-application > basis I really hope that we might be able to develop a solution which can be > used across multiple applications and not just NFS. +1 > > The challenge of interpreting and translating labels is that one system > > needs to know a lot of info about its peer. And there is no good way to > > describe the (sometimes subtle) difference. I think this problem may be > > harder on DTE systems than on MLS systems, I believe. > > I'm not sure we will ever be able to arrive at a solution that requires a > system to be able to understand the security policy/labels of another; things > change to much and I don't think anyone's crystal ball is that good. > Personally I think the best we can do is hope for a solution that allows a > system to understand a security policy/label system defined by a pre-existing > DOI definition. If we can do that then we can at least allow two different > systems to communicate via an agreed upon DOI regardless of their internal > security policies/labels. I'll admit it isn't perfect, but I think the > problem space is much smaller and likely to have less churn over time. +1 > > Assuming we can assemble all the information required to do > > label translation correctly into a package, passing that around the > > systems seem inefficient, non-scalable ... There's no need to refer to labeled security policies by value at the application protocol layer -- just by name/reference. The common policy can be referenced by URL so that it can be downloaded only when it's changed. > > ... 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. Nico -- -- 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.
