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

From: sfaibish <[email-masked]>
Date: Thu, 14 Apr 2011 12:40:16 -0400

Rick,

You might want to join the call of today on LNFS of nfsv4 list.

/Sorin

Dial-in: 1-888-765-3653 (us)
               303-218-2659 (international)
      Id: 2787108

On Mon, 21 Mar 2011 18:33:11 -0400, Rick Macklem <[email-masked]>  
wrote:

> [stuff snipped]
>> >>
>> >>    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
>>
>
> 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
>
>> >>
>> >> ----
>> >>
>> >> 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
>
>

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