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

From: "David P. Quigley" <[email-masked]>
Date: Thu, 12 Mar 2009 12:08:28 -0400

So I am addressing the comments from the mailing list in the Labeled
NFSv4 draft and currently I'm working on Peter's concerns about the
delegation section. Reading through the NFSv4.1-29 version of the
specification it seems that section 10.2 gives all the reasons why this
should be done. Would it be wise to repeat some of the reasons in the
Labeled NFSv4 document or is it fine for me to reference section 10.2 of
the NFSv4.1 spec? 

Dave

---

From: Peter Staubach <[email-masked]>
Date: Thu, 12 Mar 2009 13:20:27 -0400

> Labeled NFSv4 document or is it fine for me to reference section 10.2 of

My expectation would be that the goal would be to be part of the
NFSv4.2 specification, so I would think that referencing the section
of the NFSv4.1 specification would help the document editor.

       ps

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 25 Mar 2009 01:52:49 -0700

David P. Quigley wrote:
> Hello,
>    I have just posted a new document for the MAC labeling support work
> to the IETF website. It contains a lot of clarifying text that has been
> asked for by several people in the IETF community. I would like to ask
> that people give it a look over and provide comments if possible. I
> would prefer that discussion takes place on the NFSv4 WG mailing list
> since it shows interest in the technology which is what the WG is
> currently looking for. If you have any questions regarding the text or
> the system outlined in it email me and I'll be more than happy to help
> with any confusion. I am hoping to drum up enough interest in the work
> to request that it be added to the NFSv4 WG charter at the next IETF
> meeting. If you are interested in the work and would like to participate
> or just think that it is a worthwhile technology and would like to see
> it added to the NFSv4 standard feel free to speak up. 
>
> The information for the document which I received in the conformation
> email and a link to it can be found below.
>
> Dave Quigley
>
>
>
> http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-sec-label-00.txt
>   

Sorry about the late reply. I have the following comments on the draft.

1. section 3, a nit. It's probably better to number your requirements as 
R1, R2, ... R4. When you refer to them later in your draft, I don't need 
to count every time.

2. section 3, the semantics of DOI in your draft is different from the 
one in the CALIPSO draft. Traditionally, DOI in MLS context refers to 
(at least in part) administrative control and deployment of the MLS 
systems. For example, DOD may own a block of DOIs. Systems using that 
block of DOIs are permitted to communicate with on another. Label 
translations are possible among the DOIs. Systems are not permitted to 
accept data packets carrying DOI outside a known DOI range. In your 
draft, DOI is used to imply label format in the opaque field of the 
security attribute. This makes it impossible to share the CALIPSO DOI.

3. section 3, on a MAC system, every subject and object has a label as 
you stated. Different objects are labeled in different layers or 
subsystems. For example, data packets, network interface, sockets are 
labeled by IP module. I believe the draft should at least state that 
NFSv4 MAC labeling should be consistent with MAC policy on the entire 
system. Take MLS system as an example, it's considered a MAC violation 
that a file labeled SECRET goes out on a network interface labeled 
UNCLASSIFIED. It's important that NFS implements this correctly so that 
MAC is enforced correctly on the system. It's difficult for IP module to 
inspect whether NFS has put the correct label in IP's payload.

4. section 4, the draft should probably state how a MAC client knows 
whether the server is MAC aware or not, via configuration? Also how a 
MAC aware server knows whether the client is MAC aware, via 
configuration or based on the fact that security attributes are present?

5. section 4, nit. "MAC aware client/server" are probably better names 
than "smart client/server".

6. section 4.1, in full mode, does reply carry a label? It appears to me 
that a client never needs to do a DOI translation. The draft should be 
more explicit on  that, IMO.

7. section 4.2.2, the phrase "this may fail based on the DAC criteria 
even if the MAC policy grants access" applies to all three modes of 
operation. It may mislead reader to believe it only applies to this mode.

8. section 4.3, what actually prevents a MAC aware server to serve a 
mixture of MAC aware and MAC unaware clients? This restriction may not 
be necessary. There are environments where both kinds of clients coexist.

9. section 5.1, while I understand what you intend to explain, your 
example is not completely correct. In B&L MLS model, a request with TOP 
SECRET security attributes can actually read SECRET or UNCLASSIFIED 
directory. It's not a MAC violation, i.e. read down is OK. The reverse 
is not permitted.

10. section 7, as stated above, you seem to use the DOI field 
differently. It appears that you want the DOI to indicate whether an 
NSFv4 server understands the label format AND knows how to interpret the 
opaque field. This implies the server has to know all the label 
definitions for all valid DOIs. For example, a server must be able to 
detect a label is undefined under a DOI although it knows the format of 
the label. This may be better solved via configuration instead of going 
through IANA. For example, if one wants his server to be able to 
translate among three labeling schemes, she/he will configure the system 
with all three label definitions, translation tables, modules containing 
appropriate label functions and utilities, etc..

Jarrett

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Mar 2009 11:33:17 -0500

> security attribute. This makes it impossible to share the CALIPSO DOI.

Before CALIPSO it's always been the case that the form of a label
depends on the DOI it is from, with a DOI being either implied by
context or explicit on the wire.

A CALIPSO DOI is, AFAICT, a DOI that imposes an MLS form on the label
(though with label encoding being protocol specific) and a security
policy registration/definition requirement.  CALIPSO also requires that
a DOI always be explicit.  CALIPSO also imposes a namespace of DOIs, and
I'm not sure that it allows any DOIs that are not CALIPSO DOIs.  CALIPSO 

In other words, any protocol that carries a {DOI ID, opaque label}
should be compatible with CALIPSO.

But an implementation that adheres to CALIPSO will not be able to use
non-CALIPSO DOIs.  Is that correct?  If so we need to ensure that a
mapping between MLS and DTE is possible, since David, IIRC, wants
support for DTE.  But as far as I can tell such a mapping is possible.

One thing I think is wrong with section 3.1 is that it talks about
translation of a label "into a form that is usable by the endpoint."
That's superfluous -- it should suffice to say that the DOI field allows
the server to know how to interpret the label if it understands the
given DOI.

> inspect whether NFS has put the correct label in IP's payload.

Agreed.

> configuration or based on the fact that security attributes are present?

A client has to know a priori somehow whether to trust a server for a
specific range of labels in some DOI.  The MAC awareness or non-
awareness of a server relates only to how the label of an object is to
be determined (MAC server: the server tells you the object's label;
non-MAC server: the object's location determines the object's label) and
how authorization is to be done (MAC server: the server does MAC and DAC
authorization; non-MAC server: the server does DAC and the clients to
MAC authorization, with the clients having to all have a consistent
configuration).

> than "smart client/server".

Agreed.

> more explicit on  that, IMO.

A client may have to do a DOI translation for reasons unknown to us, but
we should probably not even mention that.   Is that what you mean?

> be necessary. There are environments where both kinds of clients coexist.

I agree.  A MAC aware server can certainly speak to MAC-unaware clients
by coercing all processes (open owners) on the client to a single label
determined via server-side configuration.

> definitions for all valid DOIs.

Well, for all the DOIs it knows about, for what else is a "valid DOI"?

>                                 For example, a server must be able to 
> the label.

But if the server understands a given DOI then can do that.

>            This may be better solved via configuration instead of going 

It should be possible for a server to support multiple DOIs without
necessarily having to know how to translate between them.  Then you get:
processes with labels in one DOI cannot access objects with labels in
another.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 26 Mar 2009 02:25:44 -0700

> context or explicit on the wire.

CALIPSO DOI is intended for IP packets. Nodes using same DOI value 
implies that they all agree on how to interpret a MAC label. In that 
sense, it's more about label definition and encodings, less about its 
format. For example, host A and host B use a label encoding where label 
CONFIDENTIAL dominates label INTERNAL. A and B communicate using DOI 1. 
Host C and D both use a compatible label encoding. But in their label 
definition, label INTERNAL dominates label CONFIDENTIAL. C and D can 
communicate using DOI 2 without any problems. But host A is not allowed 
to communicate with host C using DOI 1, despite their label format may 
be compatible. I believe CALIPSO DOI assumes that host A and B are under 
the same administrative control. The administrative authority is 
supposed to register the DOI number with IANA for its use.

CALIPSO spec is very clear that the first thing IP checks is DOI number. 
IP drops packets if the DOI is unexpected. CALIPSO hasn't changed how 
DOI is used in that regard. Sun's trusted OS has similar behavior for a 
long time. That's DOI for IP module. It appear that labeled NFSv4 wants 
a different DOI, or different semantics of DOI. Using the example above, 
it seems to desire the following semantics:

DOI value      Opaque Security Attribute Field
---------      -------------------------------
    1          CALIPSO MLS label using label encodings shared by A, B
    2          CALIPSO MLS label using label encodings shared by C, D
    3          Redhat DTE label using security policy shared by A, B
    4          OpenSolaris FMAC DTE label using sec policy shared by C, D
    5          BSD's Biba label using security policy shared by C, D
   ....
 
In an MLS example, server host C gets a request from client host A with 
DOI = 1, requester label = CONFIDENTIAL. The client wants to write to 
file foo, which is protected by label INTERNAL under DOI 2. Server C 
validates that CONFIDENTIAL is a defined label in label encodings under 
DOI 1. It then translates the label and concludes that CONFIDENTIAL in 
DOI 1 is equivalent to INTERNAL in DOI 2, it then grants the write 
access to object foo (note in MLS, write access requires labels being 
equal).

I am having difficulty with how to manage DOIs with different 
combinations in the opaque field.

> should be compatible with CALIPSO.

Whenever a packet carries a CALIPSO label, explicit DOI is mandatory.
The DOI is for validation purpose, it doesn't say anything about how the 
node should interpret the label. The "how to" part is already agreed 
upon by the virtue of using the same DOI.

> support for DTE.  But as far as I can tell such a mapping is possible.

If labeled NFSv4 DOI is used to indicate how the opaque field should be 
interpreted, it needs its own DOI, as CALIPSO DOI isn't intended for 
that use. I don't believe this DOI should be in IANA registry. A system 
may support translation of a few MAC labels. Those systems should be 
configured to do so.

> MAC authorization, with the clients having to all have a consistent

I spoke to David about this. He is of the opinion that a MAC aware 
client should not care whether the server is MAC aware. I guess that 
means client always provides label attributes to server, and MAC unaware 
server just ignores it. But I agree with you that MAC aware clients 
should somehow know whether the server is MAC aware so that the client 
is clear on whose responsibility it is to set label of an object. It's 
also more robust to be able to detect the error case where a MAC aware 
server should set label attributes but fails to do so.

> we should probably not even mention that.   Is that what you mean?

If a client also needs to do DOI translation, the document should 
explicit about  that and say that replies from server should also carry 
DOI. That way, implementors know what kind of client they need to build 
to be compliant. Requiring client to do translation adds quite a bit of 
complexity. It's probably better not requiring that, until we know for 
sure that is needed.

> Well, for all the DOIs it knows about, for what else is a "valid DOI"?

I still haven't figured out how to use the DOI and the opaque field to 
make different MAC systems to interoperate. We still have some work to 
do to standardize that. If any combination of label format, policy, 
encondings, definition, etc. requires a different DOI, it becomes 
unmanageable quickly.

> processes with labels in one DOI cannot access objects with labels in

Yes, that's possible, and this is simpler than having to translate. I 
don't know enough use cases to know whether users keep multiple file 
systems on same server but protect them with two sets of labels.

Thanks.

Jarrett

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Mar 2009 10:09:34 -0500

Jarret,

I agree with your point about interoperability: we must impose a label
encoding.  We can leave parts of the DOI number space reserved for
as-yet-unspecified label forms and encodings -- that would satisfy my
desire for extensibility.  That's a comment I should make on CALIPSO,
that it should not impose its label structure and encoding on all DOIs,
just all DOIs in parts of the DOI number space open for registration.

Also, this does not mean that the label shouldn't be opaque in the XDR
sense.  Using opaque in the XDR sense but actually imposing a label
encoding might still be desirable (mostly for compression, but also if
we should reserve some of the DOI number space for as-yet-unspecified
label structures and encodings).

On Thu, Mar 26, 2009 at 02:25:44AM -0700, Jarrett Lu wrote:
> >>[...]

Yes, and there's a relationship to the application data.  Thus, for
example, the label used for packets carrying NFS traffic has to dominate
the labels of the files being accessed via NFS.

That means that CALIPSO has an impact beyond IP.  Specifically,
CALIPSO's imposition of structure on labels of any DOIs with DOI ID <
2^32 applies to applications as well.

> CONFIDENTIAL dominates label INTERNAL. A and B communicate using DOI 1. 

CALIPSO imposes structure on labels, not encoding (it does define an
encoding for use in IPsec though).  The structure is: DOI, sensitivity
level, compartments, releasability.  We'll need to pick an encoding.

> it seems to desire the following semantics:

David seems to want explicit support for DTE.  If we can get away with a
combination of MLS (and, maybe, privileges) to represent DTE then we can
stick exclusively to MLS and remain compliant with CALIPSO.  Given the
impact that CALIPSO has on application protocols I think we have no
choice (see above).

> DOI value      Opaque Security Attribute Field

I think that's the sort of thing that David was aiming for, yes.

> combinations in the opaque field.

I agree that it's best to have an encoding for the label than to leave
it opaque.  I want a range of unknown DOIs with opque labels for
extensibility though (see above).

> >should be compatible with CALIPSO.

I should have qualified that last statement: "any protocol that carries
a {DOI ID, opaque label} _and can use MLS exclusively_ should be
compatible with CALIPSO."

> Whenever a packet carries a CALIPSO label, explicit DOI is mandatory.

David's I-D has that.

> If labeled NFSv4 DOI is used to indicate how the opaque field should be 

In David's I-D the encoding of the label is left to each DOI.  That's
not unreasonable.  But in the face of CALIPSO we might as well specify
an actual label encoding given that CALIPSO imposes label structure.

> >>[...]

I agree with you and disagree with David then on this:

 - MAC-unaware clients must be treated as being at a single label.

 - MAC-unaware servers must either be treated as being at a single label
   or filesystem object labels must be derived from the fsid of each
   object.

   The latter is more or less the Solaris TX approach to file labeling
   in general right now, and it requires that all MAC-aware clients be
   configured the same way.  It also effectively requires that all
   clients of MAC-unaware servers be MAC-aware, which is why MAC-unaware
   servers will be difficult to use in practice.

> complexity. It's probably better not requiring that, until we know for 

The DOI should always be explicit in NFSv4.x, yes.  I think that DOI
translation will never really happen, thus we should probably chuck it.

> systems on same server but protect them with two sets of labels.

I'm thinking of a single storage infrastructure serving clients from
multiple DOIs, with each DOI kept strictly separated by server policy,
thus no two DOIs "meet."  Granted, such a thing can be implemented via
virtualization.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 26 Mar 2009 15:03:00 -0700

> just all DOIs in parts of the DOI number space open for registration.

CALIPSO spec doesn't tie a DOI with a particular label encoding. For 
example, it DOI 1000 doesn't have to mean it's CALIPSO label with this 
label encoding file. DOI 1000 could very well be used by SELinux systems 
using a particular MAC policy. CALIPSO DOI does imply that when a node 
can communicate with a DOI, it knows how to interpret the labels 
associated with the DOI. All nodes using the same DOI have agreed on 
what format and encodings to use. The agreement takes place else where, 
most likely an administrative decision. Does labeled NFSv4 aim to 
establish this agreement within the protocol itself?
> label structures and encodings).

CALIPSO spec reserves DOI value 1 - 255 for private use. If an 
organization doesn't want to do labeled communication outside its 
control, it can use a number in that range, without need to register 
with IANA.

> the labels of the files being accessed via NFS.

Typically, SECRET data/file traffic doesn't leave SECRET network. So 
labels in different layers/subsystems should match. What must not happen 
is SECRET data flowing through UNCLASSIFIED network. In other words, we 
don't want to see a request coming in from UNCLASIFFIED  interface 
asking for SECRET files.

> level, compartments, releasability.  We'll need to pick an encoding.

By label encoding, I mean how a CALIPSO label represented in a more 
basic form (e.g. hex or binary). It's usually done in a file, e.g. 
0x000300a0000 translates to SECRET and it dominates 0x0001007000. 
Security administrators control the encoding. They get to say what 
labels are valid and how valid label relate to each other on their 
systems. Given this kind of local control, I don't know how we, who 
defined protocol attributes, could pick one. The way it works is that 
they (administrators) picked one, and agreed among themselves what label 
encoding and DOI to use.

> impact that CALIPSO has on application protocols I think we have no

I used MLS as examples, but I'd expect all MAC systems will have similar 
issues, i.e. MAC aware applications should not do things which are in 
conflicts with MAC policies in other parts of the system. I think the 
"interference" of CALIPSO DOI on application protocols comes from the 
fact that labeled NFSv4 wants to reuse CALIPSO DOI for something different.

> extensibility though (see above).

The difficulty is that label interpretation is directly tied to a label 
encoding file. Different organizations have control over content of this 
file. I don't know how you structure this with a protocol attribute.

> an actual label encoding given that CALIPSO imposes label structure.

This implies there is only one way to interpret a CALIPSO label. In fact 
every organization gets to say how a CALIPSO label should be 
interpreted. I don't see how a single DOI will make it work without some 
OOB agreement among communicating entities.

Jarrett

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Mar 2009 19:11:03 -0500

> CALIPSO spec doesn't tie a DOI with a particular label encoding. For 

CALIPSO is very specific about label domination -- that means that
having any application protocol w/ labeling above IP requires that we be
able to determine whether an application-level label is dominated by a
CALIPSO label, and the rules given are MLS with Bell-LaPadula.

Perhaps that does not mean that we must adopt MLS and Bell-LaPadula at
the application layer, but it certainly seems like the easiest path,
particularly if we can also represent DTE that way.

Now, CALIPSO does not impose a label _encoding_ (layout of bits on the
_wire_) outside IP, but it does seem to impose label _structure_ outside
of IP (see above).

> establish this agreement within the protocol itself?

As I read it CALIPSO allows each DOI to determine the names and meanings
of sensitivity levels, compartments, and releasability.  It does not
allow DOIs to impose a different label structure involving things other
than those (and the DOI number itself).

What exactly is your comment re: David's I-D?  I thought it was "opaque
is bad" but now I think you're saying the opposite.  I'm confused :)

I think partly the confusion relates to the word "encoding" (see below).

> control, it can use a number in that range, without need to register 

Indeed, but it still imposes label structure on private use DOIs, at
least as far as I can tell.  Did I misread CALIPSO?

> >example, the label used for packets carrying NFS traffic has to
> >dominate the labels of the files being accessed via NFS.
> 

I think you've restated what I wrote.  I was arguing that this
requirement imposes CALIPSO's label structure (DOI, sensitivity level,
compartments and releasability) on the applications layered above IP.
Perhaps that's wrong.  This matter is one we're going to have to decide
before long.

> By label encoding, I mean how a CALIPSO label represented in a more 

Fine, but when talking about protocols with bits on the wire "encoding"
generally means "the format of the bits on the wire," so that's how I've
been using the term.

> they (administrators) picked one, and agreed among themselves what label 

CALIPSO certainly specifies an encoding for use on the wire (see setion
5.1 of draft-stjohns-sipso-11).  If CALIPSO can, so can we.  The encoding
on the file system, the translation to human readable strings, the
semantics of each sensitivity level and compartment -- these are all
things that are specific to each DOI's rules.

> fact that labeled NFSv4 wants to reuse CALIPSO DOI for something different.

David's I-D doesn't even mention CALIPSO, so I don't see how you could
think that :)

> file. I don't know how you structure this with a protocol attribute.

Then it seems to me that you have a comment to make on CALIPSO since it
imposes label structure and an encoding on the wire.

> OOB agreement among communicating entities.

No, I don't think so.  I think we're each using "encoding" to mean
something different than the other is.  I'm talking strictly about bits
on the wire, not about interpretation (beyond the basic rules imposed by
CALIPSO), and not what Solaris TX means by label encoding.

Nico
--

---

From: Stephen Smalley <[email-masked]>
Date: Fri, 27 Mar 2009 08:55:39 -0400

> particularly if we can also represent DTE that way.

You can't represent Type Enforcement via MLS/BLP; TE is strictly more
expressive than BLP, not the other way around.  It also has no inherent
notion of dominance; the access matrix is explicitly defined and may
include intransitive relationships, which are required for integrity
goals and guaranteed invocation.

-- 
Stephen Smalley
National Security Agency

---

From: Stephen Smalley <[email-masked]>
Date: Fri, 27 Mar 2009 09:22:42 -0400

> goals and guaranteed invocation.

Also, in the case of SELinux and FMAC, the security context is more than
just a domain/type; it contains all of the security attributes relevant
to the security policy model, which in the case of the example security
server includes a user identity, a role, a domain/type, and a MLS range
(optionally just a single MLS level in the degenerate case where low ==
high).  But as far as the protocols are concerned, the entire security
context is just an opaque string.

-- 
Stephen Smalley
National Security Agency

---

From: Jarrett Lu <[email-masked]>
Date: Fri, 27 Mar 2009 10:03:35 -0700

> context is just an opaque string.

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.

Jarrett

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 27 Mar 2009 12:26:32 -0500

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

---

From: Jarrett Lu <[email-masked]>
Date: Fri, 27 Mar 2009 11:56:41 -0700

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

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.

Jarrett

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 27 Mar 2009 17:04:24 -0500

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

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

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 27 Mar 2009 17:09:23 -0500

> > goals and guaranteed invocation.

I thought that MLS compartment -> DTE type.  Is that not the case?  I
realize that DTE does not have an inherent notion of dominance, but for
_documents_ (as opposed to operating system- or application-specific
files like /etc/shadow) there surely must be a way to establish
dominance, no?  That seems important to me.

> context is just an opaque string.

My RPCSEC_GSSv3 proposal allows the client to make assertions about the
local process credentials of the process on whose behalf the client is
acting.  Things like identity, group memberships, privileges, audit
context, etcetera.  (Obviously the server has to evaluate what weight to
give those assertions given the client's and the user's authenticated
identities.)

Nico
--

---

From: Glenn Faden <[email-masked]>
Date: Fri, 27 Mar 2009 22:16:38 -0700

Casey Schaufler wrote:
> Jarrett Lu wrote: 
>> the interoperability problem.
>>     
>
> It is not. Two SELinux systems of the same version of the same
> operating system may have different and incompatible policies.
> Domains with the exact same name, intended for the exact same
> purpose, may include MLS on one and MCS on the other, have
> identical on wire representation of the labels, and still not
> inter operate in any sane way. The same is true for Smack, where
> the label Fish can be treated very differently on two adjacent
> boxes. Any system that relies on opaque data is going to
> have this problem, which is why the 1980's attempt at CIPSO
> went down in flames.
>   
Casey I agree with you up to the last sentence. CIPSO was invented in 
the early 90's and is still in use today by multiple vendors. CALIPSO is 
essentially an IPv6 version of CIPSO.

I think your point is that neither CIPSO nor CALIPSO can be used to 
represent SELinux security contexts. If so, that should be obvious.

Your assertion that it is required for the client and server  to have 
the same policies and OS versions is generally true, although each 
system would be expected to refuse to deal with any types that is 
doesn't understand. The opportunity for misunderstanding seems likely. I 
have an additional concern how different systems, like SELinux and 
Solaris with FMAC will handle each other's security contexts. Even if 
their policies use the same types, roles, MLS labels, etc, the 
implementation details, like privileges vs. capabilities, will probably 
differ.
>   
>>  My opinion is that it's insufficient as it 
> Common label encoding isn't sufficient either. Consider two
> computers, one encoded for DoD labels and the other for DoE
> labels. Both use SECRET, and any attempt to translate between
> the two will undoubtedly match them up even though they are
> very different. The Mitre encoding scheme doesn't solve the
> problem either, which is evident by the fact we're still
> discussing the issue today.
>
> What will work is the real question. The only notion I've seen
> that really addresses the issue has been rejected many times
> for the simple reason that it's too hard to administer. It
> requires that each system have a map of all labels that it
> expects to see from a given peer and their corresponding local
> representations. Whoever figures out a reasonable way to go
> about doing this gets a beer from me.
>
>   
In ancient times (the 1990s), trusted systems used to try to 
interoperate using the TSIX protocol. For those who want the history 
lesson here are the SGI and Sun docs:

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/cat7/trusted_networking.z

http://docs.sun.com/app/docs/doc/816-1048/6m7gaddhs?a=view

Sun dropped support for TSIX after all the other vendors withdrew from 
the market. The TSIX implementation was a mess, but it attempted to map 
one vendor's security attributes, e.g. privileges, into its own notion, 
e.g. capabilities. Labels were sent as strings and translated into local 
formats, as well. We sort of got it to work with Digital's MLS system, 
but everybody eventually fell back to CIPSO.

--Glenn

---

From: Casey Schaufler <[email-masked]>
Date: Fri, 27 Mar 2009 20:33:17 -0700

---

From: Casey Schaufler <[email-masked]>
Date: Fri, 27 Mar 2009 22:52:04 -0700

Glenn Faden wrote:
> Casey Schaufler wrote:
>> 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.
>>>     
>>
> the early 90's 

Nope. Gary Winnegar (spelling?) had proposals out to TSIG by 1987.
That version was rejected out of hand.

> and is still in use today by multiple vendors.

The current version differs in that it is less flexible than
the original, and that is precisely aimed at IETF acceptability.

> CALIPSO is essentially an IPv6 version of CIPSO.
>

Actually, no. Either can be, provided the machines on both ends
have identical policy. The point is that you can't count on it
based on the information available.

> doesn't understand. The opportunity for misunderstanding seems likely.
> I have an additional concern how different systems, like SELinux and
> implementation details, like privileges vs. capabilities, will
> probably differ.
>>  
>>>  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
>>> context string in the opaque field. DOI + opaque field doesn't say
>>> which label encoding scheme or which security policy.
>>>       
>>

Think IPSEC designed by people who thought B2 and CMW were good ideas.

> the market. The TSIX implementation was a mess, but it attempted to
> map one vendor's security attributes, e.g. privileges, into its own
> notion, e.g. capabilities. Labels were sent as strings and translated
> into local formats, as well. We sort of got it to work with Digital's
> MLS system, but everybody eventually fell back to CIPSO.

Yup.

---

From: Jarrett Lu <[email-masked]>
Date: Mon, 30 Mar 2009 11:30:25 -0700

On 03/30/09 10:37, Stephen Smalley wrote:
> On Fri, 2009-03-27 at 11:56 -0700, Jarrett Lu wrote:
>   
>> Nicolas Williams 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.  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. 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, [email-masked], a few months ago for a similar 
discussion. If people think that's a good way to go, I can provide more 
info.

Jarrett

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 30 Mar 2009 13:35:48 -0500

On Mar 30, 2009, at 1:30 PM, Jarrett Lu wrote:
> 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, [email-masked], a few months ago for a  
> similar discussion. If people think that's a good way to go, I can  
> provide more info.

It is okay that an "off-list" discussion occur but it needs to be
in the form of a "design team".  This means that there is a
specific purpose/output and that it be run under the same
guidelines as the IETF NFSv4 WG alias (same rules of
engagement about contributions, etc.).

Also, the design team can make recommendations.  The final
decisions or choices need to occur within the working group
proper.

Spencer

---

From: Stephen Smalley <[email-masked]>
Date: Mon, 30 Mar 2009 12:51:48 -0400

> dominance, no?  That seems important to me.

No, there just needs to be a way to establish authorization.  The
internal logic for determining whether data of a given label is allowed
to transit over a network interface of a given label is policy-specific
and shouldn't be limited to the dominance relation.  It can just be
represented as a permission check on a label pair for a given object
class, and then the security policy logic can internally decide yes/no
on that permission based on any combination of the dominance relation,
the TE access matrix, or any other policy constraints.

-- 
Stephen Smalley
National Security Agency

---

From: Stephen Smalley <[email-masked]>
Date: Mon, 30 Mar 2009 13:37:14 -0400

-- 
Stephen Smalley
National Security Agency

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Mar 2009 15:01:21 -0500

On Mon, Mar 30, 2009 at 11:30:25AM -0700, Jarrett Lu wrote:
> >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.

> packet, I believe. Evidently, there is more work to do in figuring this 

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Mar 2009 15:03:42 -0500

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Mar 2009 15:05:06 -0500

> the TE access matrix, or any other policy constraints.

OK, good -- that's a local-to-end-points consideration, so we can keep
the use of DTE at the end-to-end application layer and CALIPSO at the IP
layer compatible.

---

From: Stephen Smalley <[email-masked]>
Date: Mon, 30 Mar 2009 17:14:24 -0400

On Mon, 2009-03-30 at 11:30 -0700, Jarrett Lu wrote:
> 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.
> 

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

---

From: Casey Schaufler <[email-masked]>
Date: Mon, 30 Mar 2009 20:07:02 -0700

Jarrett Lu wrote:
> ...
> Apparently the solution is no longer in use today.

You're giving us more credit than we're due. No, the problem was never
solved. Oh, we had a few "interoperability rings", where we got together
and tried talking CIPSO and SAMP to each other, but it was sort of like
going to a SciFi convention and striking up conversations in Klingon.
I believe that DEC claimed they could talk to SUN using SAMP and HP
could talk to SGI in CIPSO, and everyone could banter in their own
version of NFS, but there was no money behind it, and interoperability
was never achieved even at the low levels.

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

> similar discussion. If people think that's a good way to go, I can

I would be delighted to see the discussion stay here. I would expect
a smaller group to end up with a rehash of one of the TSIX protocols
and a chip on their shoulders to make it go because of the work that
had gone into it. The problem is not one of communication, it's one
of getting the information communicated to make sense. Look at CIFS
and NFSv4 ACLs. That is the level of effort you have to invest to
solve the problem for a pair of different security schemes. True,
the more similar the schemes the more likely the results will make
sense, but even two Smack systems with different rule sets, or
two TOMOYO boxes with different profiles are beyond what you can fit
in a configuration database.

NFSv4 with labels will properly only ever support servers and clients
with identical label configurations, and with that the DOI becomes
meaningless. If you want to support labels improperly you have a
much better chance of success, but a tougher row to hoe with the
standards bodies. This is hard, and we've been working since the 80's
on it, looking for someone smarter than us to propose a solution.

---

From: Jarrett Lu <[email-masked]>
Date: Mon, 30 Mar 2009 22:59:15 -0700

> that external information gets populated is IMHO out of scope for

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

> get the whole picture for labeled NFS.

Continuing on these lists is fine with me. People on these lists 
probably have high tolerance on postings that don't care about.

Jarrett

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Mar 2009 13:28:51 -0500

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

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

> probably have high tolerance on postings that don't care about.

It sure seems that way so far :)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Mar 2009 13:34:46 -0500

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

---

From: Jarrett Lu <[email-masked]>
Date: Tue, 31 Mar 2009 20:33:07 -0700

> 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 
thought it is one of the things we are aiming for. We can say "give us 
an opaque field and we (the MAC systems) will decide how and when to use 
it. NFSv4 WG and ADs still want to know how this opaque field may be 
used. They are less willing to hand out "opaque" field just because 
someone asked for one. At least this is the impression I got at IETF74 
in SF.

> compartment naming and mapping to bits is not).

Right. This makes it easier for systems speaking CALIPSO protocol to 
interoperate at IP layer. Compliant hosts and routers know how to deal 
with packets with that option. Label translation between different DOIs 
is out of scope.

> way forward for this WG, but we'd make room for a future hash-of-policy.

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?

> should proceed as though we don't, for now.)

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.

Jarrett

---

From: Casey Schaufler <[email-masked]>
Date: Tue, 31 Mar 2009 20:42:24 -0700

> first glance, but I'm an optimist, so I think it must be doable :)

You only get common policy on a single system image. Oh, with MLS
you can limit it to MLS hosts and unlabeled hosts, but you'll always
have at least the two. Even with MLS you'll have machines that are
disallowed each other's levels and/or categories. This situation
had a major impact on the Smack design, where there is no interpretation
of the label at all.

---

From: James Morris <[email-masked]>
Date: Wed, 1 Apr 2009 17:58:38 +1100 (EST)

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

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