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

From: Yoav Nir <[email-masked]>
Date: Sat, 2 Nov 2013 12:29:47 +0000

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.

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

Yoav

---

From: "Haynes, Tom" <[email-masked]>
Date: Sat, 2 Nov 2013 21:07:50 +0000

inline...

> - 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 li…

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 sema…

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.

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

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.

> Yoav

Thanks for the comments.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 3 Nov 2013 18:26:12 +0000

> 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).

> provide a coarse control.

Great. That's the text I was missing.

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Sun, 3 Nov 2013 19:15:16 +0000

> On Nov 3, 2013, at 10:26 AM, "Yoav Nir" <[email-masked]> wrote:
> 
> 

Agreed.