From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website From: Stephen Smalley To: Jarrett Lu Cc: labeled-nfs@linux-nfs.org, nfs-discuss@opensolaris.org, selinux@tycho.nsa.gov, nfsv4@ietf.org In-Reply-To: <49D10FC1.3000103@sun.com> References: <1232651815.24537.15.camel@moss-terrapins.epoch.ncsc.mil> <49C9F0E1.1040202@sun.com> <20090325163317.GV9992@Sun.COM> <49CB4A18.3090709@sun.com> <20090326150934.GR9992@Sun.COM> <49CBFB94.6030408@sun.com> <20090327001102.GU9992@Sun.COM> <1238158539.15207.6.camel@localhost.localdomain> <1238160162.15207.19.camel@localhost.localdomain> <49CD06E7.6030802@sun.com> <20090327172632.GA9992@Sun.COM> <49CD2169.3080209@sun.com> <1238434634.2484.90.camel@localhost.localdomain> <49D10FC1.3000103@sun.com> Content-Type: text/plain Date: Mon, 30 Mar 2009 17:14:24 -0400 Message-Id: <1238447664.2484.119.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Mon, 2009-03-30 at 11:30 -0700, Jarrett Lu wrote: > On 03/30/09 10:37, Stephen Smalley wrote: > > On Fri, 2009-03-27 at 11:56 -0700, Jarrett Lu wrote: > > > > > Nicolas Williams wrote: > > > > > > > On Fri, Mar 27, 2009 at 10:03:35AM -0700, Jarrett Lu wrote: > > > > > > > > > > > > > I agree with your statements on TE vs. MLS/BLP. The problem we try to > > > > > solve is whether a DOI field + an opaque string is sufficient to solve > > > > > the interoperability problem. My opinion is that it's insufficient as it > > > > > doesn't take the "how to interpret MAC attribute agreement among all > > > > > communicating peers" into account. The current proposal seems to assume > > > > > when a node sees a DOI value of 5, it knows how to interpret the opaque > > > > > field. This may not be true. In MLS, one also needs to know which agreed > > > > > upon label encoding file to use in order to interpret label in the > > > > > opaque filed. I believe the same is true for TE -- one needs to know the > > > > > security policy being used in order to correctly interpret security > > > > > context string in the opaque field. DOI + opaque field doesn't say which > > > > > label encoding scheme or which security policy. > > > > > > > > > > > > > > What would you add or remove on the wire to solve this problem? My > > > > guess: a registry of per-DOI rules, like CALIPSO does. I don't think a > > > > registry of DOI rules is strictly necessary for NFS (though I can see > > > > how it helps in the case of IP), but I certainly don't object. > > > > > > > > > > > I don't yet see a good way to solve this problem using bits on the wire. > > > The agreement on what label encodings or security policy to use seems > > > better solved in an out of band manner. For example, on a (secure) > > > website, you can say "download this label encoding file or configure > > > your MAC system with this policy and use DOI number 5. Then we can talk". > > > > > > BTW, CALIPSO with IP module has the same issue. While the spec talks a > > > lot about how a CALIPSO system should behave, CALIPSO can't tell its > > > peers to use a particular label encoding. That's done outside CALIPSO. > > > > > > I believe it's still worthwhile to request adding a DOI + an opaque > > > field in NFSv4 protocol. The spec should be clear that other > > > arrangements need to be made before interoperability can take place. > > > > > > Once we decouple DOI from how the opaque field should be interpreted, > > > it's possible for NFSv4 to use CALIPSO DOI. For example, DOD can reserve > > > DOI 1000 through 1005. It can then decide that 1000 is only used by MLS > > > systems with a particular label encoding; and 1004 is for TE systems > > > configured with a particular secular security policy. As long as all > > > systems using these DOIs agreeing to that, they can communicate with > > > each other. But the agreement happens outside NFSv4 protocol itself. I > > > understand this is different from the public internet where all you need > > > is an IP address to communicate. But this is how MAC systems are used, I > > > believe. > > > > > > > I'm not sure if this conflicts with what you are saying, but the DOI > > should merely identify the (externally) agreed-upon network label space > > for the data to be shared between the communicating systems. That label > > space shouldn't need to be identical to the native/host label spaces of > > any of the individual systems; they just need to have a way of mapping > > between their host label spaces and the network label space identified > > by the DOI in a manner that preserves their security goals. The two > > systems shouldn't necessarily have to share a label encodings file or > > security policy configuration in order to communicate using a given DOI. > > > > > > As Casey and others pointed out, a lot more information about a > communicating peer is needed in order to be able to translate a label > and other security attributes. Yes, but the DOI is all that NFSv4 needs to convey in order to identify that (external) information (i.e. the DOI is the key/identifier by which the receiving system looks up the right set of translation/mapping functions for dealing with the network label space associated with the DOI, where the translation/mapping functions are configured via information established OOB to NFSv4 itself). Defining precisely how that external information gets populated is IMHO out of scope for NFSv4. > People have tried this in 90's. Apparently the solution is no longer > in use today. Maybe we can do something better 15 years later. The > first step is to figure out how much information is needed and then > look into how to get this info across securely. GSS_SEC may be able to > help us. To make NFSv4 work, only TCP is needed. So peer information > is needed per session vs. per packet, I believe. Evidently, there is > more work to do in figuring this all out. > > A process related question: Should we move the "design" related > discussion to a smaller alias? I assume most people don't care about > the details and prefer not see this in their email inbox. I set up a > mail alias, doi-discuss@opensolaris.org, a few months ago for a > similar discussion. If people think that's a good way to go, I can > provide more info. Seems like it just becomes one more list that people have to follow to get the whole picture for labeled NFS. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.