Subject: Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

From: Jarrett Lu <[email-masked]>
Date: Wed, 01 Apr 2009 00:46:58 -0700

On 3/31/2009 7:47 AM, Paul Moore wrote:
> On Monday 30 March 2009 11:07:02 pm Casey Schaufler wrote:
>    
>> Jarrett Lu wrote:
>>      
>>> 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.
>>>        
>> 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?
>>      
>
> I'm with Casey, I don't think it is worth spending a whole lot of time right
> now finding out how to pass information across the network in a secure manner.
> There are plenty of ways of to do that which are well established,
> interoperable and generally regarded as "secure".
>    

I'm not reinventing another secure way to pass information. I thought 
kerberos gss api may be a good candidate. I also agree that 
sophisticated handshaking negotiation protocol or complicated security 
attribute mapping between various systems is not the way to go.

>  From my point of view the real issue is how do we translate/resolve security
> labels defined by DOI X to an internal, security model/policy specific label?
> Some have mentioned a mechanism which would serve up label encoding data
> whenever a new system joined the network; unfortunately, I believe this only
> works when you know the security policy of the system before hand (or can
> restrict the security policy, after all a TSOL label encodings file will do
> nothing for SELinux and/or Smack).  While I think it is reasonable to assume a
> limited number of on-the-wire label encodings and DOIs I think it would be a
> mistake to assume a limited number of security models and or policies.
>    

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. 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.

> Ultimately I believe that the required label translation information (wire/DOI
> label to internal and the other way around) is going to need to be bundled
> with the system's security policy and distributed as a single "package".
> Granted this does require prior knowledge of the DOIs in use but I believe
> this is a much easier requirement than the opposite.  From a practical point
> of view this isn't too far removed from the notion of sending sending label
> encoding data upon joining the network, the big difference is that we are
> sending both security policy and label encoding/DOI-translation data at the
> same time (in the TSOL case I suspect this would just be the label encoding
> data, which may mean the original poster had this in mind).
>
>    

Depending how different the systems are, the "package" content will be 
different. 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, and probably outside the scope 
of labeled NFSv4 enhancement. So realistically, I think the DOI + opaque 
label is useful between very compatible systems. Given that limitation, 
may be the "package" is small enough and can be passed in RPC layer 
during authentication so that MLS can share files with like MLS systems, 
and same is true for DTE, fmac, smack, ....

Jarrett

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 01 Apr 2009 01:09:16 -0700

On 3/31/2009 11:58 PM, James Morris wrote:
> On Tue, 31 Mar 2009, Jarrett Lu wrote:
>
>    
>> 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?
>>      
>
> With SELinux systems, policies do not need to be identical to be
> considered part of the same DOI.  Generally, labels need to remain
> semantically equivalent (i.e. mean the same thing on each system), and the
> policies need to be managed within the same administrative boundary.
> Systems may restrict which labels they'll interpret from remote systems
> (similar to root_squash).
>
>    

Understood. My point is that a signature on a policy file may not always 
be the right tool to determine whether label translation should be done. 
When policies are different on two systems, how does one system know 
labels or types are semantically equivalent or not? Are you also saying 
that DOI is tied to administrative boundary, and the fact that systems 
using the same DOI implies the label and type definitions in each policy 
are always semantically equivalent?

Jarrett

> - James

---

From: James Morris <[email-masked]>
Date: Wed, 1 Apr 2009 20:49:25 +1100 (EST)

On Wed, 1 Apr 2009, Jarrett Lu wrote:

> Understood. My point is that a signature on a policy file may not always be
> the right tool to determine whether label translation should be done. When
> policies are different on two systems, how does one system know labels or
> types are semantically equivalent or not?

This should be determined via the DOI.

> Are you also saying that DOI is tied
> to administrative boundary, and the fact that systems using the same DOI
> implies the label and type definitions in each policy are always semantically
> equivalent?

For DOIs designed to function like this, yes.  i.e. it's not a property 
inherent to DOIs, but of how they're administered.

- James
-- 
James Morris
<[email-masked]>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Apr 2009 12:50:12 -0500

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'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
--

---

From: Paul Moore <[email-masked]>
Date: Tue, 31 Mar 2009 10:47:20 -0400

-- 
paul moore
linux @ hp

---

From: Paul Moore <[email-masked]>
Date: Wed, 1 Apr 2009 12:46:33 -0400

On Wednesday 01 April 2009 03:46:58 am Jarrett Lu wrote:
> > I'm with Casey, I don't think it is worth spending a whole lot of time
> > right now finding out how to pass information across the network in a
> > secure manner. There are plenty of ways of to do that which are well
> > established, interoperable and generally regarded as "secure".
>

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.

> >  From my point of view the real issue is how do we translate/resolve
> > security labels defined by DOI X to an internal, security model/policy
> > specific label? Some have mentioned a mechanism which would serve up
> > label encoding data whenever a new system joined the network;
> > unfortunately, I believe this only works when you know the security
> > policy of the system before hand (or can restrict the security policy,
> > after all a TSOL label encodings file will do nothing for SELinux and/or
> > Smack).  While I think it is reasonable to assume a limited number of
> > on-the-wire label encodings and DOIs I think it would be a mistake to
> > assume a limited number of security models and or policies.
>
> 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.

> The challenge of interpreting and translating labels is that one system

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.

> > Ultimately I believe that the required label translation information
> > (wire/DOI label to internal and the other way around) is going to need to
> > be bundled with the system's security policy and distributed as a single
> > "package". Granted this does require prior knowledge of the DOIs in use
> > but I believe this is a much easier requirement than the opposite.  From
> > a practical point of view this isn't too far removed from the notion of
> > sending sending label encoding data upon joining the network, the big
> > difference is that we are sending both security policy and label
> > encoding/DOI-translation data at the same time (in the TSOL case I
> > suspect this would just be the label encoding data, which may mean the
> > original poster had this in mind).
>
> different.

Yep, that is the point; squares hole need square pegs, round holes need round 
pegs.

> Assuming we can assemble all the information required to do
> systems seem inefficient, non-scalable ...

Honestly I don't see it as being that far removed from many of the current 
solutions that ship "security policy" to individual systems through the 
network/enterprise.  Also look at some of the NAC stuff that is being used 
these days, how is a security policy/translation "package" all that different 
from an anti-virus update or a set of os/application patches?

It is a solvable problem, or at least one that users have shown a willingness 
to tolerate.

> ... 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 :)

> So realistically, I think the DOI + opaque label is useful between very
> compatible systems.

Of course.  I agree there are a lot of things you can do with a DOI + opaque 
label, especially if you are only concerned about end-to-end security issues 
which I believe is the case for labeled NFS.

> Given that limitation, may be the "package" is small enough and can be
> passed in RPC layer during authentication so that MLS can share files with
> like MLS systems, and same is true for DTE, fmac, smack, ....

Well, I think all that the opaque label buys you is the ability to limit who 
you share the security policy/translation "package" with, as those systems 
that participate in the labeled communication (be it NFS, generic IP or some 
other random service) still need to worry about label translation and security 
policy differences if they want to enforce policy locally.

-- 
paul moore
linux @ hp

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 10:24:24 -0500

> 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).

> used across multiple applications and not just NFS.

+1

> problem space is much smaller and likely to have less churn over time.

+1

> > 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.

> 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
--

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 02 Apr 2009 16:43:17 -0700

> (automatable) task; no standard protocol nor policy description

I don't mean to dwell on this. Requiring either systems being identical 
or relying on OOB information to know whether the opaque field can be 
used sounds weak on interoperability.  ;-)

I agree with you on rest of your comments. I still think more detailed 
study on different use cases are needed to understand whether the 
proposed solutions are suitable, sufficient, etc..

Jarrett

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 02 Apr 2009 18:21:08 -0700

> On Wednesday 01 April 2009 03:46:58 am Jarrett Lu wrote:
[ ... ]
> problem space is much smaller and likely to have less churn over time.

This comes back to semantics of DOI. So far, I heard two slightly 
different versions:
(1) DOI is a key to a set of label parsing functions. Knowing the DOI 
value implies the parser on the system knows how to parse the octet 
string in opaque field. It says nothing about whether a peer's label can 
be correctly interpreted. I believe Daivd's draft uses this definition. 
(2) In addition to being able to parse the opaque field, DOI also 
implies communicating systems have consistent label policy and encoding. 
Systems with inconsistent policies are not supposed to use same DOI. 
This definition is closer to the CALIPSO DOI, and is how MLS systems use 
DOI today.

While (1) is easier to specify on the wire, I am not clear on what it 
takes to use it safely even when OOB methods are used. Since this 
definition doesn't say who should use this DOI and who is not supposed 
to, what happens when a node, which has not consented to the agreement 
over the OOB method, uses the same DOI and octet string format but with 
inconsistent label policy? (2) has an easier usage model, IMO. But it's 
harder to define a "pre-existing" DOI., e.g.  define DOI X to mean 
vendor ABC, OS version 1.0, label policy 2.0, label parser version 3.0, 
etc., and store that in some kind of registry. I think Nico's "URL 
during authentication" idea is interesting.

> It is a solvable problem, or at least one that users have shown a willingness 

I was thinking how to do that within a protocol enhancement.

> policy differences if they want to enforce policy locally.

I am still trying to understand what is needed to make safe sharing 
possible. BTW, are you implying that it's always necessary to do one 
label translation, e.g. from on-the-wire format to a native label format?

Jarrett

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 23:42:10 -0500

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:
> > > 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.
> >
> 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.

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).

> 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).

> > 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.

> 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.

---

From: Paul Moore <[email-masked]>
Date: Thu, 2 Apr 2009 18:35:50 -0400

> 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.

> > 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
> > :)
>

-- 
paul moore
linux @ hp

---

From: Joy Latten <[email-masked]>
Date: Fri, 03 Apr 2009 13:08:43 -0500

> six-of-one/half-dozen-of-the-other discussion right now.

I am just getting to read this thread. I find it interesting because the
labeled ipsec draft expresses DOI + opaque string in similar manner as
the labeled nfsv4 draft. 

Upon reading the thread, I agree with you, define a security policy and 
label format in the DOI and leave it up to implementation to handle
internalization.

I had always assumed the DOI would be handled by IANA and when a request
was made for a new DOI number, a definition would be included. 
For example, DOI #5: mapping between MAC implementation A version xx,
label policy B AND MAC implementation G version xx, label policy R.
Or maybe something like, DOI #6: SElinux version XX, using MCS.

The sys admin would determine based on local MAC, mappings, etc...,
which DOI to use/communicate. 

This perhaps sounds somewhat primitive, but I am still processing all
the info communicated in the thread. :-)

regards,
Joy

---

From: Paul Moore <[email-masked]>
Date: Tue, 7 Apr 2009 17:30:53 -0400

On Thursday 02 April 2009 09:21:08 pm Jarrett Lu wrote:
> > Of course.  I agree there are a lot of things you can do with a DOI +
> > opaque label, especially if you are only concerned about end-to-end
> > security issues which I believe is the case for labeled NFS.
> >
> >> passed in RPC layer during authentication so that MLS can share files
> >> with like MLS systems, and same is true for DTE, fmac, smack, ....
> >
> > Well, I think all that the opaque label buys you is the ability to limit
> > who you share the security policy/translation "package" with, as those
> > systems that participate in the labeled communication (be it NFS, generic
> > IP or some other random service) still need to worry about label
> > translation and security policy differences if they want to enforce
> > policy locally.
>

[Sorry for the delayed response.]

As I said earlier I think the easiest way forward is to design systems that 
can interoperate with established DOI definitions and not worry about what 
other peer systems are using for a security mechanism.  In some cases that 
will require translations from a native label format to a wire format and back 
to a label format; in some cases it may result in no translations at all.  It 
all depends on the individual systems and the DOI.

-- 
paul moore
linux @ hp