Re: [secdir] SecDir Review of draft-ietf-nfsv4-labreqs

Yoav Nir <ynir@checkpoint.com> Sun, 03 November 2013 18:26 UTC

From: Yoav Nir <ynir@checkpoint.com>
To: "Haynes, Tom" <Tom.Haynes@netapp.com>
Thread-Topic: SecDir Review of draft-ietf-nfsv4-labreqs
Thread-Index: AQHO18c3l5Ocx4tIM0WjeGDw7jvwUJoS5PWAgADOSQA=
Date: Sun, 03 Nov 2013 18:26:12 +0000
Message-ID: <0665E0C6-DFB6-4CA5-B261-CB3AD27DEB50@checkpoint.com>
References: <FF6A9891-728D-4688-BE3D-663A2C1DF362@checkpoint.com> <ADA3E59C-A56A-486A-A527-67AA1E547912@netapp.com>
In-Reply-To: <ADA3E59C-A56A-486A-A527-67AA1E547912@netapp.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <94EA0D76F8840D4E96E5BE48E5F7AE9E@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-nfsv4-labreqs.all@tools.ietf.org" <draft-ietf-nfsv4-labreqs.all@tools.ietf.org>, The IESG <iesg@ietf.org>, "<secdir@ietf.org>" <secdir@ietf.org>
Subject: Re: [secdir] SecDir Review of draft-ietf-nfsv4-labreqs
Precedence: list

On Nov 2, 2013, at 2:07 PM, "Haynes, Tom" <Tom.Haynes@netapp.com> wrote:

> inline...
> 
> On Nov 2, 2013, at 5:29 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> 
>> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments ust like any other last call comments.
>> 
>> Short version: I think the draft is ready.
>> 
>> This draft is intended to be Informational. It does not specify any standard. Instead, it describes the operating environment and assumptions behind labeled NFS. 
>> 
>> Labeled NFS associates labels with resources (usually files) and processes, where the resources reside on a file server, while the resources run on a client. Such labels (Multi-Level Security is but one example) are then used as a basis for policy decisions. The draft is intended for people not familiar with NFS, and does a good job of explaining the different scenarios. For example, with a limited server, it is up to the client to decide about authorization for accessing resources, and the server functions solely as a store. This model is surprising to people familiar with, for example, web servers, where the resources are considered to belong to the server, and it is up to the server to make authorization decisions. Other NFS servers, called "MAC-functional" have authorization decisions on both client and server.
>> 
>> I found the draft to be well-written and informative.
>> 
>> I have a few comments, but I consider none of them show-stoppers:
>> 
>> - The introduction has this text: "DAC systems offer no real protection against malicious or flawed software due to each program running with the full permissions of the user executing it.". Put like that, this sentence is inflammatory. Discretionary Access Control protects you against unauthorized users running malicious software. It just doesn't protect against "good" users being tricked into running bad software.
>> 
> 
> Can rework....
> 
>> - Section 3.3 uses the term "opaque". This is a surprising term, considering this sentence about the opaque component: "The LFS component provides a mechanism for identifying the structure and semantics of the opaque component." So it's not really opaque, is it?  The term "opaque" is commonly used when the data is unparseable by the participants in the protocol. Here, the client and a MAC-functional server can parse this data just fine.
>> 
> 
> I can't argue with your statement - I've tried and every time I get 20 words in, I disagree with
> what I am writing.
> 
> The intent is that the payload of the component is not describable via the protocol. seLinux
> might pick a different labeling scheme than say Trusted Solaris.
> 
> I am willing to rewrite to get that intent through.

So how about…

OLD:
                                 To accomplish this the labels
   MUST consist of an opaque component bound with a Label Format
   Specifier (LFS).
NEW:
                                 To accomplish this the labels
   MUST consist of a format-specific component bound with a Label
   Format Specifier (LFS).


>> - I think the security considerations is missing some text on what additional security is needed in the case of a limited server that only stores the information. Something should protect the data so that client A's data is not served to client B, even if client B is malicious. 
> 
> 
> A limited server cannot parse the labels. In essence, the server is acting like a disk array
> to the client. It simply passes the labels back to allow the client to act. As a use case, it
> is actually very attractive in achieving parity with SAN based implementations. I do believe
> there are now Linux NFSv4.2 prototypes available for just this purpose.
> 
> Nothing prevents a server vendor from implementing some user ID and IP based schema to 
> provide a coarse control.

Great. That's the text I was missing.

> 
> 
> 
>> 
>> Yoav
>> 
> 
> Thanks for the comments.
> Email secured by Check Point

[secdir] SecDir Review of draft-ietf-nfsv4-labreqs Yoav Nir
Re: [secdir] SecDir Review of draft-ietf-nfsv4-la… Haynes, Tom
Re: [secdir] SecDir Review of draft-ietf-nfsv4-la… Yoav Nir
Re: [secdir] SecDir Review of draft-ietf-nfsv4-la… Haynes, Tom