Subject: [nfsv4] ietf80 nfsv4 agenda version 0.1posted

From: Spencer Shepler <[email-masked]>
Date: Tue, 8 Mar 2011 19:37:58 +0000

I have posted an initial, very rough draft of our
agenda in the meeting materials.

Additions/changes welcome.

Spencer

---

From: "Sorin Faibish" <[email-masked]>
Date: Fri, 11 Mar 2011 21:40:38 -0500

Spencer,

I need 2 spots as I mentioned before for my 2 drafts:
pNFS block disk protection
pNFS Permission access check.

Additionally as discussed at the interrim I would like to have a spot for:
MAC Security Label Support for NFSv4
if possible on Wednesday to allow Dave Quigly to be on the phone.

I also noticed that the the draft of Dave Noveck:
draft-dnoveck-storage-control-00
is not included in the list of active I-Ds of the nfsv4:
https://datatracker.ietf.org/wg/nfsv4/

I would like to have a slot to discuss this draft perhaps also on  
Wednesday to
allow Dave Noveck to be on the phone.

Also could you tell me when is the dead line for non-00 drafts so I can  
get an
update of the storage control draft. I assume it is Monday 5PM PST.

Thank you

/Sorin

On Tue, 08 Mar 2011 14:37:58 -0500, Spencer Shepler  
<[email-masked]> wrote:

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

-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Spencer Shepler <[email-masked]>
Date: Sat, 12 Mar 2011 02:48:04 +0000

>pNFS block disk protection

Okay

>pNFS Permission access check.

Given that Tom has pulled this into his personal NFSv4.2 I-D do you still
need a slot or can you coordinate with Tom?  I don't have a preference;
whatever works best for the two of you.

>if possible on Wednesday to allow Dave Quigly to be on the phone.

As far as I know, there will be no phone access.
I assume there will be streaming audio/jabber room available.

>https://datatracker.ietf.org/wg/nfsv4/

The I-D is not listed because it does not have "nfsv4" in the file name.
The list is automatically generated by the IETF site.

>allow Dave Noveck to be on the phone.

Note that Pranoop has requested a slot for this and it is
Scheduled for Wednesday.  Please coordinate.

>update of the storage control draft. I assume it is Monday 5PM PST.

Non-00 I-Ds are due by:

2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT

As per:

http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80

---

From: "Sorin Faibish" <[email-masked]>
Date: Fri, 11 Mar 2011 22:04:53 -0500

> whatever works best for the two of you.
There were 2 small changes that I will include in the final draft but
I wanted to have 10 min discussion to validate these 2 changes for which
Dave Black had some doubts and we didn't clarified in BJ. But if the time
is at premium I can inclde them after Tom cuts 4.2.

> I assume there will be streaming audio/jabber room available.
Sure, this is what I meants some mean of life communication.

> The list is automatically generated by the IETF site.
I will fix this in next draft.

> Scheduled for Wednesday.  Please coordinate.
Perfect. I missed it as the name of the item was not same as the draft.

> http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80
Of course, since when I do read the ietf website. :) Thanks.
It will give me and Dave Quigly time for the MAC Security Label draft.

/Sorin

        EMC²
where information lives

---

From: Thomas Haynes <[email-masked]>
Date: Sat, 12 Mar 2011 11:33:45 -0600

On Mar 11, 2011, at 9:04 PM, Sorin Faibish wrote:

> On Fri, 11 Mar 2011 21:48:04 -0500, Spencer Shepler <[email-masked]> wrote:
> 
>> 
>> 

This has been cut.

See http://www.ietf.org/mail-archive/web/nfsv4/current/msg09035.html

I'd prefer we apply the changes there.

If you have an existing set of diffs, I'm willing to apply them.

But perhaps first you can post to the mailing list what the issues are and
we can discuss them first there.

I think that will give us a feel for whether we want to discuss them in Prague.

---

From: Dave Quigley <[email-masked]>
Date: Sat, 12 Mar 2011 12:34:56 -0500

>>>> Additions/changes welcome.
I will make sure to repose the MAC Security Label drafts either today or 
tomorrow. I'm working on something at the moment but once I'm done with 
that I'll rebuild the documents and resubmit them.

Dave

---

From: sfaibish <[email-masked]>
Date: Sat, 12 Mar 2011 13:43:17 -0500

> we can discuss them first there.
I will do this. I presented the issues in BJ and didn't got any comments.
I will try to send the proposed changes to the list.

> I think that will give us a feel for whether we want to discuss them in  
Sure. I missed to have the discussion at the interim meeting. Should of.

/Sorin

-- 
Best Regards

Sorin Faibish

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

---

From: Dave Quigley <[email-masked]>
Date: Mon, 14 Mar 2011 04:12:06 -0400

I have reposted all of the Labeled NFS related documents. This includes 
the requirements document, the specification document, the impact study, 
and the label format specification document. I spoke with Trond and he 
said he would be willing to present a few slides for us. At the 
Bake-A-Thon in Boston, Trond and I had spoken with Dan Walsh from Red 
Hat who provided some slides for real business cases he is getting from 
his customers (at least that's what my understanding was). So between my 
slides, the ones Dan sent, and the ones that Trond had wanted to present 
there should be a clear picture for the Labeled NFS work.

Dave

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 21 Mar 2011 14:15:16 -0500

On Mar 14, 2011, at 3:12 AM, Dave Quigley wrote:

> I have reposted all of the Labeled NFS related documents. This includes the requirements document, the specification document, the impact study, and the label format specification document. I spoke with Trond and he said he would be willing to present a few slides for us. At the Bake-A-Thon in Boston, Trond and I had spoken with Dan Walsh from Red Hat who provided some slides for real business cases he is getting from his customers (at least that's what my understanding was). So between my slides, the ones Dan sent, and the ones that Trond had wanted to present there should be a clear picture for the Labeled NFS work.
> 
> Dave

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

Section 2.3 sounds like hand waving.

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?

----

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.

----

   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

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.

----

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

----

===

                  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.

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

---

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.

You need the XDR to be provided here.

---

   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.

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

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

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.

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.

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

----

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.

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

----

----

====

           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:

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

---------

Section 3.2:

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

---------

Section 3.5:

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

----

Section 3.8

MLS is used and not defined:

 This is a common requirement of MLS-enabled systems,

----

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.

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?

   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.

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

-----

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
   to assign the subject security attribute based on their
   authentication credentials and/or associated network attributes (e.g.
   IP address, network interface).

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

----

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 21 Mar 2011 14:31:40 -0500

I'm resending these as the original subject was misleading for this topic.

---

From: sfaibish <[email-masked]>
Date: Mon, 21 Mar 2011 17:40:24 -0400

On Mon, 21 Mar 2011 15:31:40 -0400, Thomas Haynes <[email-masked]>  
wrote:

>>> I have reposted all of the Labeled NFS related documents. This  
>>> includes the requirements document, the specification document, the  
>>> impact study, and the label format specification document. I spoke  
>>> with Trond and he said he would be willing to present a few slides for  
>>> us. At the Bake-A-Thon in Boston, Trond and I had spoken with Dan  
>>> Walsh from Red Hat who provided some slides for real business cases he  
>>> is getting from his customers (at least that's what my understanding  
>>> was). So between my slides, the ones Dan sent, and the ones that Trond  
>>> had wanted to present there should be a clear picture for the Labeled  
>>> NFS work.
>>>
>>> Dave
this is correct. I will try to ask Peter Staubach to remind us the need.
I had previous discussions with him on this topic. If not I will ask
SteveD.

>> should start with Section 3 to get an idea of how to look at the 4  
I agree to this and ask Dave to make this clarification.

>> but is intended to be required in the next minorversion.
This was what I thought we should do but it is still not included in 4.2
unless somebody will pioneer it. I am trying to pick it up as I believe
it is needed and we have a prototype server implementation.
I will leave Dave to answer the remaining.

/Sorin

>> You need the XDR to be provided here.
I will try to come up with the xdr for next release.

>> I see this last is presented in  
>> draft-quigley-nfsv4-sec-label-requirements-03.txt.
>>
>> ----
>>
>>
>>    The character '@' is

-- 
Best Regards

Sorin Faibish

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

---

From: Rick Macklem <[email-masked]>
Date: Mon, 21 Mar 2011 18:33:11 -0400 (EDT)

[stuff snipped]
> >> I'd recommend changing this to state that it is optional in the
> >> first
> >> minorversion it debuts in,

In case it is of interest, I think FreeBSD would like to implement
a Mac label attribute at some point. Since work has just started on
4.1 implementation, that is a ways off.

rick

> >> I never saw how the changes for 3 were to be done. (BTW - please
> >> use
> >> <list style='numbers'> here.)
> >>
> >>
> >> ---
> >>
> >> Section 3:
> >>
> >> Are there any guidelines here for the opaque field? I.e., are there
> >> any
> >> existing standards it
> >> must adhere to?
> >>
> >> If the answer is that they are site dependent, what happens if
> >> multiple
> >> implementations try
> >> What is the size of the LFS and what is the size of the opaque
> >> section?
> >> If it
> >> I'm confused here, neither the client nor server can make a
> >> decision.
> >> So what is meant by the
> >> "host system"?
> >>
> >>
> >> ----
> >>
> >> ----
> >>
> >> ====
> >>
> >> We need some references here and the approaches they took. I.e.,
> >> while
> >> the limitations are
> >> Different terms are used for Full Mode and Guest Mode in the
> >> different
> >> documents.
> >> 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
> >> I find this vague. We should enumerate the other methods and
> >> recommend
> >> that
> >> they be deprecated.
> >>
> >> -----
> >>
> >> One thing I find missing here is a discussion of what the server
> >> should
> >> do if the
> >> And must it make this same choice if it has a MAC aware NFSv4
> >> client
> >> which

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 23 Mar 2011 10:34:06 -0500

Thanks Peter, that was the use case I remember hearing about.

On Mar 23, 2011, at 9:56 AM, <[email-masked]> <[email-masked]> wrote:

> If I remember correctly, SELinux was one of the prime consumers of this technology.  Without this support, it would be impossible to run a diskless system, which uses NFS for the root file system, and continue to be protected in the same fashion as more traditional disk based root file systems.
> 
> I am sure that there are other uses for the support as well.
> 
> 	Thanx...
> 
> 		ps
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of sfaibish
> Sent: Monday, March 21, 2011 5:40 PM
> To: Thomas Haynes
> Cc: [email-masked]; Trond Myklebust
> Subject: Re: [nfsv4] Labeled NFS comments (resend)
>

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 10:56:46 -0400

Thanx...

		ps

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of sfaibish
Sent: Monday, March 21, 2011 5:40 PM
To: Thomas Haynes
Cc: [email-masked]; Trond Myklebust
Subject: Re: [nfsv4] Labeled NFS comments (resend)

/Sorin

-- 
Best Regards

Sorin Faibish

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

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 23 Mar 2011 17:20:46 -0500

On Mar 23, 2011, at 1:01 PM, Daniel J Walsh wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> That is really not the use case we are most concerned about.  We really
> need labeled nfs for secure virtualization.
> 
> svirt/libvirt pick a label before starting a virtual machine, it then
> labels all images related to the virtual machine and starts the virtual
> machine with a label to match.
> 
> If the file system does not support labeling, we have to either allow
> all virtual machines full access to the default type of the file system
> (nfs_t) or allow no access.   Currently we are telling people to not use
> NFS if you are running virtual machines, and to try iscsi.

So different machines would get different labels? I.e., different
levels of access to the file system?

And this is a good overview of a typical system?

http://namei.org/presentations/svirt-lca-2009.pdf