Subject: [nfsv4] Response to Labeled NFS Document comments.

From: Dave Quigley <[email-masked]>
Date: Mon, 28 Mar 2011 07:24:30 -0400

Since Tom went through a lot of work reviewing my document I didn't want 
my response to his questions buried in the long thread that took place 
after he posted them. So instead I've taken Tom's comments from his 
initial email and have responded to each of them inline and posted it 
here. Text from the internet drafts is kept with no Name: marker on 
front. Everything with Tom: on it was in his original email. Everything 
with Dave: on it is my response.

               draft-quigley-nfsv4-lnfs-impact-01.txt

Tom: Section 2.3 sounds like hand waving.

Tom: Perhaps add a section with the new requirements coming out of Red 
Hat? I.e.,
I thought they had a new need for this stuff for clouds?

Dave: So Dan chimed in that his main use case is virtual machine 
separation which is section 2.2 and I believe that is what Red Hat is 
mainly concerned with. I think I need to revisit what I'm trying to say 
in sections 2.1 and 2.3. Looking back at these sections I'm having a 
difficult time telling the difference between section 2.1 and 2.3.

----

Tom: I would have liked to have seen something in the email stating that 
the reader
should start with Section 3 to get an idea of how to look at the 4 
documents.

Dave: This is definitely possible. I'll make sure to make a note in my 
next email that section 4 of the impact study is a general overview of 
the documents. Looking at this section some of the document version 
numbers are off as well so I have to fix that up.

----

    The MAC recommended attribute specification document describes the
    protocol changes to NFSv4 in the form of a new optional to implement
    recommended attribute.  This document is currently published as

Tom: I'd recommend changing this to state that it is optional in the 
first minorversion it debuts in,
but is intended to be required in the next minorversion.

Dave: I wrote a blurb in response to another email about this comment. I 
think its definitely something we should discuss as to whether this 
should eventually be a Mandatory attribute instead of a recommended one. 
I'd be happy with it either way but making it Mandatory guarantees that 
atleast the basis is there for my customers to get what they need.

----

Tom: Section 4. Just state that this entire document addresses security 
concerns.

Dave: Sounds like a reasonble thing to put in that section unless there 
are additional things that should be in there. I'll go with something 
simple like that though.

----

===

                   draft-quigley-nfsv4-sec-label-03.txt

----

    People desire to use NFSv4 with these systems.  A mechanism is
    required to provide security attribute information to NFSv4 clients
    and servers.  This mechanism has the following requirements:

    o  Clients must be able to convey to the server the security
       attribute of the subject making the access request.  The server
       may provide a mechanism to enforce MAC policy based on the
       requesting subject's security attribute.

    o  Server must be able to store and retrieve the security attribute
       of exported files as requested by the client.

    o  Server must provide a mechanism for notifying clients of attribute
       changes of files on the server.

    o  Clients and Servers must be able to negotiate Label Formats and
       Domains of Interpretation (DOI) and provide a mechanism to
       translate between them as needed.

    These four requirements are key to the system with only requirements
    two and three requiring changes to NFSv4.1.

Tom: I never saw how the changes for 3 were to be done. (BTW - please 
use <list style='numbers'> here.)

Dave: Good point on the list format type. It was unclear at the time 
what mechanism we might want to use to provide label change 
notification. One method was to rely on the file handle being marked 
stale forcing the client to revalidate the handle and all of the 
attributes on it. Another option was just rely on the attribute cache to 
time out and have it regrab them. The final method we looked at was an 
actual callback for the notification. This suffers from the problem of 
it being disabled if callback support is not available. This would be a 
good thing to discuss.

---

Section 3:

To this end the attribute number XXX:ATTRNUM is
    requested for the security_attribute recommended attribute.

3.1.  Interpreting security_attribute

    The security_attribute field contains two components the first
    component being an LFS.

Tom: You need the XDR to be provided here.

Dave: I believe I have the XDR for this somewhere. I guess it didn't 
make it into the document. I'll include it in the next version. It is 
pretty trivial as its just an integer and an opaque field.

---

    The second component is an opaque field which the actual
    security attribute data.  To allow for various MAC models NFSv4
    should be used solely as a transport mechanism for the security
    attribute.  It is the responsibility of the endpoints to consume the
    security attribute and make access decisions based on their
    respective models.

Tom : Are there any guidelines here for the opaque field? I.e., are 
there any existing standards it
must adhere to?

Dave: The format of these labels was a bit ephemeral when we first 
stated and we wanted to keep them flexible so we wouldn't lock people 
into something that they didn't need so this is what the Label Format 
Specifer document is for. Its a registry of label formats which describe 
the structure of the opaque fields.

Tom: If the answer is that they are site dependent, what happens if 
multiple implementations try
to share the same server?

Dave: So it is possible that labels will be site specific. In the case 
where there are two different label formats in use (for example SELinux 
labels vs BSD MLS labels) there is a translation daemon which translates 
from one label set to another. The format of the label and the actual 
semantic meaning of label values are called a Domain of Interpretation 
(DOI). This is one of the more difficult things to reconcile when using 
security labels. However if your entire infrastructure is homogenous 
then it isn't really an issue.

Tom:I see this last is presented in 
draft-quigley-nfsv4-sec-label-requirements-03.txt.

----

    The character '@' is
    reserved as a separator between the LFS and opaque section of the
    security attribute.

Tom: This is where the XDR would help. Why do we need the '@' symbol 
when the
LFS and the opaque section would be better described as two fields.

Dave: I agree, I'll add the XDR for this. Originally the idea was to 
make it a human readable string on the wire but I think we've given up 
on that and left that decision up to the specific security label format.

Tom: What is the size of the LFS and what is the size of the opaque 
section? If it
varies, what is the max size?

Dave: The LFS is a simple unsigned 32 bit integer. The size of the 
opaque section is another matter all together. The length of it varies 
based on the LFS in use. We don't have a good answer to what an upper 
bound is yet for the opaque field though.

----

3.3 Permission Checking

    This means
    that the NFSv4 client and servers can not be expected to directly
    make access control decisions based on the security attribute.
    Instead NFSv4 should defer permission checking on this attribute to
    the host system.

Tom :I'm confused here, neither the client nor server can make a 
decision. So what is meant by the "host system"?

Dave: The point I'm trying to get across here is that NFS has no 
business interpreting these security values. MAC systems are typically a 
component in the operating system which provide a lot of properties that 
have no place in the NFSv4 server or client and might not be easily 
guaranteed by the NFSv4 implementation (in case of a userspace 
implementation). For example the SELinux security server which is a 
kernel component is responsible for taking the security label and making 
an access control decision based on it.

----

----

====

            draft-quigley-nfsv4-sec-label-requirements-03.txt

Section 2:

    Without a method for providing per file-object labeling as described
    above existing MAC systems have fallen back to methods of handling
    file systems that lack labeling attributes.  While this allows policy
    to provide coverage of NFSv4 file systems, there are several
    limitations, including:

Tom: We need some references here and the approaches they took. I.e., 
while the limitations are
mentioned, there is no coverage of the approach.

Dave: I'll make sure to add these in the next revision.

---------

Section 3.2:

Tom: If LNFS is not deployed, there should be no significant performance 
impact.

Dave: I'll make note of this in the document. It should be really easy 
to implement as well.
---------

Section 3.5:

Tom: Different terms are used for Full Mode and Guest Mode in the 
different documents.
These need to be consistent.

Dave: I'll take a look at this and fix them up.

----

Section 3.8

Tom: MLS is used and not defined:  This is a common requirement of 
MLS-enabled systems,

Dave: Would it be better to define it inline or put it as a term in a 
term section of the document?

----

Section 4:

    When either the client or server is operating in guest mode it is
    important to realize that one side is not enforcing MAC protections.

Tom: We should be able to enumerate how a client and/or server can tell 
the other
is in guest mode. Is there a way for the client to convey it is using MAC
from the start? I.e., even before it sends an attribute?

Dave: For the NFSv4 recommended attribute there is an initial server 
capability negotiation that takes care of this. For the process label 
negotiation we haven't got far enough through RPCSEC_GSSv3 to determine 
what mechanism is needed yet.

    Alternate methods are being used to handle the lack of MAC support
    and care should be taken to identify and mitigate threats from
    possible tampering outside of these methods.

Tom: I find this vague. We should enumerate the other methods and 
recommend that
they be deprecated.

Dave: I agree. We'll clean that up.

-----

Tom: One thing I find missing here is a discussion of what the server 
should do if the
client makes NFSv2/v3 requests? Does it assume that the
server may choose

Dave: Security label support is not supported on NFSv2 or NFSv3 with 
this document. There have been attempts in the past to do security label 
support for NFSv2 
(http://www.ietf.org/proceedings/30/charters/tnfs-charter.html) and 
there was work done at the agency on a poject called synergyfs which did 
security label support in NFSv3. I have no intentions of supporting 
NFSv2 or NFSv3 with this security label document. If someone else wishes 
to do so they should feel free to give it a go.

    to assign the subject security attribute based on their
    authentication credentials and/or associated network attributes (e.g.
    IP address, network interface).

Tom: And must it make this same choice if it has a MAC aware NFSv4 
client which
is also making NFSv3 requests?

Dave: I believe this requirement was for when the NFSv4 client was not 
MAC aware. However the server should be able to restrict the set of 
labels a MAC aware NFSv4 client is able to assert.

----

---

From: sfaibish <[email-masked]>
Date: Mon, 28 Mar 2011 08:58:47 -0400

> difficult time telling the difference between section 2.1 and 2.3.
What I would recommend in section 2 is to present the usecases that
the draft address. Requirements should be drawn from the usecases.
Perhaps restructuring to put the usecases section befroe requirement
section. But I would merge the minimum requirements into the doc
draft-quigley-nfsv4-sec-label-03.txt and remove this document.

> numbers are off as well so I have to fix that up.
Again just summarize and merge into draft-quigley-nfsv4-sec-label-03.txt.

> atleast the basis is there for my customers to get what they need.
Just add language in draft-quigley-nfsv4-sec-label-03.txt to cover
the spec. You need also xdr definitions.

> it being disabled if callback support is not available. This would be a  
Next version for Quebec must have the correct format and concrete  
definitions
of the attributes including 2 fields and max length all in xdr format.

> pretty trivial as its just an integer and an opaque field.
I thought you presented at BAT but you didn't find the ppt. Must
be included in the next draft. Actually there are 2 fields: LFS and
security attribute in the opaque and an integer. No @ please.
In fact this is an common method to use the opaque for the
attribute while LSF field will define the opaque content.

> the structure of the opaque fields.
My understanding is that the LFS will define the content of the opaque
and not use external standard even if the LFS uses a certain standard.
In the I-D you may use a pointer to the external document but include
the definition. I would refrain for using yet another document for
the definition. You should rather define the framework and allow
for multiple formats.

> from one label set to another. The format of the label and the actual
I would rather prefer to define the framework to include all the local
formats. Not sure that I would like to have any DOI and/or translation
between differnt formats; rather a monolithic use on one site. No mixed
environments. Leave it for next minorversion.

> on that and left that decision up to the specific security label format.
I would rather prefer Tom's idea of using 2 fields but define the
relation between the field; first defines the content of the other
and they must match. This is slightly different from typical XDR
definitions.

> bound is yet for the opaque field though.
We cannot leave it opened; we need to define a maximum and perhaps
LFS will define the size according to the method used. You should
enumerate possible options and perhaps allow later extension to
additional options.

> business interpreting these security values. MAC systems are typically a
True unless you want the NFS server to reinforce MAC security.

> an access control decision based on it.
Well this model can only work if the security is reinforced in local FS
of the OS. Not sure it is true for NFS. At least this is the opinion of
Peter Staubach and mine. As a result we still have this problem that the
root and mount are in the clear and allows to see the root objects and  
names
which in local FS can be hidden.

> Dave: I'll make sure to add these in the next revision.
Not sure that what is true for local is extendable to NFS. Just be
careful. We need to discuss these in the calls preparing for Quebec.

> Dave: I'll make note of this in the document. It should be really easy  
I didn't think there is any performance impact different from any
attribute unless server reinforce the security.

> what mechanism is needed yet.
I would leave this entire section of guest/full outside of 4.2 and included
in the separate/complementary I-D.

> to do so they should feel free to give it a go.
We shouldn't worry with nfsv2 v3 except for backward compatibility.
But using named attributes can work for v2 and v3. This discussion is
relevant for server that reinforce security. I would recommend not
to address this case in 4.2. What I mean yes v2 and v3 clients could
get access to objects with MAC labels but not being able to
decode/interpret it. Of course it is a problem as a hacker can
get the MAC and interpreted it. It may be that the NFS server
will implement a special mechanism to prevent non-NFSv4 clients to
access objects that have MAC labels.

-- 
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: Mon, 28 Mar 2011 10:15:37 -0500

Regarding attribute change notification, it seems that volatile file
handles (i.e., marking the handle stale) seems almost like the best
approach here.  However, the way clients recover from stale
filehandles is not ideal (re-open by path).  In this case it ought to
be possible to add an operation by which to obtain a new filehandle
given a stale one.

So that's my proposal: add a new operation for re-validating
filehandles.  Inputs: old (stale) filehandle.  Outputs: new
filehandle.

This would also have the side-effect of enabling the use of
capabilities (in the traditional, non-Linux sense).

Nico
--

---

From: Dave Quigley <[email-masked]>
Date: Mon, 28 Mar 2011 11:59:37 -0400

> capabilities (in the traditional, non-Linux sense).
I like this proposal quite a bit. I find it a lot better than re-open by 
path since there is no telling if the file at that path has changed 
since the handle was originally granted to us. Since this really is just 
a metadata refresh and not a complete reopen then having the file change 
out from under us is a bad thing. Would this be a proposal in and of 
itself? Would we incorporate it into one of the other proposals?

Dave