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

[sfaibish <[e-mail]>]

On Mon, 28 Mar 2011 07:24:30 -0400, Dave Quigley <[e-mail]>  
wrote:

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

>
> ----
>
> 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.
Again just summarize and merge into draft-quigley-nfsv4-sec-label-03.txt.

>
> ----
>
>
>     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.
Just add language in draft-quigley-nfsv4-sec-label-03.txt to cover
the spec. You need also xdr definitions.

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

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

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


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

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

>
> ----
>
>
> 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
True unless you want the NFS server to reinforce MAC security.

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

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

>
> ---------
>
> 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.
I didn't think there is any performance impact different from any
attribute unless server reinforce the security.

> ---------
>
> 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.
I would leave this entire section of guest/full outside of 4.2 and included
in the separate/complementary I-D.

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



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



-- 
Best Regards

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

Phone: [phone]
Cellphone: 617-510-0422
Email : [e-mail]