[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Thu, Apr 02, 2009 at 06:35:50PM -0400, Paul Moore wrote: > 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+ seems reasonable. Right. Once again we have a disconnect on what is meant by "label encoding" -- only this time I'd adopted Jarret's use of the term for what Solaris TX calls label encodings and confused you (Jarret had confused me earlier). > > 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. What Jarret means by label encoding is "the mappings of human readable labels to bits on the wire" not just "the generic mapping of internal MLS labels to bits on the wire" (which CALIPSO does provide, for example). > > 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" :) These aren't options -- these two go together. > > b) ensuring that clients and servers agree on a DOI's policy. > > As you point out, this seems much more reasonable of a goal. For how else do you get a heterogeneous network to agree on a DOI's policy if not by having a generic way to represent that policy? The alternative is to show that two descriptions of the same policy but in different languages are equivalent, and that strikes me as mostly equivalent to having a common language -- but a common language would surely be easier to work with. > > 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. Sure.
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
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 --
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Tue, Mar 31, 2009 at 08:33:07PM -0700, Jarrett Lu wrote:
> Nicolas Williams wrote:
> >On Mon, Mar 30, 2009 at 10:59:15PM -0700, Jarrett Lu wrote:
> >
> >>That's certainly one option. We can say DOI + an opaque field is what we
> >>will add to NFSv4 protocol. Use the information as you see fit. Going
> >>
> >
> >That's what David's I-D and what my RPCSEC_GSSv3 I-D both say now.
> >
>
> If we stop here, we don't have much of an interoperability story. I
I don't agree. We'd have the same interop story everyone has today
w.r.t. labeling: synchronization of policies is an out-of-band, manual
(automatable) task; no standard protocol nor policy description
language is specified.
Note: I'm not saying that I don't want us to do better. Rather, I'm
saying that we should consider whether to: a) proceed as now, b) also
separately and independently solve the policy agreement issues, c) make
the labeled NFSv4 work dependent on a solution to the policy agreement
issues.
I'm in favor of (a) and (b), but if we can reach consensus on a sketch
of a policy agreement solution, then I'd be willing to go for (c).
I.e., we should be realistic about what we can accomplish.
> >Signature of security policy is certainly an interesting idea! But it
> >does require defining a standard security policy description syntax --
> >that's work that I think is well outside what this WG should be working
> >on. (Also, we'll need hash function agility.)
> >
> >Therefore I think the NFSv4 community should stop at either
> >
>
> I'm in general agreement with you on this. I am not sure to what extent
> the extensibility stuff makes sense, e.g. how much may be enough? I
> guess we need to study more use scenarios. I suspect TE systems may have
> more challenges in this area, just because security policies on TE
> systems tend to be more flexible. For example, how many things are
> critical in order to translate label correctly, OS version, vendor,
> label parser, security policy file? How likely DTE systems are
> configured with exact same policy files? Does it make sense that a
> (harmless) update to security policy file causes label translation
> failures from that point on?
I've re-thought this a bit. I think we need the policy agreement parts
to be:
- provided by authentication mechanisms where possible (PKIX cert
extensions, Kerberos V authz-data, SAML assertions, ...)
- exchanged by the client and server via a new operation
The label should remain {DOI #, octet string}. Clients and servers that
can reach policy agreement via out-of-band mechanisms will need no
authentication mechanism extensions, nor any NFSv4 policy agreement
operations. Other clients and servers would use whatever policy
agreement mechanism is available to them, preferably authentication
mechanism extensions.
Policy agreement should consist of a sequence of {DOI #, policy encoding
type, hash function algorithm, hash of policy}. If a client and server
have one common policy for one or more DOIs then they can use those
DOIs. For all DOIs they don't agree on they'd fail to move bits (or
whatever is the preferred outcome).
> >[comments about where to do what work elided]
>
> No disagreement here either. At the end of this scoping exercise, we'll
> hopefully know how big a bite we can chew. I believe the DOI + opaque
> field may be useful to identical or compatible system under same
> administrative control. To push David's draft forward, I believe we
> still need to understand more about how different systems may use the
> opaque field and decide if it makes sense to propose extensibility
> fields for future use.
Agreed.
Nico
--
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Mon, Mar 30, 2009 at 08:07:02PM -0700, Casey Schaufler wrote: > Not to throw a puppy in the gears, but sophisticated handshaking and > negotiation protocols are not the answer. We had TSIG session management > for doing that and it is just not enough. How would you negotiate the > differences between two SELinux policies? You don't. You either establish that they are the same (or that one or both peers are translating to a common policy) or that they are not. In the latter case you fail to communicate further. It seems quite reasonable to me to have a single policy for a site -- that seems doable for MLS, but for DTE it's more likely that there will be OS-specific parts of a site policy, and the potential need to map between existing OS-specific policies and something else seems daunting, at least at first glance, but I'm an optimist, so I think it must be doable :) Nico --
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Mon, Mar 30, 2009 at 10:59:15PM -0700, Jarrett Lu wrote:
> That's certainly one option. We can say DOI + an opaque field is what we
> will add to NFSv4 protocol. Use the information as you see fit. Going
That's what David's I-D and what my RPCSEC_GSSv3 I-D both say now.
It's also what CALIPSO does (except that the label must be MLS and the
bits on the wire are defined, though the actual sentivity levels and
compartment naming and mapping to bits is not).
> this route, we basically punt on the label interpretation / translation
> problem. I believe this simple DOI + opaque attribute does add value as
> it provides an potentially easier way for compatible systems to
> communicate label attributes on file objects. I was trying to explore
> whether it makes sense to include other information (e.g. OS version,
> signature of security policy or label encoding files) to make handling
> of label interpretation and translation easier.
Signature of security policy is certainly an interesting idea! But it
does require defining a standard security policy description syntax --
that's work that I think is well outside what this WG should be working
on. (Also, we'll need hash function agility.)
Therefore I think the NFSv4 community should stop at either
- {DOI #, opaque label, hash function name, hash-of-policy}
(which means blocking on a standards-track labeled policy document)
or, more likely,
- {DOI #, opaque label, [extensibility field for future hash function
name / hash-of-policy]}.
The latter seems better to me because {DOI #, opaque label} is the easy
way forward for this WG, but we'd make room for a future hash-of-policy.
I think the security area of the IETF should explore Kerberos V
authz-data and PKIX certificate extensions to ensure DOI label encoding
synchronization (whether based on my sketch or some other approach) as
well as a common labeled security policy syntax covering MLS and DTE.
I know, where each set of documents gets done is a subtle distinction
when it might well be the same people doing all of them. But it's an
important distinction here.
Also, it's possible that some of this work will be done in the form of
individual submission I-Ds all the way if it doesn't naturally fit any
WG and we don't have enough work to justify spinning up a new WG. But
we'd still seek review in the appropriate WGs (NFSv4 WG for NFS work,
KRB-WG for Kerberos work, PKIX WG for PKIX work, SAAG for labeled
security policy description).
(Between CALIPSO and NFSv4 and all the other potential work mentioned
above we might well have enough work for a new WG. But I think we
should proceed as though we don't, for now.)
> Continuing on these lists is fine with me. People on these lists
> probably have high tolerance on postings that don't care about.
It sure seems that way so far :)
Nico
--
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Mon, Mar 30, 2009 at 03:01:21PM -0500, Nicolas Williams wrote: > I believe that certificate extensions and Kerberos V authorization-data > could be used to ensure that the client and server both know the correct > "label encodings" for their shared DOIs. Of course, this does nothing for deployments that don't use PKIX or Kerberos V. We can do something like this for all trusted third-party distributed authentication systems. But for simple pre-shared key (PSK) and simpler schemes (e.g., AUTH_SYS) there's nothing we can do: the client and server will have to agree on a DOI and label encodings a priori.
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Mon, Mar 30, 2009 at 11:30:25AM -0700, Jarrett Lu wrote:
> On 03/30/09 10:37, Stephen Smalley wrote:
> >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. [...]
Right now that's the best we can do, and CALIPSO does nothing to improve
this situation.
> 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. 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.
I believe that certificate extensions and Kerberos V authorization-data
could be used to ensure that the client and server both know the correct
"label encodings" for their shared DOIs.
To specify such a thing would be easy: allocate cert ext OID (for PKIX
certs) and authz-data ID (for Kebreros V) and specify the contents of
the extension, which could be the DER encoding of:
DOI-SPEC ::= SEQUENCE {
doi INTEGER (0..MAX),
label-encodings-uri UTF8STRING -- contraint: MUST be a URI
}
DOI-SPECS ::= SEQUENCE SIZE (1..MAX) OF DOI-SPEC;
I.e., a sequence of {DOI number, label encodings URI}.
Then define the format of the document referenced by the label encodings
URI. That format should cover MLS and DTE DOI types.
Nico
--
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Fri, Mar 27, 2009 at 11:56:41AM -0700, Jarrett Lu wrote: > 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". Well, you could use a PKIX certificate extension, or a Kebreros V ticket authorization-data and ticket extension to point to the actual DOI rules. But the simplest thing, given that most nodes will participate in a single DOI, is to configure this when the node joins the network (when it gets whatever credentials it needs). In practice this is exactly what happens -- out of band delivery of what Solaris TX calls "label encodings." > 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. BTW, you're using the Solaris TX meaning of "label encoding" but CALIPSO uses the term "encoding" in a very different way (or two: one in relation to how to represent releasability, and the other for actual bits on the wire). We should be careful to use terminology that we all understand. What you've been calling "label encoding" CALIPSO calls, I think, "a particular set of policies which define the Sensitivity Levels and Compartments present within the DOI, and by inference, to the "real world" (e.g. used on paper documents) equivalent labels" -- very wordy, that! > 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. I agree. I believe that negotiation of the "particular set of policies which..." is something that belongs in the authentication facilities, or else out of band -- either way that is completely outside the scope of this document (and even the RPCSEC_GSSv3 document). > CALIPSO spec has considerations in how routers can support DOI and MLS > labels. I don't believe that affects or harms NFSv4 in anyway, as > routers won't look at NFSv4 stuff. Indeed. What CALIPSO does though, is require that end-points select packet labels that dominate the labels of the data being sent. Nico --
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
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.
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Thu, 2009-02-12 at 14:11 -0600, Nicolas Williams wrote: > On Thu, Feb 12, 2009 at 03:00:51PM -0500, David P. Quigley wrote: > > We also explored a callback for label change notification. I think we > > even have the code lying around for the prototype. It worked but Trond > > expressed some concern with how well it would scale. The issue Trond > > raised is what happens if you relabel an entire file system from under a > > set of NFSv4 clients? I'm not sure how much of a concern this will be > > Surely it would scale no better and no worse than open file delegation... > > > since 1) File relabeling is supposed to be rare and 2) clients will > > probably have a small subset of files open. In the event that you do > > Reclassification of data is supposed to be rare, though that may vary a > lot by environment. The number of files that may be kept open provides > a natural limit to how many relabel callbacks will be needed. (A client > could OPEN every file at limit cost to itself hoping to overwhelm a > server, but that's a separate issue.) > > > need to relabel the entire file system on the server it might be a good > > idea from an administrative perspective to have your clients remount the > > NFS shares and flush whatever caches they have. > > Well, there's no callback to tell clients to flush all writes and > remount (or recover). You could simulate a server reboot and force > recovery though. > > Nico So can anyone see of another use for providing a call back that would tell a client to flush it's cached changes back to the server and start a recovery? It could be a potential solution to large scale relabeling on the server but I hesitate to propose it unless it has more than just that application. Also aren't callbacks done out of band and if a callback channel can't be established the functionality is just dropped? Dave
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Tue, Feb 17, 2009 at 11:50:50AM -0500, David P. Quigley wrote: > So can anyone see of another use for providing a call back that would > tell a client to flush it's cached changes back to the server and start > a recovery? It could be a potential solution to large scale relabeling > on the server but I hesitate to propose it unless it has more than just > that application. Also aren't callbacks done out of band and if a > callback channel can't be established the functionality is just dropped? I don't think that timely revocation, extending to cached data on clients, is a problem that we need to address for labeling. It's a problem in general and one that most users and implementors probably don't care that much about. Timely revocation can always be addressed separately if it becomes sufficiently desirable. IMO: leave it out of scope. Nico --
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Thu, 2009-02-12 at 09:36 -0600, Nicolas Williams wrote: > On Thu, Feb 12, 2009 at 12:07:31PM +1100, James Morris wrote: > > On Wed, 11 Feb 2009, David P. Quigley wrote: > > > > > sort of open file handle revocation support. In the past people have > > > suggested building the client's idea of the label into either the > > > stateid or some other form of cookie that can be verified by the server. > > > We explored doing this in the form of an NFSv4 op and while that worked > > > we are trying to shy away from adding new operations if we can help it. > > The file handle should suffice. The server can check if the label has > changed and then return an error. If need be we could even use volatile > FHs for this (with the FH being somewhat like a capability). > > > What's wrong with adding new operations? > > In this case a new operation won't help since the server may want to > perform revocation as early as possible, and waiting for a client to use > a specific operation is not a good way to achieve that. If you meant a > callback operation, sure, but the server needs to know what clients are > caching open file data and metadata, and right now the server only knows > about that when clients get delegations. It might be possible to add a > callback operation to indicate that access must be re-evaluated but > without recalling a delegation. > > Nico We also explored a callback for label change notification. I think we even have the code lying around for the prototype. It worked but Trond expressed some concern with how well it would scale. The issue Trond raised is what happens if you relabel an entire file system from under a set of NFSv4 clients? I'm not sure how much of a concern this will be since 1) File relabeling is supposed to be rare and 2) clients will probably have a small subset of files open. In the event that you do need to relabel the entire file system on the server it might be a good idea from an administrative perspective to have your clients remount the NFS shares and flush whatever caches they have. Dave
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Thu, Feb 12, 2009 at 03:00:51PM -0500, David P. Quigley wrote: > We also explored a callback for label change notification. I think we > even have the code lying around for the prototype. It worked but Trond > expressed some concern with how well it would scale. The issue Trond > raised is what happens if you relabel an entire file system from under a > set of NFSv4 clients? I'm not sure how much of a concern this will be Surely it would scale no better and no worse than open file delegation... > since 1) File relabeling is supposed to be rare and 2) clients will > probably have a small subset of files open. In the event that you do Reclassification of data is supposed to be rare, though that may vary a lot by environment. The number of files that may be kept open provides a natural limit to how many relabel callbacks will be needed. (A client could OPEN every file at limit cost to itself hoping to overwhelm a server, but that's a separate issue.) > need to relabel the entire file system on the server it might be a good > idea from an administrative perspective to have your clients remount the > NFS shares and flush whatever caches they have. Well, there's no callback to tell clients to flush all writes and remount (or recover). You could simulate a server reboot and force recovery though. Nico --
[nfs-discuss] [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
On Thu, Feb 12, 2009 at 12:07:31PM +1100, James Morris wrote: > On Wed, 11 Feb 2009, David P. Quigley wrote: > > > sort of open file handle revocation support. In the past people have > > suggested building the client's idea of the label into either the > > stateid or some other form of cookie that can be verified by the server. > > We explored doing this in the form of an NFSv4 op and while that worked > > we are trying to shy away from adding new operations if we can help it. The file handle should suffice. The server can check if the label has changed and then return an error. If need be we could even use volatile FHs for this (with the FH being somewhat like a capability). > What's wrong with adding new operations? In this case a new operation won't help since the server may want to perform revocation as early as possible, and waiting for a client to use a specific operation is not a good way to achieve that. If you meant a callback operation, sure, but the server needs to know what clients are caching open file data and metadata, and right now the server only knows about that when clients get delegations. It might be possible to add a callback operation to indicate that access must be re-evaluated but without recalling a delegation. Nico --
