[nfs-discuss] [Labeled-nfs] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Tue, Apr 07, 2009 at 08:02:50PM -0700, Casey Schaufler wrote: > Wow. > > Before I go too far, how familiar are you with MLS, SELinux, or Smack? I'm familiar with Solaris TX (which is MLS). I'm also familiar with the OpenSolaris community that is trying to extend the TX model to include DTE. I don't know much at all about SELinux or Smack. I think common security policies for MLS are within reach. DTE... not so much. Some subsets of specific DTE policies, probably on a per-application basis, should be. > All three provide general security policy models (Opinions vary on MLS) > but none would lend themselves as a "generic" model. MLS is strictly > oriented toward sensitivity, SELinux depends on the programs installed > on the machine, and Smack uses no syntax in its labels at all. An > interoperable encoding of policies might be possible for very limited > policies. I suggest that mapping any other policy to the SELinux > reference policy is beyond the state of the art, and I welcome an > informed argument that proves me wrong. Two peers negotiating a IIUC it should be possible to generate SELinux policies from generic ones, but not the reverse. If so then that provides a path to interoperable deployment, though it would mean sacrificing some flexibility. Can you clarify my understanding? > policy subset? How does that help? Regarding the notion that the issue > of label equivalences is "least critical", I don't see how you can > claim to have successfully addressed any of the other bullet items > without it. Why send data at some label to a peer who doesn't understand what that label is? As for label equivalencies I was referring to the example cited earlier of multiple agencies with different MLS policies needing to communicate. To clarify: by "less critical" I meant that we could solve the equivalency problem later (provided we don't paint ourselves into any corners). > You're busy stocking the nursery and you haven't kissed the girl yet. Thanks. > If the information from the client is meaningless to the server the > server can not use it to make an access control decision. Same goes > the other way. With Smack I can assert that the label space for the Therein lies the interop problem. Will SELinux and Solaris TX interop with the labeled NFSv4 protocol we're working on? Evidently: not w/o policy agreement (that was Jarret's point, which kick-started this thread on the NFSv4 WG list). > client and server are the same and that it's OK if they use the labels > passed around even if their rule sets differ. I know a good number of > people who would find such an assertion dangerous, maybe even > criminal. Label representations are meaningless without the policy So you're saying that a) "a good number of people" think a solution is needed that allows the client and server to each know with certainty that the other will understand their labels, b) you're among those people (?), but c) no solution is feasible. Correct? So close up shop, forget interop? Or did I misunderstand you? What is the message that you're imparting here? I get the impression that it's "you can't solve this problem" and "I know what I'm doing" (and "you don't") but you're not telling us what it is that is. Is what you really mean "forget labeled protocol interop"? Please clarify. > behind them and mapping policies is hard enough that you could probably > get a PHD from a reputable institution by measuring just how hard it > is. I'm not interested in a PhD. I'm interested in solutions. SPIF is evidence that it's been tried. But I know little about how successful SPIF has been. Nico --
[nfs-discuss] [Labeled-nfs] [saag] Common labeled security (comment on CALIPSO, labeled NFSv4)
On Mon, Apr 06, 2009 at 08:03:57PM -0700, Casey Schaufler wrote: > I don't think so. Two SELinux machines will most likely have different > policies even if they installed from the same media on similar hardware > with similar configurations. If there's any reason for the NFS server > to know anything about the client that impacts policy enforcement the > server has to know enough to make that judgment correctly. If the server > can ignore the client's policy there is no need to send any information. > If the server can't ignore the client's policy it needs to be able to > reconcile the local policy to the remote policy in order to enforce > reasonable policy. We can have label-aware servers with non-label-aware protocols. But that's too constraining: it means clients have to be at a single label or otherwise communicate labels by convention (e.g., data location). It also means that interfaces to labeling will be proprietary. We can have non-label-aware server, non-label-aware protocols, and label aware clients, trusting the clients to enforce a common policy. But this too is too constraining: a) it forces one to associate labels with document _location_, b) it forces one to trust the clients too much. We need multi-level clients, since many users will have a range of clearances, not just a single one (and they need a trusted desktop). Given the above then we need label-aware servers and label-aware protocols so as to support for multi-level clients (with clients trusted to within a range of labels associated with clients' and users' authenticated identities and other authorization information). Even before putting labels on the wire we'd have a security policy management issue since storage can span many servers. With labels appearing on the wire (in IP headers, in application protocols, in PKIX certificate extensions and Kerberos V authorization- data, ...) we simply cannot avoid the need to express common security policies. We also cannot force everything and everyone to operate in a single DOI. And we cannot avoid the need to classify the security policies themselves, including varying classification for different subsets of the policies. IMO that means that we need something like SPIF, including: - a generic security policy data model/syntax - an interoperable encoding of security policies - a method by which two peers can detect and agree that they know a given common subset of a common security policy - label equivalencies The last item is the least critical -- we can deal with that later. > So you're back to mapping policies. You have to map policies if you > want either side to do all the work. The mechanisms used to map Yes. > labels used by different installations of the same 1990's MLS systems > will not work for SELinux systems installed for different purposes by > disjoint agencies. That's fine, unless you want them to interop and you can establish equivalencies. And provided SELinux can deal -- but that's less important because if it's just a small matter of programming (i.e., we have specs to code to or know what to code that we can write specs from) then it's just a matter of time. So we need to know whether solutions in this space are technically feasible. I believe they are. (We also need to know whether they are politically feasible, but here I think we'll find that they are politically required :) > I'm not trying to stop progress here. I am simply trying to point out > that choosing a mechanism to implement a facility that won't work in > the end is pretty pointless. Sure the old schemes worked in certain No one is knowingly proposing a mechanism that won't work so far as I can tell. > cases in the olden days. The question is will they work now, and the > answer is obviously "no".
