Re: [nfsv4] WG last call complete for Requirements for Labeled NFS (still needs review)

On 5/1/12 3:53 PM, "Jarrett Lu" <jarrett.lu@oracle.com> wrote:

>Tom, Spencer,
>
>The document is in pretty good shape. My review comments and questions
>are as follows:

Thanks for the review.

>
>1. Section 3.3 list the following Security Services:
>- Authentication
>- Integrity
>- Privacy
>
>I'd expect Confidentiality be listed as well, as many MAC systems do
>provide confidentiality. Is Privacy used here to mean Confidentiality?

Yes, these are actually the offerings of krb5. So the context is the
network and not the MAC system.

>
>2. Through out the document, "local server policy" and "local client
>policy" are used. It may be better to eliminate the word "local" and
>just use "server policy" and "client policy". Server and client policies
>may not be strictly "local" as the policies can reside in a centralized,
>networked database, which could make policy configuration and
>administration easier.

Agree, "local" seems to be used instead of "its". Changed most of the
occurrences of "local".

>
>3. Section 3.4,
>In "If the LFS of a system changes", it's probably more clear to state
>"If the LFS supported on a system changes".
>An LFS, i.e. the label format mapping, probably won't change. A system
>may be reconfigured to support more or less LFSs.

Changed

>
>4. Section 3.6,
>    The content of the paragraph seems to suggest that the section title
>should be "Label Checking" instead of "Labeling".

Changed.

>
>5. Section 3.9,
>The example usage of LFS here is incorrect. LFS indicates what label
>format is used and how labels should be interpreted. It is not meant to
>be used to indicate server capability or its smartness in handling
>labels, such as "I'm only capable of storing and returning labels".

Ok, I had already changed this to be:

      In this case, a mixed and loosely administered network is assumed,
      where nodes may be running a variety of operating systems with
      different security mechanisms and security policies.  It is desired
      that network file servers be simply capable of storing and retrieving
      MAC security labels for clients which use such labels.  The LNFS
      protocol would be implemented here solely to enable transport of
      MAC security labels across the network.  It should be noted that in
      such an environment, overall security cannot be as strongly enforced
      as when the server is also enforcing, and that this scheme is aimed
at
      allowing MAC-capable clients to function with its MAC security
policy enabled rather
      than perhaps disabling it entirely.

But, in your registry document, we planned to reserve a LFS of 0 to mean
that the server is only capable of storing and returning labels.

>
>6. Section 4.2,
>double word "able to to protect".

Fixed.

>
>7. Section 4.5,
>The reference to case (a) should be removed.

Fixed.

>
>8. The draft referenced by this doc, "Registry Specification for MAC
>Security Label Formats", just expired. David Q and I should move that
>draft forward.
>
>Thanks.
>
>- Jarrett
>
>
>On 04/30/12 12:43 PM, Spencer Shepler wrote:
>> Thanks, Jarrett and Dave.  Please go ahead with the review and let me
>>know when you are finished.
>>
>> I would like to have one more volunteer that has been at least once
>>removed from the material for a read of flow of the document and to see
>>if there are any "missing"pieces.
>>
>> Volunteers?
>>
>> Spencer
>>
>> -----Original Message-----
>> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
>>Of Jarrett Lu
>> Sent: Monday, April 30, 2012 6:15 AM
>> To: Dave Quigley
>> Cc: nfsv4@ietf.org
>> Subject: Re: [nfsv4] WG last call complete for Requirements for Labeled
>>NFS (still needs review)
>>
>>
>> On Apr 30, 2012, at 5:13 AM, Dave Quigley<dpquigl@davequigley.com>
>>wrote:
>>
>>> On 4/30/2012 2:55 AM, Spencer Shepler wrote:
>>>> We have completed the last call for the Labeled NFS.
>>>>
>>>> While this is a short document and certainly has had a lot of
>>>> feedback over its lifetime, I do not believe this particular version
>>>> is ready to forward to our AD.
>>>>
>>>> I need to have at least two reviewers for this version before I will
>>>> shepherd it forward. Given this is a requirements document and it
>>>> deals with security and it is providing a path for our NFSv4.2 work,
>>>> I want it to be ready for the broader IESG review.
>>>>
>>>> Thanks in advance for the help.
>>>>
>>>> Spencer
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> nfsv4 mailing list
>>>> nfsv4@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>> Does this have to be revewiers besides myself? I can be one of them
>>>and we've had a review from Casey Schaufler on the SELinux list that I
>>>had forgotten to forward over here. If you'd like We could be the two.
>>>If someone else besides me needs to do it I'll get Steve Smalley to
>>>chime in on the draft.
>> I can be one of the reviewer too.
>>
>> - Jarrett
>>
>>
>>> Dave
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>>
>
>_______________________________________________
>nfsv4 mailing list
>nfsv4@ietf.org
>https://www.ietf.org/mailman/listinfo/nfsv4