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

From: Peter Staubach <[email-masked]>
Date: Mon, 09 Feb 2009 17:24:32 -0500

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
>
>
> A new version of I-D, draft-quigley-nfsv4-sec-label-00.txt has been
> successfuly submitted by David Quigley and posted to the IETF
> repository.
>
> Filename:        draft-quigley-nfsv4-sec-label
> Revision:        00
> Title:           MAC Security Label Support for NFSv4
> Creation_date:   2009-01-22
> WG ID:           Independent Submission
> Number_of_pages: 12
>
> Abstract:
> This Internet-Draft describes additions to NFSv4 minor version one to
> support Mandatory Access Control systems.  The current draft
> describes the mechanism for transporting a MAC security label using
> the NFSv4.1 protocol and the semantics required for that label.  In
> addition to this it describes an example system of using this label
> in a fully MAC aware environment.
>                                                                                   
>
>
> The IETF Secretariat.
>
> http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-sec-label-00.txt

I have been looking at the document and have some comments,
questions, and suggestions --

In section 1, MAC is defined, but perhaps it might be useful for
NFS folks to expand upon the definition just a tad.  For example,
how is this different than normal access control and why?  Perhaps
I am dense, but the text in Section 3 might make better sense if
I understood a little more about MAC at a high level.

In Section 3, there is discussion of using a recommended attribute
to store the security attribute.  A request is made for security
attribute number 76.  This one appears to be used already in the
NFSv4.1 specification.  Perhaps this should be flagged so that it
can be updated appropriate when this specification is included
into a larger, NFSv4.2, document?

In Section 3.1, DOI is defined for a third time.  The acronym can
probably just be used here.  That said, providing a little more
detail on how a DOI would be represented would be useful.  Is it
a 32 bit unsigned integer or something else?  Perhaps including
a pseudo description of the syntax of the security_attribute
would be good.

Section 3.2 discusses handling if a security attribute is
changed while a client is holding a delegation to an object.
The text describes that the client should flush changes to the
server and relinquish the delegation.  Why?  Is access to an
open file on the client to be revoked?  What happens on a
client which does not happen to be holding a delegation at the
time?

This leads to a further question concerning client side caching
of these attributes.  Is the client allowed to do caching?  If
so, how would it go about doing cache validation?

Section 4.1 includes an XXX reference probably to a draft
document.  Is this the draft for RPCSEC_GSSAPI v3?

Section 4.1.1 discusses denying a request if a security
attribute can not be translated from one DOI to another.
What error should be returned?  It seems to me that a new
set of errors may potentially need to be introduced to
handle the new cases where servers need to inform clients
exactly what happened.  Section 4.1.2 is missing a period
on the end of the second paragraph.  Perhaps this is the
intended error to be returned?

Section 4.2.1 discusses a smart client and the need for a
common DOI.  Could a client not implement its own translations
for the DOIs that it may choose to know about?

Section requests an IANA registry for DOIs.  Perhaps document
like, draft-ietf-nfsv4-rpc-netid-06.txt, previously circulated
by Michael Eisler, will need to be constructed to handle the
issue.

---

Anyway, enough for the time being.  I think that some more
detailed definitions and declarations need to be specified
in order to move along.

    Thanx...

       ps

---

From: "David P. Quigley" <[email-masked]>
Date: Wed, 11 Feb 2009 18:47:44 -0500

> I understood a little more about MAC at a high level.

I will make an attempt to clarify this. I was trying to get a concise
definition into the draft without bogging it down with a whole bunch of
Access Control theory. However, if it isn't clear enough then I do need
to fix this.

> into a larger, NFSv4.2, document?

Hmm I picked that number from what I thought was an earlier v4.1
document. It's possible that I was looking at 4.0 proper instead. I
asked about grabbing a number a while back and someone said just take
one and we can fix it up later. A question for the WG is if there is a
proper procedure for this? Should I leave it blank with some sort of
marker like Peter suggests or is it as simple of just pick one for now
and we'll deal with conflicts if/when it gets chartered.

> a pseudo description of the syntax of the security_attribute

It seems reasonable at this point that the person will know what DOI
stands for and if not they can look it up in the terms section. There
are a few people doing transport layer work that have a definition of a
DOI. I originally had a marker in there that we should have a normative
reference to a draft about DOIs. The structure that most people seem to
be happy with is a 32 bit number that can be thought of as a series of 4
octets. This allows it to be easily partitioned into ranges for private
used among other things. The CALIPSO guys have a good starting point for
this and we talked about it at the DOI BOF last IETF. The consensus at
that meeting was that we should convene a full BOF to discuss it at a
future IETF. Between the Labeled IPSec drafts that are slowly making
their way to the IETF, the CALIPSO draft which is already far along, and
the Labeled NFS work we should probably have a standard definition for
DOIs including how they are registered, represented, what ranges are
reserved and for what purposed, etc. 

Even if this information is pulled in from a normative reference it
doesn't seem like a bad idea to explain part of it in this document. 

> client which does not happen to be holding a delegation at the

Well, this is standard behavior for delegation within NFSv4. If the
security label is changed from under a client you have an issue where it
could still be making local cached access decisions based on a label
that is now out of date. This may not be as stringent of a requirement
with DAC permissions but with MAC it's very important because the system
may be mediating read and write calls in addition to just open calls. If
the client doesn't have a delegation then it shouldn't have an open file
handle for the file. So when it opens the file it will get the valid
label.

Hmm, the text here seems a bit ambiguous. What I mean to say here is
that the label on the server changes while the client is holding the
delegation. There is a case to say that if it changes on the client that
if you really want to guarantee the file is protected on the server that
you shouldn't maintain local cached security attribute changes. However
it's not completely clear to me how the exported FS should react with
processes local to the server making access to files.

> so, how would it go about doing cache validation?

So as of right now we do standard attribute timeouts. In the Linux case
this is 5 seconds by default. I spoke with Nico briefly a while back
about this and he said what might be needed here was to provide some
sort of open file handle revocation support. In the past people have
suggested building the client's idea of the label into either the
stateid or some other form of cookie that can be verified by the server.
We explored doing this in the form of an NFSv4 op and while that worked
we are trying to shy away from adding new operations if we can help it.
I'm still open to potential solutions to this problem. 

> document.  Is this the draft for RPCSEC_GSSAPI v3?

That's exactly what it is referencing. I think the reason I left that
was because Nico hadn't posted it to the IETF website as a P-ID when I
had released this. It was made public but I don't think it was
submitted.

> intended error to be returned?

The error mentioned in 4.1.1 is the one referenced in 4.1.2
(NFS4ERR_ACCESS). I'll put it in section 4.1.1 as well if it makes
things clearer. I am open to adding a NFS4ERR_MACACCESS code or
something similar to that to provide additional information to
administrators as to why things are failing. I make mention in 4.3.2
that an administrator should be aware when he gets an access failure
using this functionality that it can possibly be caused by the MAC
policy. I probably need to find a better location for this tidbit of
information.

> for the DOIs that it may choose to know about?

We made a decision that in an environment where the server just operates
as a dumb storage medium that it would bring huge problems to store the
DOI with the label. So in this kind of environment the security
attributes are stored without a DOI on the server so it isn't possible
to have those translations take place. The second half of that section
says why we made that decision. I should add to the security attribute
section that when an attribute shows up without the @DOI portion of the
string it should be treated as the null DOI. Either that or we should
atleast force these storage boxes to append @0 into the attribute. 

> by Michael Eisler, will need to be constructed to handle the

I'll take a look into this document to see what we can learn from it.

> detailed definitions and declarations need to be specified

I noticed you didn't make any comments regarding section 5. This was the
most recent section added because some WG members expressed a desire to
see an extensive example of the system. Did you not comment because you
think its acceptable or are comments on that being put off till after I
address these. Also a question for the WG. Is that section effective in
providing understanding of the system? Is there something else that it
needs to contain? Are there ambiguities that I'm not seeing because I
have a background in the area?

Dave

---

From: James Morris <[email-masked]>
Date: Thu, 12 Feb 2009 12:07:31 +1100 (EST)

> we are trying to shy away from adding new operations if we can help it.

What's wrong with adding new operations?

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 12 Feb 2009 08:53:35 -0600

> What's wrong with adding new operations?

Nothing wrong with adding operations.   If there are other
alternatives, it is preferable to avoid new operations.  What
is meant by this is that it adding the functionality may be
easier from the technical/development standpoint and from
a process standpoint.

Spencer

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 12 Feb 2009 10:05:54 -0500

The specifics will depend on the specific feature but I don't think that
as a general rule doing things in other ways is typically easier.

>From a development point of view and from a process point of view, it is
genrally easier to add a new operation with clear boundaries on the new
functionality rather than change an existing operation to be somewhat
different.  That means updating an existing operation and when you do
that it is often harder to keep straight what is the same in the new
minor version and what is different.

Despite that, some things make more sense as modifications to existing
operations, and some things make more sense as new operations.  As far
as making the choice, I'd go with what seems clearest and most natural.
First impressions in this area can be wrong but if you find yourself
going out of your way to do something different, then that's probably a
case where the first impression was correct.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Thursday, February 12, 2009 9:54 AM
To: James Morris
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [nfsv4] [Labeled-nfs] New MAC label support Internet
Draftposted to IETF website

Spencer

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2009 09:22:03 -0600

> so, how would it go about doing cache validation?

For DAC POSIX semantics are that open file references are not revoked
when a file's owner/group/permissions (and/or ACL) change.

MAC requires some sort of revocation.  This can happen on the
server-side whenever the client tries to access a file after it's been
relabeled.  The client might learn of this pretty late, but given that
the user on the client would have been able to see the contents under
the old label this timing seems to me to be acceptable.

Recalling an open file delegation seems OK as a way to speed that up if
the client can obtain a new delegation if it still has access to the
file.

The only other wrinkle is that multi-user clients need to let the server
perform all access decisions for each user -- the client must not allow
access using local MAC decisions based on cached file labels.

> document.  Is this the draft for RPCSEC_GSSAPI v3?

No, it's not.  As David explained, that I-D came later.

> What error should be returned?  It seems to me that a new

IMO NFS4ERR_ACCESS is good enough.

> exactly what happened.  [...]

Perhaps, but I expect that production servers would return generic
errors like NFS4ERR_ACCESS rather than newfangled ones like, say,
NFS4ERR_NODOITRANS.  There's no need to tell the client too much about
why its request failed.  It suffices that access was denied, and for
that NFS4ERR_ACCESS is good enough.

> for the DOIs that it may choose to know about?

It could.

> detailed definitions and declarations need to be specified

Defnitely.

Thanks for the comments!

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2009 09:36:21 -0600

> > we are trying to shy away from adding new operations if we can help it.

The file handle should suffice.  The server can check if the label has
changed and then return an error.  If need be we could even use volatile
FHs for this (with the FH being somewhat like a capability).

> What's wrong with adding new operations?

In this case a new operation won't help since the server may want to
perform revocation as early as possible, and waiting for a client to use
a specific operation is not a good way to achieve that.  If you meant a
callback operation, sure, but the server needs to know what clients are
caching open file data and metadata, and right now the server only knows
about that when clients get delegations.  It might be possible to add a
callback operation to indicate that access must be re-evaluated but
without recalling a delegation.

Nico
--

---

From: "David P. Quigley" <[email-masked]>
Date: Thu, 12 Feb 2009 14:45:21 -0500

> What's wrong with adding new operations?

For the sake of discussion I'll talk about the previous work we did on
this topic. In the presentation I gave at IETF 71 we had a new NFSv4
operation called OP_PUTCLIENTLABEL. The idea of this was it was to work
like a PUTFH call in that you would push some state to the server which
would be used to evaluate all portions of the compound operation after
it. The idea was that the client would say that it believes the file is
TOP SECRET by issuing a PUTCLIENTLABEL at the beginning of the compound
op with the label TOP SECRET as the value. When the server evaluated the
parts of the compound operation that used a file handle it would check
if the label for that FH matched the one asserted by the client in the
PUTCLIENTLABEL operation. If they didn't match, the server returned an
ESTALE error and hopefully the client would refetch the file handle. At
the time Linux didn't have good support for recovering from an ESTALE
but since then I believe that support was fixed.

Someone in the audience brought up that we possibly had the
PUTCLIENTLABEL op in the wrong place because it wasn't being protected
by one of the replay attack mechanisms. This would have been easy to fix
but some people seemed skeptical to doing this as a new operation (we
had a total of two or three that were being proposed). So we went back
and looked for another way to do it. James had suggested building it
into the stateid and Nico has suggested to use volatile FHs for it. 

When I gave a followup presentation at IETF 72 I mentioned that we had
removed the operations. After the presentation I believe Mike Eisler
mentioned that it was good that we avoided adding new operations. He
said that they were trying to make future revisions to NFSv4 (4.2 and
higher) move more quickly through the process since they would be
smaller revisions. We hoped making the required protocol changes smaller
would help move things along more quickly.

I'd like to hear more from Nico on how we can use volatile FHs to solve
this problem. The document still needs more work to take care of things
like this but I was hoping this revision could get the discussion
rolling so other people would provide input into the design. It seems
that it is getting attention now.

Dave

---

From: "David P. Quigley" <[email-masked]>
Date: Thu, 12 Feb 2009 15:00:51 -0500

> without recalling a delegation.

We also explored a callback for label change notification. I think we
even have the code lying around for the prototype. It worked but Trond
expressed some concern with how well it would scale. The issue Trond
raised is what happens if you relabel an entire file system from under a
set of NFSv4 clients? I'm not sure how much of a concern this will be
since 1) File relabeling is supposed to be rare and 2) clients will
probably have a small subset of files open. In the event that you do
need to relabel the entire file system on the server it might be a good
idea from an administrative perspective to have your clients remount the
NFS shares and flush whatever caches they have.

Dave

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2009 14:11:52 -0600

> set of NFSv4 clients? I'm not sure how much of a concern this will be

Surely it would scale no better and no worse than open file delegation...

> probably have a small subset of files open. In the event that you do

Reclassification of data is supposed to be rare, though that may vary a
lot by environment.  The number of files that may be kept open provides
a natural limit to how many relabel callbacks will be needed.  (A client
could OPEN every file at limit cost to itself hoping to overwhelm a
server, but that's a separate issue.)

> NFS shares and flush whatever caches they have.

Well, there's no callback to tell clients to flush all writes and
remount (or recover).  You could simulate a server reboot and force
recovery though.

Nico
--

---

From: "David P. Quigley" <[email-masked]>
Date: Tue, 17 Feb 2009 11:50:50 -0500

> remount (or recover).  You could simulate a server reboot and force

So can anyone see of another use for providing a call back that would
tell a client to flush it's cached changes back to the server and start
a recovery? It could be a potential solution to large scale relabeling
on the server but I hesitate to propose it unless it has more than just
that application. Also aren't callbacks done out of band and if a
callback channel can't be established the functionality is just dropped?

Dave

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2009 11:00:27 -0600

> callback channel can't be established the functionality is just dropped?

I don't think that timely revocation, extending to cached data on
clients, is a problem that we need to address for labeling.  It's a
problem in general and one that most users and implementors probably
don't care that much about.  Timely revocation can always be addressed
separately if it becomes sufficiently desirable.  IMO: leave it out of
scope.

Nico
--