Subject: Re: [nfsv4] FW: Labeled NFS comments (resend)

From: sfaibish <[email-masked]>
Date: Wed, 23 Mar 2011 15:34:29 -0400

I had a similar uescase for VMware and I discussed this with
Jerret Lu an Dave as my major usecases. Now about the draft
itself I am of the opinion that we need to simplify the
draft in order to make it more useful for the above usecases.
This will make easier the decision to include it in 4.2. I would
like to continue the weekly calls to work on this if there is
interest of at least 5 people except me and Dave in this. The
target should be to have a more reasonable draft by Quebec
City ietf81 meeting.

/Sorin

> -----Original Message-----
> From: Daniel J Walsh [mailto:[email-masked]]
> Sent: Wednesday, March 23, 2011 2:02 PM
> To: Thomas Haynes
> Cc: Staubach, Peter; faibish, sorin; [email-masked];  
> [email-masked]
> Subject: Re: [nfsv4] Labeled NFS comments (resend)
>
> -----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.
>
> On 03/23/2011 11:34 AM, Thomas Haynes wrote:
>> 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)
>>>
>>> On Mon, 21 Mar 2011 15:31:40 -0400, Thomas Haynes <[email-masked]>
>>> wrote:
>>>
>>>> I'm resending these as the original subject was misleading for this
>>>> topic.
>>>>
>>>>
>>>> On Mar 21, 2011, at 2:15 PM, Thomas Haynes wrote:
>>>>
>>>>>
>>>>> 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
>>>>>> _______________________________________________
>>>>>> nfsv4 mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>>>
>>>>>
>>>>>                 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?
>>> 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.
>>>
>>>>>
>>>>> ----
>>>>>
>>>>> 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.
>>> I agree to this and ask Dave to make this clarification.
>>>
>>>>>
>>>>> ----
>>>>>
>>>>>
>>>>>   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.
>>> 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
>>>
>>>>>
>>>>> ----
>>>>>
>>>>> 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.
>>> I will try to come up with the xdr for next release.
>>>
>>>>>
>>>>> ---
>>>>>
>>>>>
>>>>>
>>>>>   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?
>>>>>
>>>>> ----
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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-249-5745
>>> Cellphone: 617-510-0422
>>> Email : [email-masked]
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2KNYgACgkQrlYvE4MpobPLkQCgj7k8ASewMkqi9neFkk7aLDYA
> lO4AoJsPbYgbSrTCZOotlFXY5RX7v78d
> =j8yD
> -----END PGP SIGNATURE-----
>
>

-- 
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: Thomas Haynes <[email-masked]>
Date: Wed, 23 Mar 2011 16:28:58 -0500

Sorin,

If the intent is to get it into NFSv4.2 and if we wait until
IETF81 to have a reasonable draft, then I'm afraid this
feature has missed the train.

By that timeframe, we'll want something much more
mature than 'reasonable'.

I think there is a lot of overlap in the 3 I-Ds available. And
they could easily become one.

I'm willing to meet weekly to get advanced.

Thanks,
Tom

On Mar 23, 2011, at 2:34 PM, sfaibish wrote:

>> Cc: Staubach, Peter; faibish, sorin; [email-masked]; [email-masked]
>>> 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.
>>>> 
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of sfaibish
>>>>>>> with Trond and he said he would be willing to present a few slides for
>>>>>>> Walsh from Red Hat who provided some slides for real business cases he
>>>>>>> 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
>>>>>> Perhaps add a section with the new requirements coming out of Red Hat?
>>>>>> I.e.,
>>>> this is correct. I will try to ask Peter Staubach to remind us the need.
>>>>>> I would have liked to have seen something in the email stating that the
>>>>>> reader
>>>>>>  protocol changes to NFSv4 in the form of a new optional to implement
>>>> This was what I thought we should do but it is still not included in 4.2
>>>>>>  o  Server must provide a mechanism for notifying clients of attribute
>>>>>>  These four requirements are key to the system with only requirements
>>>>>>  attribute.  It is the responsibility of the endpoints to consume the
>>>>>> 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
>>>>>> This is where the XDR would help. Why do we need the '@' symbol when the
>>>>>> What is the size of the LFS and what is the size of the opaque section?
>>>>>> If it
>>>>>>  Without a method for providing per file-object labeling as described
>>>>>>  file systems that lack labeling attributes.  While this allows policy
>>>>>> 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.
>>>>>>  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
>>>>>> 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
>>>>>>  authentication credentials and/or associated network attributes (e.g.

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 23 Mar 2011 16:35:41 -0500

> I'm willing to meet weekly to get advanced.

I wonder how many people will realize I missed including "it"?

I'm willing to meet weekly to get "it" advanced!

:->

---

From: Nico Williams <[email-masked]>
Date: Wed, 23 Mar 2011 19:44:55 -0500

> mature than 'reasonable'.

I'll say it one more time: the train model is awful.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 24 Mar 2011 01:06:36 +0000

Tom and I discussed his comments below.

Let me rephrase.

Don't put off for tomorrow what can be done today.

-and-

Perfection is not required of individual I-Ds before their inclusion
into the mainline NFSv4.2 I-D.  All major issues for an item should
be discussed, resolved and documented.  The personal I-Ds will be used
as a guide to determine rough consensus.

Finally, IETF 81 is not the cutoff for inclusion of content in NFSv4.2.

Spencer

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Haynes
> Sent: Wednesday, March 23, 2011 2:29 PM
> To: sfaibish
> Cc: Rick Macklem; Staubach, Peter; [email-masked]; nfsv4 list; Trond
> Myklebust
> IETF81 to have a reasonable draft, then I'm afraid this feature has missed
> the train.
> 
> By that timeframe, we'll want something much more mature than
> 'reasonable'.
> 
> I think there is a lot of overlap in the 3 I-Ds available. And they could
> easily become one.
> 
> > I had a similar uescase for VMware and I discussed this with Jerret Lu
> > an Dave as my major usecases. Now about the draft itself I am of the
> > opinion that we need to simplify the draft in order to make it more
> > useful for the above usecases.
> > This will make easier the decision to include it in 4.2. I would like
> > to continue the weekly calls to work on this if there is interest of
> > at least 5 people except me and Dave in this. The target should be to
> > have a more reasonable draft by Quebec City ietf81 meeting.
> >
> > /Sorin
> >
> >> That is really not the use case we are most concerned about.  We
> >> really need labeled nfs for secure virtualization.
> >>
> >> labels all images related to the virtual machine and starts the
> >> virtual machine with a label to match.
> >>
> 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'm resending these as the original subject was misleading for
> >>>>> this topic.
> >>>>>
> >>>>>
> >>>>>>> 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
> >>>> I had previous discussions with him on this topic. If not I will
> >>>> ask SteveD.
> >>>>
> >>>>>>
> >>>>>> ----
> >>>>>>
> >>>>>> 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.
> >>>> 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.
> >>>>>> Section 4. Just state that this entire document addresses
> >>>>>> security concerns.
> >>>>>>
> >>>>>> ----
> >>>>>>
> >>>>>> ===
> >>>>>>
> >>>>>> required to provide security attribute information to NFSv4
> >>>>>> clients  and servers.  This mechanism has the following
> requirements:
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> 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?
> >>>>>>
> >>>>>> multiple implementations try to share the same server?
> >>>>>>
> >>>>>>  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.
> >>>>>>
> >>>>>>  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.
> >>>>>>
> >>>>>> 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:
> >>>>>>
> >>>>>> 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 documents.
> >>>>>>  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.
> >>>>>>
> >>>>>> recommend that they be deprecated.
> >>>>>>
> >>>>>> -----
> >>>>>>
> >>>>>> 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.
> >>>>>> 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: Wed, 23 Mar 2011 20:55:17 -0500

> Finally, IETF 81 is not the cutoff for inclusion of content in NFSv4.2.

Heh, I hadn't realized I was saying that.

My focus was mainly on don't work on getting it into NFSv4.2 I-D, work
on getting it done. If it has enough energy to get into NFSv4.2 I-D,
that should be evident when we meet in Prague.

If I recall right, in Sunnyvale, this feature lacked a clear champion
and more use cases. I've heard David say that both Trond and
Sorin have been helping out. We've also had two additional use
cases pop out of the wood work in the last couple of days.

If we come away from Prague with the intent to bring it into NFSv4.2 I-D,
then we start work on getting it into the spec and we do not work
on the personal I-Ds.

And I'm more than willing to attend weekly meetings on it.

---

From: Nico Williams <[email-masked]>
Date: Wed, 23 Mar 2011 20:59:07 -0500

> I'll say it one more time: the train model is awful.

I should clarify.  A model of protocol extensibility where feature
sets are negotiated by version numbers, where the version numbers are
monotonically increasing and the WG works on only one new version at a
time is a WG productivity disaster.

The reason is that the "train" either keeps getting delayed from
arrival at its final destination due to frequent stops so others can
get on the train, or some features must wait until the next train
(which invariably will take a long time to arrive).

I don't know of any other major protocol or WG in the IETF that uses this model.

IPv6?  No, there won't be an IPv7.  All new features are negotiable.

TCP?  Same thing.

IPsec (IKE in particular, but also ESP/AH)? LDAP?  IMAP?  Kerberos?
PKIX?  TLS?  SSHv2?  No, no, no, no, no, no, and no.

Maybe in the sub-IP area they use version trains?

Note that some of the protocols I list do have major and/or minor
version numbers, and some times those get bumped, but features rarely
have to wait for version bumps.

I think the WG should make an a la carte model of extensibility a
requirement for the nearest practical minor version change.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 23 Mar 2011 21:15:22 -0500

> requirement for the nearest practical minor version change.

Nico,

I think the biggest challenge the WG has is getting away from the
big feature model. We know that doesn't work for us and it leads
to horrible production delays.

So what I like about our adoption of the train model is that we have
a hard date in mind and if we stick to it, we will have a clean break
from the big feature model.

But you are right that if all of the WG focuses on this release, then
it will suck the productivity out of the next release. I think we are
closer to an a la carte model than we realize. I certainly got that
feeling as we picked items to make it to this release.

I think the gap between our model and what you are proposing is
that we were still suffering from the big feature model (and not
getting 3530bis done) and most of the energy was sucked out
of the individual drafts that were out there. I.e., everything was
on hold until we completed our prior WG charter and we could
really not dive into new features.

I'm hoping our new approach will allow things to not stall and
when it comes to the next release, there will be drafts ready to
naturally fall into what we are going to call the next minor release.

Tom

---

From: Nico Williams <[email-masked]>
Date: Wed, 23 Mar 2011 21:46:58 -0500

On Wed, Mar 23, 2011 at 9:15 PM, Thomas Haynes <[email-masked]> wrote:
>>[...]

Both are train models.  One has stops before the final stop, the other
doesn't.  Both are productivity disasters.

> feeling as we picked items to make it to this release.

We've always been closer to an a la carte model than we thought, and
yet we've never gone there.

I'm not an implementor now, thus it seems difficult for me to insist
that a la carte negotiation be the critical feature of 4.2.  I hope,
for the WG's sake, that an implementor does insist on it.  (Of course,
not being an implementor doesn't mean I can't ask for this, but being
an implementor would, I think, make it more likely to get adotion.)

> really not dive into new features.

But who is "we"?  What would it take to get a la carte done?  Why is
no one doing it?  Is it because none of the key participants mind the
low productivity?  Or is it because none wants to do that work because
it's not critical to their needs, thus a tragedy of the commons
ensues?  I suspect its' the latter, and if so we have a lesson: a la
carte must be in from the get-go.

> naturally fall into what we are going to call the next minor release.

The "new" approach is the same as the old.  Witness our being told to
get our I-Ds ready ASAP or lose out.  Losing out means not having a
clue when the desired features will ship.  Only getting 4.2 _and_ 4.3
done very quickly will prove that the new approach is significantly
different from the old, and I don't see that happening.  We know a la
carte negotiation of features works for all other Internet protocols,
so why not do it for NFSv4??  What would it take to get this into the
4.2 train so it's done once and for all?

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 23 Mar 2011 23:28:26 -0500

On Mar 23, 2011, at 9:46 PM, Nico Williams wrote:

>  We know a la
> so why not do it for NFSv4??  

Okay, I totally read 'a la carte' in the sense of what we picked
for the I-D and not in the sense of negotiation.

While I think I know what you mean now, please define what
you mean here. Assume I'm not the only one here who does not
know how the other Internet protocols define this.

---

From: Robert Gordon <[email-masked]>
Date: Thu, 24 Mar 2011 00:58:18 -0500

I can detail what i thought Nico meant, if that helps. 

Lets say i want to define a narrow feature (the example is just an
example) in NFSv4.x that allows the client to tell the server it is
going offline for a bit, but it wants all it's state preserved, and
when the client re-connects to the server it will flush updates. 
Lets say it's called the Client Disconnected Mode (CDM). 

Not all servers will implement the CDM feature, and as an implementor 
i don't want it bound to a specific minor version, where it has to wait
for other features. 

I think that Nico is suggesting that 4.2 should just provide a mechanism 
where by the client and server can negotiate supported features, i'd see 
it as a variation of section 4 of Novecks (et al) storage-control draft. 

Robert.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 24 Mar 2011 09:20:18 -0400

> it as a variation of section 4 of Novecks (et al) storage-control draft. 

All new features that go into 4.2 are supposed to be optional. Feature
negotiation is therefore not (optional)...

If you mean that we shouldn't ever make any new 4.x features mandatory
to implement after they have proved themselves to be useful through the
optional-to-implement mechanism, then I disagree; that would be too
limiting.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: sfaibish <[email-masked]>
Date: Thu, 24 Mar 2011 10:00:07 -0400

> negotiation is therefore not (optional)...
But this is also true for 5661; not all the servers/clients implement all
the features. Any protocols are like this. Aren't they? In fact the value
of different protocol features is judged by adoption.

> optional-to-implement mechanism, then I disagree; that would be too
I didn't think that the secure NFS is ever mandatory if we are still
discussing around this as started by me and Tom.

/Sorin

-- 
Best Regards

Sorin Faibish

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 24 Mar 2011 10:31:11 -0400

> of different protocol features is judged by adoption.

No. 5661 violated the above rule by mandating the implementation of
sessions. If we had gone strictly by the minor version rules, then they
would have been optional, as would _all_ other new features added by
4.1.

> discussing around this as started by me and Tom.

What secure NFS mechanism?

RPCSEC_GSS has been mandatory to implement since RFC3530 (i.e. minor
version 0) so it falls outside the minor version rules.

If you mean the SSV mechanism, then I suggest you look again. It is
listed as 'REQ' (required to implement) in the table in section 17 of
RFC5661.

NetApp

---

From: Tom Haynes <[email-masked]>
Date: Thu, 24 Mar 2011 10:12:23 -0500

> What secure NFS mechanism?

He means the Labeled NFS work. The first release it appears in, it could
probably be marked as RECOMMENDED. The next release, we could upgrade it to
REQUIRED.

The personal I-Ds had defined it to be optional.

The spec states this:

   12.  Except for infrastructural changes, a minor version must not
        introduce REQUIRED new features.

...

        Allowing infrastructural features to be RECOMMENDED or OPTIONAL
        complicates implementation of the minor version.

-- 
Tom Haynes
ex-cfb

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 24 Mar 2011 13:48:27 -0400

> optional-to-implement mechanism, then I disagree; that would be too

Yeah, agreed, my understanding is that we intend to follow the minor
version rules strictly and be conservative about converting features to
mandatory-to-implement.  In which case we already have Nico's a la carte
model.

All the existing proposals seem to have figured out how to make their
new features optional, so there doesn't appear to be a need for any new
protocol mechanism to allow that.

--b.

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Mar 2011 13:31:06 -0500

> mandatory-to-implement.  In which case we already have Nico's a la carte

OK, so I misunderstood badly then.  My bad.

So then it's not terribly important whether any one feature is in 4.2
or not?  Good!

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 24 Mar 2011 13:36:35 -0500

> So then it's not terribly important whether any one feature is in 4.2

Unless there are dependencies:

1) server-side copy benefits from RPCSEC_GSSv3 but doesn't need it

2) Labeled NFS demands RPCSEC_GSSv3

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Mar 2011 13:42:33 -0500

> 2) Labeled NFS demands RPCSEC_GSSv3

But (2) could be optional itself.  It should be OK to have an optional
facility depend on another.

Moreover, RPCSEC_GSSv3 is a layer below NFS proper, which probably
simplifies the negotiation picture for (2).

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 24 Mar 2011 14:53:52 -0400

> 2) Labeled NFS demands RPCSEC_GSSv3

Sure, but dependencies do not make a particular feature mandatory to
implement either: that feature just becomes mandatory if you want to
implement the feature that depends on it.

IOW: I can decide not to implement Labeled NFS, in which case
RPCSEC_GSSv3 also becomes optional...

NetApp

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Mar 2011 14:01:18 -0500

> implement the feature that depends on it.

I don't quite parse that.  An optional feature can certainly depend on
another optional feature without that dependency requiring an upgraqde
of one of those features to required.  If the WG has a rule to the
contrary, well, I'd be curious to see why it does.

> RPCSEC_GSSv3 also becomes optional...

Well, yeah.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 24 Mar 2011 15:11:37 -0400

> contrary, well, I'd be curious to see why it does.

Sorry. I mean to say that if feature A depends on a feature B to the
point where you cannot implement feature A without feature B, then that
still means that feature A+B can (and SHOULD) be optional to implement.

If, OTOH, feature A can be implemented without feature B, then it is
still up to us to decide whether or not we want to make it so. I can't
see that the train model changes anything here...

NetApp

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 28 Mar 2011 01:34:36 -0700

> 4.2 train so it's done once and for all?

"Losing" means your feature waits a year. So spend that time getting it
ready for the next train.

I haven't seen a concrete proposal for "ala carte", and we've been at this
since 1996.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Dave Quigley <[email-masked]>
Date: Mon, 28 Mar 2011 05:46:38 -0400

There should be a lot of overlap in the 3 I-Ds. They were all asked for 
in sucession at different IETF meetings and for building on one another. 
I had a large initial document which basically was a major portion of 
those 3 documents all in one I-D and Tim Polk advised me that such a 
large document wouldn't be very friendly to WG review. Granted this was 
the second meeting I attended where a lot of people looked at Labeled 
NFS and had no idea what to make of it. There might still be a lot of 
people that have no idea what to make of it but at least now there are 
quite a few that do and understand its importance.

Dave

On 3/23/2011 5:28 PM, Thomas Haynes wrote:
>>>> On Mar 23, 2011, at 9:56 AM,<[email-masked]>  <[email-masked]>  wrote:
>>>>
>>>>> On Mon, 21 Mar 2011 15:31:40 -0400, Thomas Haynes<[email-masked]>
>>>>> wrote:
>>>>>

---

From: Dave Quigley <[email-masked]>
Date: Mon, 28 Mar 2011 05:54:58 -0400

>          complicates implementation of the minor version.
When initially deciding on whether to make this a Mandatory Attribute or 
a Recommended attribute it seemed that it is squarely in the recommended 
category. There are quite a few customers for this technology both in 
governments around the world and in private industry. However to force 
everyone to be able to handle the extra infrastructure for dealing with 
this (although I guess a null label format or toggling off support isn't 
that difficult) seems a bit much. I know for a fact that there is a 
market for this feature because I've had customers and Red Hat also has 
customers (with probably more people I'm not aware of) that have 
personally come to us and said I need security labels on my file but I 
have a Netapp or EMC appliance. If you think Mandatory Access Controls 
are something relegated to government only then that is a big mistake. 
The NYSE runs SELinux on their servers and from what I understand their 
solution to file labeling is just to mount things using iSCSI instead of 
relying on an actual file system. Red Hat has many customers in the same 
boat which would rather be running NFSv4 off of their storage appliances 
but have to use iSCSI instead because they can't get their security 
labeling. If those reasons make a strong case to make it Mandatory at 
some point then I'm all for making it Mandatory. However I would also be 
happy with making it a recommended attribute as well.

Dave

---

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

Number 2 is not necessarily true. There are several documents that would 
make a completely featured Labeled NFS. The two documents of importance 
are RPCSECGSSv3 and the MAC Security Label Attribute documents. This are 
two parts that actually are independent of each other.  One of the 
documents is how you would go about using these technologies for 
implementing some sort of security model across your enterprise. That 
uses both of these but they aren't strictly required. For now I would be 
happy with just the recommended attribute for the security labels on 
files. Its icing on the cake to me that other people would benefit from 
RPCSEC_GSSv3 and are willing to help move it along the process. I really 
think it might be time to revisit all 4 documents and figure out what we 
want a Labeled NFS document to say. The reason there are so many 
documents is because the working group needed to see a complete picture 
before deciding to work on Labeled NFS so there is a lot of information 
there. we can pair it down to a fewer number of documents or consolidate 
them into one larger but more complete document (instead of having to 
read 3 different ones).

Dave

---

From: sfaibish <[email-masked]>
Date: Mon, 28 Mar 2011 07:51:28 -0400

> quite a few that do and understand its importance.
As a general observation we should include all the components in one
document not necessarily the sum of the 3 documents but rather a merge
of all the information in a single I-D with limited size. All said
in order to have a compact feature to be included in 4.2 I will take a
step approach. In first step I propose to include just a new capability
flag for the server and client to agree on support of MAC at mount
during the EXCHANGE_ID and the label capability in either named
attributes and extend attributes. I will leave the security reinforcement
to the client and the server will not reinforce the check and leave the
support for server reinforcement as an option. This will work in trusted
environments only unless the server chose to implement the reinforcement.
Of course we will include all the needed tools to allow reinforcement
but will state that server MAY reinforce.

Additional to this we will also make the different levels of security
to the client to implement and the server will just have any RPC
enablement if needed. Moreover I would be inclined to use IPSEC
if there is any need for reinforcement of the access to the root.
Will not require RPCSEC_GSSv3 in first phase and leave it to 4.3.
I will not ask for MAC label to be a mandatory feature for 4.2.
We will use the getattr and setattr and modify them to support MAC
security. We may also modify to support directory delegation
if this is of interest of the WG. More than this I will define
the classes of objects that should reinforce MAC and limit the
draft to directories and files/links. I am not sure we want to
include this attribute in the inode. We may also want to
support named attributes as well as extended attributes
w/o specifiying the extra security required by the named
attributes model.

This is my general plan for the next draft to be finished
before Quebec. After discussions with Dave Black, Peter Staubach
and others from Red Hat this seems the best way to have it in 4.2.
I will appreciate if you will work with me along these lines
and Jerret will help as well. This is our best shot at it. You
can eventualy move all the rest in a private I-D that will run
outside of the 4.2 with the goal to make it in a future version
4.3 maybe.

All, please comment on my proposal (if it makes sense) as I would
like to present it on Wednesday WG meeting for discussions.

/Sorin

>>>> really
>>>>>> 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.
>>>>>>
>>>>>>>> that the
>>>>>>>> first
>>>>>> in 4.2
>>>>>>>> clients
>>>>>>>> there any
>>>>>>>> when the
>>>>>>>> directly
>>>>>>>> performance
>>>>>>>> is
>>>>>>>> tell the
>>>>>>>> support
>>>>>>>> client
>>> -- Best Regards

-- 
Best Regards

Sorin Faibish

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

---

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

> a Recommended attribute it seemed that it is squarely in the recommended
I guess the issue here was the name: Mandatory Access Control. We can make
it an optional for the extention of the attributes but mandatory to
announce the capability/support, i.e. a server that support MAC security
to be able to announce it during EXCHANGE_ID at mount time.

> governments around the world and in private industry. However to force
I think at this phase we agreed that there is enough traction to include
it in 4.2. No need to explain as we have several usecases.

> that difficult) seems a bit much. I know for a fact that there is a
If the agreement is that this is a needed feature no need to justify
any addtional infrastructure to be added.

> are something relegated to government only then that is a big mistake.
I totally agree here and this is the reason to my motivation to just
include the needed hooks (minimum set) to allow client and server
implementation but make it optional. It can be used by government (with
possible extenssions to be added later) use as well as commercial use.

> relying on an actual file system. Red Hat has many customers in the same
This is a relevant usecase we need to include in the draft.

> labeling. If those reasons make a strong case to make it Mandatory at
This is already included usecase. We need to add the virtualization
usecase of James Morris.

> happy with making it a recommended attribute as well.
It is my goal to do exactly this.

/Sorin

-- 
Best Regards

Sorin Faibish

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

---

From: Benny Halevy <[email-masked]>
Date: Tue, 29 Mar 2011 06:16:56 +0200

> 4.2 train so it's done once and for all?

My guts feeling are with Nico on this issue.  I actually mentioned it in
the interim meeting in Sunnyvale and I agree that NFSv4.x could benefit
from a better, formal way to negotiate or discover optional features
rather than using the minor version as an indication of the available
set of features and their version and then probing certain operations or
attributes.

However, I'd like to remind that essentially the RPC protocol always
provided an "a la carte" model were each program under the RPC stack is
an optional independent feature that can advance at its own pace.
Yet, historically, the complexity of keeping a family of protocols -
NFS, MOUNT, LOCK, NFSACL - in sync with each other actually drove NFS
towards the other direction which was cramming them all together into
NFSv4 and forcing an ordered model on their progression.

Perhaps we went too far and there is a place for a official layer under
the NFS minor version so that features can be introduced and evolve
without depending on a single NFSv4 minor version.  The challenge here
to tame beast and provide a model that is:
- more scalable and extensible, yet
- simple for specification authors
- simple for implementers
- straight forward for administrators

If you think about it, the pnfs layout type extensibility model is one
example where the NFSv4.x layer functions as a transport layer for a
sub-protocol feature that is defined independently of NFSv4.x, within
its framework.  We've not seen this in action yet and there could be
compatibility challenges with old layout types and new NFS version or
vice verse, still specifying it this way created a true ecosystem and
opened up a huge window of opportunity.

<end of manifesto :)>

Benny

---

From: Dave Quigley <[email-masked]>
Date: Tue, 29 Mar 2011 21:25:45 -0400

On 3/28/2011 7:51 AM, sfaibish wrote:
> On Mon, 28 Mar 2011 05:46:38 -0400, Dave Quigley 
> <[email-masked]> wrote:
>
>> There should be a lot of overlap in the 3 I-Ds. They were all asked 
>> for in sucession at different IETF meetings and for building on one 
>> another. I had a large initial document which basically was a major 
>> portion of those 3 documents all in one I-D and Tim Polk advised me 
>> that such a large document wouldn't be very friendly to WG review. 
>> Granted this was the second meeting I attended where a lot of people 
>> looked at Labeled NFS and had no idea what to make of it. There might 
>> still be a lot of people that have no idea what to make of it but at 
>> least now there are quite a few that do and understand its importance.

Not to be argumentative but this is the exact opposite of how we evolved 
the specification over the last 3 years. This feature can not be a Named 
or Extended attribute. That was discussed and thrown out almost 3 years 
ago. It has to be a recommended attribute for many reasons. One of which 
is the need for atomically setting the label on file creation. I have no 
problem leaving RPCSEC_GSSv3 support out at the moment as it isn't vital 
to get initial support done. Also, I think there is a mismatch of 
terminology here. Mandatory Access Control is a type of access control. 
It has nothing at all to do with what type of file attribute we 
eventually choose (Recommended vs Mandatory). I paired down the support 
into two features once is a very simple two component field which is a 
piece of file metadata which we know how to do and we know how to do it 
well (look at all of the recommended attributes in the specification). 
The second is RPCSEC_GSSv3. Considering the file attribute isn't even 
interpreted by the NFSv4 client or server I don't know how I can make it 
more simple. I'm completely ok with just having the attribute for now 
and we can work on getting more complex usage scenarios integrated over 
time. However the file attribute alone is over 50% of a win if we can 
get this in. For people like Dan Walsh the file attribute is almost a 
100% solution for him,

We know how to implement recommended attributes and support for security 
labels will be negotiated when the client connects to the server. It 
sends a null request for getattr which returns all of the supported 
attributes. If security labels are in there and the client wants them it 
can keep the bit set for security label support. If it doesn't want them 
it can mask it out of its getattr request. The initial specification for 
4.2 should simply be the MAC recommended file attribute. That way we can 
support label change notification through the method Nico talked about 
for all of the other attributes and do it in an incremental step. If you 
want me to take the specification and remove all usage scenarios to make 
it simpler I can do that. However I don't know how I can get much 
simpler than this.

> w/o specifiying the extra security required by the named

So RPCSEC_GSSv3 and the mac attribute are two different mechanisms that 
aren't dependent on each other. Each would provide benefits on their 
own. I think for now we need to let Thomas handle RPCSEC_GSSv3 
separately from the MAC security attribute and just make sure that the 
feature still supports MAC labeling and privilege assertions like Nico 
and I initially discussed.

> like to present it on Wednesday WG meeting for discussions.

My proposal  for how to proceed is this. For NFSv4.2 we let Thomas 
handle RPCSEC_GSSv3 and we keep an eye on it to make sure it still 
supports our features. I trust Thomas to do the right thing with that 
draft and Nico and I can keep it in line with the main reason we (mostly 
Nico) came up with it in the first place. From our end the only feature 
being pushed by us is the MAC Security Label Recommended attribute. I am 
also still firmly in the camp that atleast initially and maybe even 
permenantly the MAC security label should be a recommended attribute. I 
don't want to force the overhead of it on people who don't want it and 
if we did a mandatory attribute I fear that is what would happen. I 
don't know how all implementation work but on Linux when you grab the 
root file handle you make a getattr call to it to discover the supported 
attributes. If the client doesn't want to support MAC attributes it will 
mask out the bit for it when making future getattr calls. The 
enforcement of the attribute is completely left up to the client. The 
only requirement I would have on the server is that if the client 
doesn't support labels but there are labels on the export then it should 
propogate the label from the parent directory on file creations.

So those are the features that I would include in 4.2. Once we get 
RPCSEC_GSSv3 and that in then we can talk about complex usage scenarios 
with server and client side enforcement. However just the paragraph I 
mentioned gets a 99% solution for a lot of the people who need the 
feature today. The extra stuff provided by RPCSEC_GSSv3  is for more 
advanced deployments.

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 30 Mar 2011 08:19:33 +0200

On Mar 28, 2011, at 1:51 PM, sfaibish <[email-masked]> wrote:

> On Mon, 28 Mar 2011 05:46:38 -0400, Dave Quigley <[email-masked]> wrote:
> 
>> There should be a lot of overlap in the 3 I-Ds. They were all asked for in sucession at different IETF meetings and for building on one another. I had a large initial document which basically was a major portion of those 3 documents all in one I-D and Tim Polk advised me that such a large document wouldn't be very friendly to WG review. Granted this was the second meeting I attended where a lot of people looked at Labeled NFS and had no idea what to make of it. There might still be a lot of people that have no idea what to make of it but at least now there are quite a few that do and understand its importance.

We need a generic approach and not just one geared towards Red Hat, and hence selinux. How much of the work that Dave did is geared towards making LNFS work in multiple frameworks?

---

From: Dave Quigley <[email-masked]>
Date: Wed, 30 Mar 2011 06:55:59 -0400

> We need a generic approach and not just one geared towards Red Hat, and hence selinux. How much of the work that Dave did is geared towards making LNFS work in multiple frameworks?

The mechanism is completely generic which is why it has taken so long to 
come up with and to get to this point. If I wanted a RedHat/SELinux 
specific solution I would have defined the label format. The reason why 
there is a LFS and an opaque field instead of just an SELinux security 
label is because it is generic.

---

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

> We need a generic approach and not just one geared towards Red Hat, and hence selinux. How much of the work that Dave did is geared towards making LNFS work in multiple frameworks?
To clarify a bit more. In the initial versions I was asked several times 
to pick a label format and I insisted on keeping the label format 
unspecified just so we could use any framework. The label format isn't 
the important part of the framework as much as the other properties of 
the attribute are. Any MAC system will need the ability to set labels on 
creation. It should have the choice if it desires to use information 
about the calling process in the access control decision (which our 
proposal allows for). The fact that NFS does not handle interpretation 
of these labels makes it generic as well. We've pushed interpretation 
and enforcement off to another system resource so we don't have to make 
NFSv4 have SELinux/Solaris TX specific information in the specification.

Dave

---

From: Dave Quigley <[email-masked]>
Date: Wed, 30 Mar 2011 08:35:59 -0400

On 3/30/2011 7:48 AM, Sorin Faibish wrote:
> I will not present this in the meeting today.
>
> On Mar 30, 2011, at 7:10 AM, Dave Quigley<[email-masked]>  wrote:
>
>> To clarify a bit more. In the initial versions I was asked several times to pick a label format and I insisted on keeping the label format unspecified just so we could use any framework. The label format isn't the important part of the framework as much as the other properties of the attribute are. Any MAC system will need the ability to set labels on creation. It should have the choice if it desires to use information about the calling process in the access control decision (which our proposal allows for). The fact that NFS does not handle interpretation of these labels makes it generic as well. We've pushed interpretation and enforcement off to another system resource so we don't have to make NFSv4 have SELinux/Solaris TX specific information in the specification.
>>
>> Dave
>>

I still think we need to talk about Labeled NFS at the meeting today. We 
need to talk about how to move it forward still.

Dave

---

From: Dave Quigley <[email-masked]>
Date: Wed, 30 Mar 2011 09:17:01 -0400

Ok,
    Please try to have someone on jabber for when the meeting starts. 
Are we running later? Has it moved rooms? The feed doesn't seem to have 
anything going on.

On 3/30/2011 8:57 AM, [email-masked] wrote:
>
> Not my slides.
>
> /Sorin
>
>
> ----- Original Message -----
> From: "Dave Quigley" <[email-masked]>
> To: "Sorin Faibish" <[email-masked]>
> Cc: "Tom Haynes" <[email-masked]>, "sfaibish" 
> <[email-masked]>, "<[email-masked]>" <[email-masked]>
> Sent: Wednesday, March 30, 2011 8:35:59 AM
> >>> We need a generic approach and not just one geared towards Red 
> Hat, and hence selinux. How much of the work that Dave did is geared 
> towards making LNFS work in multiple frameworks?
> >> To clarify a bit more. In the initial versions I was asked several 
> times to pick a label format and I insisted on keeping the label 
> format unspecified just so we could use any framework. The label 
> format isn't the important part of the framework as much as the other 
> properties of the attribute are. Any MAC system will need the ability 
> to set labels on creation. It should have the choice if it desires to 
> use information about the calling process in the access control 
> decision (which our proposal allows for). The fact that NFS does not 
> handle interpretation of these labels makes it generic as well. We've 
> pushed interpretation and enforcement off to another system resource 
> so we don't have to make NFSv4 have SELinux/Solaris TX specific 
> information in the specification.
> >>
> >> Dave
> >>
>

---

From: Brian Pawlowski <[email-masked]>
Date: Wed, 30 Mar 2011 06:27:59 -0700 (PDT)

I think we're in?

---

From: Dave Quigley <[email-masked]>
Date: Wed, 30 Mar 2011 09:33:33 -0400

> I think we're in?
I seem to have several conduits in the room now. Thanks to everyone for 
helping me participate remotely.

Dave

---

From: Nico Williams <[email-masked]>
Date: Wed, 30 Mar 2011 10:08:05 -0500

> ready for the next train.

Let me summarize then.  We have a protocol that can effectively
negotiate extensions a la carte but a process that does not allow the
WG (nor any other parties) to develop extensions a la carte.  Is that
a correct summary?

> I haven't seen a concrete proposal for "ala carte", and we've been at this

This WG does things rather differently from many others in the IETF.
I'm concerned that the current process for extending NFSv4 could
potentially be characterized as an artificial barrier to entry, and
that implementors could be said to be colluding via this forum to
maintain that barrier -- that is, I'm concerned that there may be
anti-trust issues here (IANAL, so maybe my concern is basless, but
maybe it isn't, so speak to your lawyers).  Note that this is not a
threat, but an idle thought -- my current business has nothing
whatever to do with NFSv4, and I don't know anyone who would complain
to the FTC or equivalent agencies elsewhere, nor do I know anyone
interested in bringing any sort of suit on this matter.  (I should
also point out that I never worked for the NFS team at Sun/Oracle, and
that I've no knowledge whatsoever regarding Sun/Oracle management's
views on this topic.)

Note too that there are competitors to NFSv4, and they benefit from
this WG doing what it can to slow down NFSv4 protocol evolution.

Personally, I think it's time for the WG to abandon the current minor
versioning if indeed my characterization of them in my first paragraph
above is correct.

Nico
--

---

From: Sorin Faibish <[email-masked]>
Date: Wed, 30 Mar 2011 07:48:37 -0400

---

From: [email-masked]
Date: Wed, 30 Mar 2011 12:57:38 +0000 (UTC)

Not my slides. 

/Sorin 

----- Original Message ----- 
From: "Dave Quigley" <[email-masked]> 
To: "Sorin Faibish" <[email-masked]> 
Cc: "Tom Haynes" <[email-masked]>, "sfaibish" <[email-masked]>, "<[email-masked]>" <[email-masked]> 
Sent: Wednesday, March 30, 2011 8:35:59 AM 
Subject: Re: [nfsv4] Labeled NFS comments (resend) 

Dave