Re: [nfsv4] NFSv4.2 work items

["Mike Eisler" <mre-ietf at eisler.com>]

David,

Thanks for your comments.

I hope in
 http://www.ietf.org/internet-drafts/draft-eisler-nfsv4-minorversion-2-requirements-02.txt

these have been addressed.

I have also added links to I-Ds that have been posted that propose to
address the requirements listed in
draft-eisler-nfsv4-minorversion-2-requirements .

On Wed, October 21, 2009 9:16 am, David P. Quigley wrote:
> I have some comments for the text in the compliance section. There are
> several points to get across in this section.
>
> It is important to note that the purpose of Mandatory Access Controls
> isn't just to determine who can view the data but also who and by what
> means that data can be modified. For example let's say in your
> enterprise data of an certain type is only supposed to be modified by
> one special purpose application. With security labels and the
> appropriate MAC model/protections you can enforce the security goal that
> only that particular application has the ability to modify that data.
>
> Second while it is important to note that ACLs are discretionary and
> that is a major problem when trying to enforce certain security goals
> its also important to note that they are only based on users. This means
> that they can't confine malicious and/or flawed software from running
> with the full privileges of the user executing the software. Security
> labels on file and also the process label transport that will be
> provided by rpcsecgssv3 allows for this type of confinement among other
> things.
>
> The end of the first paragraph specifically calls out that two object
> labels must match for an access to be allowed. While you could have a
> MAC model that implements this security goal, in general this usually
> isn't the case. MLS uses an ordered dominance relationship to determine
> what subjects can have access to what objects. The text implies that the
> equality constraint here is a requirement. I think it would be better to
> put "When the labels of two objects are authorized by the security
> policy" or something along those lines instead. This removes the strict
> equality requirement and allows for flexibility by saying that it is up
> to the particular MAC model being implemented to determine the
> relationship of those labels and whether access should be allowed or
> denied. With that change it would be appropriate to use maybe Secret and
> Top Secret in the example instead and make a note that MLS uses a
> dominance relationship.
>
> The last point that I think should be made is that currently the choice
> exists of whether I should have strong security protections in the form
> of MAC in the enterprise or should I use NFS. This is a problem because
> I believe both of these technologies are very important to increasing
> the security of enterprise environments. I think a brief mention that
> having the ability to label file objects on the NFS server and have the
> server apply an access policy to them while also enabling the client to
> apply access policy on top of that (or vice versa) enables end to end
> protections which are very important. Think of the scenario where you
> have 2 clients accessing that special data I mentioned earlier. Unless
> the server can say in addition to the client that only the special
> purpose application can modify that data it is possible for the other
> client that may not have that security policy to modify that data
> without knowledge of the first client.
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>


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