[nfsv4] Response to Labeled NFS Document comments.

[Dave Quigley <[e-mail]>]

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.

----