Subject: [nfsv4] [LNFS] Updated draft

From: Thomas Haynes <[email-masked]>
Date: Mon, 2 May 2011 23:57:06 -0500

I just pushed out a new version of the draft: draft-quigley-nfsv4-labeled-01
and it can be accessed via http://datatracker.ietf.org/doc/draft-quigley-nfsv4-labeled/

Since the first draft, I have added:

1) The additional use cases provided by Kathleen Moriarty

2) The new callback, CB_LABEL_CHANGED

3) A description of LFS 0, which is a simple security system for:
a) Debugging infrastructure
b) Only storing and returning the label. I.e., allowing smart
clients to work together.

NOTE: I chose LFS 0 because it defined a default security
system for LNFS aware servers and it allowed for debugging
of the transport code.

4) An example of how the new callback enables LFS 0 to work.

5) DS to MDS label enforcement

NOTE: I was purposely vague on details here. In the last meeting,
this area drew concern about how FILE, OBJECT, and BLOCK
layouts work here. My claim is that they already work with DAC
access checks and by piggybacking on top of that mechanism
for each layout type, we can avoid layout type specific language.

6) A means for a client to discover the LFS supported by the server.

An interesting point here is that we have discussed the client and
server having different LFS, but we haven't discussed the server
supporting multiple LFS at the same time. I.e., we allow for the
server's security system to map from LFS A to LFS B, but we
do not explicitly state whether the server can support multiple
LFS in its namespace.

Do we want to consider such an extension? In my mind, the
difficulty is in the client being presented with a directory which
contains objects which are the root of different LFS models.
I.e., the whole security flavor approach we take for AUTH_SYS
and kerberized access.

---

From: Dave Quigley <[email-masked]>
Date: Tue, 03 May 2011 04:36:45 -0400

On 5/3/2011 12:57 AM, Thomas Haynes wrote:
> and it can be accessed via 
> http://datatracker.ietf.org/doc/draft-quigley-nfsv4-labeled/
>

So in the LFS document that Jarrett and I wrote we reserved LFS 0 as 
unused. I had originally argued that LFS 0  should be a null LFS where 
it is completely opaque and you better be sure that everyone is speaking 
the same language before you used it. Since you've come up with a 
similar concept I'm wondering if this is a bettter use of LFS 0 than 
reserving it. If we do define LFS 0 as being a sort of NULL label format 
should that description go into the LFS document or should it be a 
document referenced by the LFS document?

> do not explicitly state whether the server can support multiple

The view I originally held for this was that when a smart server gets a 
label from a client it would translate it from the client's DOI(meaning 
LFS/PI combination) into its own local one and store the labels like 
that. Because of this there is a translation that happens at the 
boundaries between clients. We can discuss further where we think they 
should be (I'm tempted to say at the server). This way a client really 
only needs to know about its own DOI while the server needs to know how 
to talk among multiple clients. However, and this is a big caveat here,  
something may get lost in translation. You have to be conscious when 
doing this that your translations are in fact not lossy otherwise you 
could get a situation where the label you put on disk is not the one you 
got back.

This method allows support for LFSs which implement similar models to 
talk with each other.  For example, SELinux and FreeBSD MLS policy. Both 
can implement DOE or DOD MLS labeling. There may be a situation where 
you deem it acceptable for them to work on the same data set. However 
this is where we get a lossy translation. A FreeBSD system can place a 
label onto a file and the server will have to fill in the remaining 
SELinux components when giving that label out to an SELinux client. We 
have to make a decision as to whether it is up to the server to give out 
default label values for a LFS or if its up to the client to fill in the 
blanks.

I think this is something that we need to discuss further.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: sfaibish <[email-masked]>
Date: Tue, 03 May 2011 09:42:40 -0400

>> 1) The additional use cases provided by Kathleen Moriarty
I assume that the virtualization usecases will be addressed (currently
Section 9.2 looks a little too thin). For example it doesn't make any
distinctions between on wire and on disk protection).

> document referenced by the LFS document?
No additional external documents please. Neverthless I thought we discussed
to use label 0 (or NULL) for dumb clients to which the server sent the  
support for
LFS but client doesn't understand labels except is aware of server being  
capable.
(I think me and David Black were looking at this).

> should be (I'm tempted to say at the server). This way a client really
This is true/possible only for LFS aware servers. We need to ensure that
"dumb" servers that support only the LFS attributes can still support
different types of clients supporting different DOIs. The entire
discussion is mostly for the LFS aware clients and servers and we
need to be sure that unaware servers are supported.

> could get a situation where the label you put on disk is not the one you
I agree with this statement and we must prevent making this behavior
responsibility of the server. This also means that the server is aware of
all the LFS existing in all environments. How do you define this? Use a LSF
database? And why is this a v4.2 protocol issue. How to manage different  
LSF.
IMHO this is a server implementation detail. I would like to see as little  
as
possible included in the 4.2. And yes this can be defined in a different
document.

> default label values for a LFS or if its up to the client to fill in the
I vote for the server give out a default value (NULL) and the unaware  
client
to use NULL to label new objects as recommended by the server.

> I think this is something that we need to discuss further.
Agreed. This issue should be in the Agenda for the next meeting.

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 May 2011 10:44:14 -0500

> 2) The new callback, CB_LABEL_CHANGED

Is this the only meta-data for which we'll ever want such a callback?

If not I think a generic callback would be better.  The key is to
distinguish critical from non-critical meta-data changes (which could
be done via two sets of attrs, or a simple flag, for example).

> system for LNFS aware servers and it allowed for debugging

What would this LFS' properties be?  Suppose it grants access only
when the subject label equals the object label...  but you'd be so
close to Smack then!

> I.e., the whole security flavor approach we take for AUTH_SYS

What would the extension be like, OTW?

Anyways, servers can support multiple LFSes/DOIs, either by
translation between them or by simply allowing it and applying the
different rulesets as appropriate.  In the latter case users will, no
doubt, prefer to segregate content by LFS...  In practice I don't
really see this happening.

A much more interesting model would be one where each subject and
object can have more than one label.  This could be a DTE label and an
MLS label -- one to enforce domain-types, the other to enforce
compartments and levels.  This could be a useful way to combine LFSes
(all MAC policies being ANDed).  I'm not sure that there will be
demand for this, but, incidentally,  RPCSEC_GSSv3 allows clients to
assert more than one subject label...  Just to keep this option open
I'd suggest that NFS allow more than one object label as well.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 12:29:40 -0500

On May 3, 2011, at 8:42 AM, sfaibish wrote:

> On Tue, 03 May 2011 04:36:45 -0400, Dave Quigley <[email-masked]> wrote:
> 

Please feel free to provide more text for this area.

> No additional external documents please.

Right now this is kept in http://tools.ietf.org/html/draft-quigley-label-format-registry-01

I will pull this document into the current draft with the next revision.  (This is
actually one of the questions within the draft.)

> Neverthless I thought we discussed
> to use label 0 (or NULL) for dumb clients to which the server sent the support for
> LFS but client doesn't understand labels except is aware of server being capable.

I actually don't care what scheme gets used as 0. I'd like for us to define such
basic scenarios as the first values.

I don't see the need for a unique LFS in the above scenario. If the clients are
dumb, then that puts all decision making on the server. But the spec claims
that the NFS client and server does not make any decisions on MAC labels.
So we would need to define a security system to handle all of this. I think
that is out of scope for this draft.

I don't have the same issue for the smart client/label aware server because
we are not defining any security decision making. We are simply defining
additional transport semantics to allow the clients to react to a change in
the label.

> need to be sure that unaware servers are supported.

I think this is a good observation, it has really made me think about our
model.

Some terms:

Dumb server - it neither stores nor transports labels
Label aware server - it stores and transports labels, but it does not act on them
Smart server - it stores, transports, and acts on labels.

What you are stating is that a label aware server needs to accept
more than LSF 0 from a client. It sounds attractive, but there are some
complications:

1) What happens when that server is upgraded to a smart server?

This one states that a smart server has to be able support multiple DOI
anywhere in the namespace. Or it has to be able to map all existing
FATTR4_SEC_LABEL attributes to values that it supports (which
is vague enough to allow a security system which understands
multiple DOI).

2) How do the  smart clients  determine what to do with an LFS (and/or DI)
that they know nothing about?

This one really implies to me we only want to support one LFS in
a label aware server, but that still does not work. The LFS would still
be 0, but each client would have to interpret the opaque label. We
could get labels that the client knows nothing about.

More on this below...

> database? And why is this a v4.2 protocol issue. How to manage different LSF.
> IMHO this is a server implementation detail. I would like to see as little as

I agree that defining how a server support multiple LSFs is not in the scope
of this document. However, how the server reports such scenarios to the
client is very much in scope.

Some questions which we need to consider:

1) Can a file object have multiple labels, each of which is DOI dependent?

So far the answer is no, in that security system would have to do the mapping.

2) Can a directory object have multiple labels, each of which is DOI
dependent?

This one is more tricky as we have yet to flesh out what we are going to
do with directory objects. I.e., we disallow a client from reading a directory.

I think the answer is still no. We have to let the security system do the
mapping.

3) Which security system gets to do the mapping if the server supports both?
The one the client is using, as shown in the subject label, or the one shown
in the object label?

I think the answer is always the object label.

4) How do we handle an object label for which there is no security system?

I think this one is server dependent and outside of the scope of the document.

BTW - nothing we have put in place keeps a client from being able to
speak multiple DOIs. 

I think 99% of all deployments will be a single LFS and perhaps multiple DI.
I hope that anyone who deploys multiple LFS on a server does so with
subtrees and has no other mingling within a directory.

I think we either decide:

1) The first implementation of LNFS is only going to support one LFS on the
server. We will push off doing multiple ones until we have some implementation
experience.

BTW - are there any existing servers which support multiple LFS on local
filesystems.

2) We support multiple LFS on the server and provide a section which details
a best practices implementation guide.

> I vote for the server give out a default value (NULL) and the unaware client

If the client is unaware, how does it set labels?

I think the default label generation should be security system dependent. You
can either record NULL, in which case the system needs to map that to a default,
or you can set the label.

The benefit of setting it is in scenarios where we allow multiple LFS
on the same server. A NULL can be interpreted differently, whereas
a set label has only one interpretation and it forces the server to
use the correct LFS to parse it.

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 12:51:52 -0500

> Is this the only meta-data for which we'll ever want such a callback?

I think so. I'll take an AI to examine this.

> be done via two sets of attrs, or a simple flag, for example).

Even if it is currently the only meta-data we want to support, it
might be a good idea to use your proposed extension to support
something we are not foreseeing.

What I like about this idea is that it only reports that something
has changed, but not how. The client still has to query the server
to determine the change. (Which is a requirement for this work.)

> when the subject label equals the object label...  but you'd be so

A very good question, especially when combined with Sorin's
observation that  the smart clients probably want to store labels
with the DOI that they are using. I.e., if we ever upgrade a label
aware server to a smart server, we already have the labels correct.

I think what we might want to do is use LSF 0 on the ROOTFH to
indicate that the server is label aware and not smart.

PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}

A LSF of 0 states the server is label aware.
Any other LSF states that the server is smart.

And it indicates that it is a dumb server by not setting the appropriate
bit.

And then I don't know what we want to do with properties inside
the rest of the filesystem. I think we only want to allow a NULL
label if the LFS is 0. If the smart clients have an implementation
that they want to remain private, they are free to use one of
the LSF marked for Private Use only in the registry. Otherwise,
they will use the LSF that they all understand.

> What would the extension be like, OTW?

I'd like to hold off on that discussion until we cover the namespace
issues.

> assert more than one subject label...

I had just been reading the RPCSEC_GSSv3 spec on that matter.

>  Just to keep this option open

I think we should bring this up at the next meeting. I'd also like
to keep this option open.

---

From: <[email-masked]>
Date: Wed, 4 May 2011 10:18:38 -0400

> Do we want to consider such an extension?

IMHO, not for the first version of LNFS.  Let's stick with one object label
in the protocol for simplicity, please.

Possible alternative: Allow the client to specify what LFS it is using.
Server can say "yes" or "no", plus a server that supports multiple LFS's and
can map across them could use this to decide which LFS to show to that client.

If we want to do that, it needs to go in now, as it'll be difficult to add
the initial operation for the client to declare the LFS that it's using to
the server.  I'll leave it to folks like Dave Q and Jarret to comment on
whether the DOI mapping is appropriate to client vs. server vs. both.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
> Sent: Tuesday, May 03, 2011 12:57 AM
> To: [email-masked]
> Subject: [nfsv4] [LNFS] Updated draft
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 09:50:12 -0500

> whether the DOI mapping is appropriate to client vs. server vs. both.

I propose something simpler: the label attribute may have N >= 1
values (labels), but a) servers are free to reject N > 1, b) clients
are free to refuse to access objects with N > 1 labels, and c) we
could have a filesystem attribute indicating whether the server and
filesystem support N > 1 object labels.

Also, we ought to have an fs attr listing the {LFS, DOI}s that the
server/fs supports.  For each such tuple we might want a boolean flag
indicating whether the server supports the given LFS+DOI natively or
via translation to another (and, possibly, what the other is).

This leaves us with an OTW protocol that can support multiple labels
but with interoperability initially guaranteed only for cases where
there's a single label per-object, and a clear path forward by which
to add interoperable multi-label support in a future minor version by
making previously optional behavior mandatory.

As for subject labels (RPCSEC_GSSv3), I'd say that we should allow
multiple subject labels now, with the client picking one to be the
first one in the list and the server picking the first one in the list
when it doesn't support more than one.  If the client marks more than
one subject label assertion as critical and the server can't handle N
> 1 subject labels, then the server should indicate this to the client
as a failure to handle a critical assertion.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 04 May 2011 09:04:46 -0700

> whether the DOI mapping is appropriate to client vs. server vs. both.

Solaris trusted extensions (TX) does not support multiple DOIs, so my
implementation experience in this area is very limited. The CALIPSO RFC
(RFC 5570) actually mandates multiple DOI support. I worked with authors
of that RFC and could not persuade the authors to change that from
"must" to "should". So I guess there are users out there who feel strongly
about multiple DOI support.

I view DOI mapping as a server/client feature. I don't see we need a
multi label NFS protocol extension to enable such a feature. In other
words, client/server only uses one label for an object. For example,
client A talks to server A using one label type 1; server A can also
serve client B using label type 2. There could be a mapping between
type 1 label and type 2 label (may be not). But client A and B don't
need to know the sever is capable of speaking another label type.

I also don't know if an explicit label type negotiation is required. I 
thought
the opaque label attribute has an LFS field that indicates the format
of the label. In the smart client -> smart server case, if the server
does not support the label of client's choice, it will say no. If the client
supports a second label format, it may try that one. In the
smart client -> semi smart server case, the server will just store
the label attributes. The burden is on other smart clients to check
the validity of a file label attributes.

If the above is sufficient, we only need a simple extension.

- Jarrett

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 11:41:34 -0500

But I do see value in multiple labels of _different_ LFS types.  You
could use one label for domain-type enforcement, and another for
compartment+level (or similar) enforcement, with both enforced
simultaneously.

My proposal is simple and allows implementors to support just one
label at a time initially while giving us a trivial way to later
support multiple labels.

This particular sub-discussion should probably be moved to SAAG, where
we're likely to get advice from more MAC experts.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 04 May 2011 09:50:33 -0700

> If the above is sufficient, we only need a simple extension.

Sorry, I should have had coffee before writing emails.

I think there is a need for clients to know server's label handling 
capabilities
so that a client can decide whether it will use the service. Solaris did 
that
using configuration. For greater interoperability, this should be 
negotiated.
I believe a client only needs to know smartness of the server (or whether
the server can support client's label). It may not need to know the list of
all labels the server can handle. So the protocol extension will be more
complex than I outlined in my last email.

- Jarrett

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 4 May 2011 11:58:43 -0500

> label at a time initially while giving us a trivial way to later

I think this is a very important consideration given our minor versioning
rules. If we implement FATTR4_SEC_LABEL as a scalar, then to get
to multiple labels in the future, we would have to implement
FATTR4_SEC_LABEL_PLUS. I really do not want to do this.

I was going to propose that we allow an array and limit it to one value,
but given Jarrett's summary of RFC 5570, I am now hesitant to do so.

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 04 May 2011 11:31:19 -0700

> compartment+level (or similar) enforcement, with both enforced

Given the two MAC models are so different, I doubt people will
ever do that. Kathleen's sensitivity label + criticality label may be
a better candidate for a file object requiring multiple labels.

> label at a time initially while giving us a trivial way to later

I think we agree on the goal/requirement: support one object
label first and take extensibility into consideration.

> we're likely to get advice from more MAC experts.

In the past, we haven't had great response from saag on MAC
issues.

Thanks.

- Jarrett

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 13:31:11 -0500

> complex than I outlined in my last email.

+1, with the caveat that we might want "LFS, DOIs supported" to be
filesystem attributes, not server attributes.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 13:35:12 -0500

> a better candidate for a file object requiring multiple labels.

That was just an example.  I think it's a good example, and I think
it's good precisely because DTE and MLS are so different -- using two
labels and ANDing the authorization checks is the only reasonable way
to combine them.

Quite aside from whether the example is a good one or not, it need
only be plausible that we might ever want to combine LFSes in this
way.  If that is plausible then we ought to want to design LNFS such
that it can support multiple labels.

> label first and take extensibility into consideration.

Yes, but that means take it into consideration now so we can avoid
having to change the wire protocol later (and so implementors can
experiment with multi-labeling now).

> In the past, we haven't had great response from saag on MAC

I remember a lengthy NFS/SAAG thread a couple of years ago that
involved participants who do not normally hang out on the NFSv4 WG
list.

Nico
--

---

From: Stephen Smalley <[email-masked]>
Date: Wed, 04 May 2011 14:53:08 -0400

> we're likely to get advice from more MAC experts.

The SELinux security context is a composite label consisting of multiple
components, including user, role, domain/type, and MLS range.  It is
still a single "label", but it has multiple components.

-- 
Stephen Smalley
National Security Agency

---

From: Stephen Smalley <[email-masked]>
Date: Wed, 04 May 2011 14:55:27 -0400

> labels and ANDing the authorization checks is the only reasonable way

Actually, the composition of TE and MLS in SELinux is more complex than
a simple AND; we use TE to identify and control the subjects that are
trusted to override specific MLS restrictions.  For example, a process
with a given domain type may be authorized to override the MLS
write-down restriction on files, while a process in a different domain
type may be authorized to override MLS restrictions on socket writes.

-- 
Stephen Smalley
National Security Agency

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 14:17:15 -0500

> still a single "label", but it has multiple components.

So, I get it that generic composition might leave something to be
desired, thus leading to some custom compositions.  But that's not
dispositive.

The questions I have are:

a) Is it always going to be the case that generic composition is never
desirable, or even never feasible?

b) Will anyone ever want to do generic composition?

I think the answers are "no" and "possibly".

Nico
--

---

From: Stephen Smalley <[email-masked]>
Date: Wed, 04 May 2011 15:49:38 -0400

> I think the answers are "no" and "possibly".

That seems like a safe assertion ;)

FreeBSD supports multiple simultaneous MAC models, each with its own
label, although you can also get that as a single unified label.  Not
sure what the tradeoffs are of supporting multiple LFS vs a single LFS
that encodes multiple labels.

-- 
Stephen Smalley
National Security Agency

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 15:01:33 -0500

> That seems like a safe assertion ;)

I thought so, but I wasn't sufficiently certain of that :)

I mean, you could have made a strong argument against generic
composition.  I don't know what that argument could have been, but I
couldn't be certain that there is no such argument to be made :)

> that encodes multiple labels.

This is very good information.  For one I think this argues that LNFS
ought to support generic composition now, not later.  Secondly, this
shows that generic composition is not even theoretical.

Note too that there's a difference between generic composition at MAC
policy evaluation time and generic composition of labels themselves.
IIUC it should be possible to do generic composition of labels without
precluding custom policy composition.  I think this is a valuable
distinction.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 4 May 2011 16:32:11 -0500

> filesystem attributes, not server attributes.

What do you mean by 'supported' here?

1) DOIs that the server's security system can handle?

2) DOIs that are encoded in labels in the filesystem?

There are two interesting scenarios to consider:

1) A label aware server which is upgraded to a smart server. It might
have labels from DOIs that it does not support.

Which leads to the possibility of having a hybrid label aware and
smart server. I.e., the security system's behavior when it encounters
a foreign DOI is to just pass it back to the smart client to process.

2) Also, what happens if a filesystem is either replicated or migrated
from a either a label aware or a smart server to another smart server
which does not understand the incoming DOIs? While it appears a filesystem
attribute would handle this issue, the point is that the destination
server might not 'support' the DOI. I.e., another hybrid label
aware/smart server.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 May 2011 16:51:33 -0500

> 2) DOIs that are encoded in labels in the filesystem?

Up to the server.  A strict server will only allow the DOIs that it
can handle.  A label-aware-but-not-smart server may allow any DOIs and
simply keep track of which ones have been used (though I'd not
configure a label-aware server to allow DOIs that smart clients
wouldn't understand, and I'd expect that on upgrade to smart server it
will be able to handle all my DOIs).

> [...]

Patient: "Doctor, doctor, it hurst when I do this"
Doctor: "So... don't do that"

:)

By which I mean that label-aware servers will have to be configurable
as to which DOIs they may allow.  But really, I just don't see much
value in label-aware-but-not-smart servers.

Nico
--