Subject: [nfsv4] [PATCH 0/4] Labeled NFS clairifications

From: <[email-masked]>
Date: Mon, 23 Jun 2014 17:28:05 -0400

From: Andy Adamson <[email-masked]>

Some clairifications prior to adding a section on rpcsec_gssv3 use for full
mode labeling in NFSv4.2.

The biggest change is patch "Labeled NFS label changes section clarificiation"

Andy Adamson (4):
  Labeled NFS Introduction clairifications
  Labeled NFS label changes section clarificiation
  Labeled NFS miscellaneous clarifications
  Labeled NFS remove change_sec_label section

 nfsv42_middle_fileattributes.xml | 20 -------------
 nfsv42_middle_introduction.xml   |  8 ++++--
 nfsv42_middle_lnfs.xml           | 61 ++++++++++++++++++++--------------------
 3 files changed, 36 insertions(+), 53 deletions(-)

-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Mon, 23 Jun 2014 17:28:06 -0400

Signed-off-by: Andy Adamson <[email-masked]>
---
 nfsv42_middle_introduction.xml |  4 ++--
 nfsv42_middle_lnfs.xml         | 23 +++++++++++++----------
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/nfsv42_middle_introduction.xml b/nfsv42_middle_introduction.xml
index 4038e60..9815595 100644
--- a/nfsv42_middle_introduction.xml
+++ b/nfsv42_middle_introduction.xml
@@ -138,8 +138,8 @@
         security models to enforce data access, there has been no protocol
         support to allow full interoperability. A new file object attribute,
         sec_label (see <xref target='ss:fattr:sec' />) allows for the
-        server to store and enforce MAC labels. The format of the sec_label
-        accommodates any MAC security system.
+        server to store MAC labels, which the client retrieves and enforces.
+        The format of the sec_label accommodates any MAC security system.
       </t>
     </section>
   </section>
diff --git a/nfsv42_middle_lnfs.xml b/nfsv42_middle_lnfs.xml
index 25b4b1c..0686e23 100644
--- a/nfsv42_middle_lnfs.xml
+++ b/nfsv42_middle_lnfs.xml
@@ -21,7 +21,7 @@
     </t>
 
     <t>
-      The first change necessary is to devise a method for transporting
+      First we provide a method for transporting
       and storing security label data on NFSv4 file objects.  Security
       labels have several semantics that are met by NFSv4 recommended
       attributes such as the ability to set the label value upon
@@ -36,18 +36,21 @@
     </t>
 
     <t>
-      The second change is to provide methods for the client to
-      determine if the security label has changed. A client which
-      needs to know if a label is going to change SHOULD request a
-      delegation on that file. In order to change the security
-      label, the server will have to recall all delegations. This
-      will inform the client of the change.
+      Second, we describe a method for the client to
+      determine if an NFSv4 file object security label has changed.
+      A client which
+      needs to know if a label on a file or set of files is going to change
+      SHOULD request a delegation on each labeled file. In order to change such
+      a security label, the server will have to recall delegations on
+      any file affected by the label change, so informing clients of
+      the label change.
     </t>
 
     <t>
-      An additional useful change would be modification to the RPC layer
-      used in NFSv4 to allow RPC calls to carry security labels.  Such
-      modifications are outside the scope of this document
+      An additional useful feature would be modification to the RPC layer
+      used by NFSv4 to allow RPC calls to carry security labels and enable
+      full mode enforcement as described in <xref target= 'ss:modes:full' />.
+      Such modifications are outside the scope of this document
       (see <xref target='rpcsec_gssv3' />).
     </t>
   </section>
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Mon, 23 Jun 2014 17:28:07 -0400

Signed-off-by: Andy Adamson <[email-masked]>
---
 nfsv42_middle_lnfs.xml | 34 ++++++++++++++++------------------
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/nfsv42_middle_lnfs.xml b/nfsv42_middle_lnfs.xml
index 0686e23..0221440 100644
--- a/nfsv42_middle_lnfs.xml
+++ b/nfsv42_middle_lnfs.xml
@@ -216,29 +216,27 @@
 
     <section anchor='ss:macss:lnfs:changes' title='Label Changes'>
       <t>
-        If there are open delegations on the file
-        belonging to client other than the one making the label
-        change, then the process described in
-        <xref target='ss:macss:lnfs:delegs' /> must be followed.
-        In short, the delegation will be recalled, which effectively
-        notifies the client of the change.
+        Consider a <xref target='ss:modes:guest'> guest mode system </xref>
+        in which the clients enforce MAC checks and
+        and the server has only a DAC security system which stores the
+        labels along with the file data.
+        In this type of system, a user with the appropriate DAC
+        credentials on a client with poorly configured or disabled MAC labeling
+        enforcement is allowed access to the file label (and data)
+        on the server and can change the label.
       </t>
-
       <t>
-        Consider a system in which the clients enforce MAC checks and
-        and the server has a very simple security
-        system which just stores the labels. In this system, the
-        MAC label check always allows access, regardless of the
-        subject label.
+        Clients which need to know if a label on a file or set of files 
+        has changed SHOULD request a delegation on each labeled file so
+        that a label change by another client will be known via the process 
+        described in <xref target='ss:macss:lnfs:delegs' />  which must be
+        followed: the delegation will be recalled, which effectively
+        notifies the client of the change.
       </t>
-
       <t>
-        The way in which MAC labels are enforced is by the
-        client. The security policies on the client can be
+        Note that the MAC security policies on a client can be
         such that the client does not have access to the file
-        unless it has a delegation. The recall of the delegation
-        will force the client to flush any cached content of the
-        file.
+        unless it has a delegation. 
       </t>
     </section>
   </section>
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Mon, 23 Jun 2014 17:28:08 -0400

Signed-off-by: Andy Adamson <[email-masked]>
---
 nfsv42_middle_introduction.xml | 6 ++++--
 nfsv42_middle_lnfs.xml         | 4 ++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/nfsv42_middle_introduction.xml b/nfsv42_middle_introduction.xml
index 9815595..2b604f0 100644
--- a/nfsv42_middle_introduction.xml
+++ b/nfsv42_middle_introduction.xml
@@ -136,9 +136,11 @@
       <t>
         While both clients and servers can employ Mandatory Access Control (MAC)
         security models to enforce data access, there has been no protocol
-        support to allow full interoperability. A new file object attribute,
+        support for interoperability. A new file object attribute,
         sec_label (see <xref target='ss:fattr:sec' />) allows for the
-        server to store MAC labels, which the client retrieves and enforces.
+        server to store MAC labels on files, which the client
+        retrieves and uses to enforce data access
+        (see <xref target='ss:modes:guest' />).
         The format of the sec_label accommodates any MAC security system.
       </t>
     </section>
diff --git a/nfsv42_middle_lnfs.xml b/nfsv42_middle_lnfs.xml
index 0221440..587bcd1 100644
--- a/nfsv42_middle_lnfs.xml
+++ b/nfsv42_middle_lnfs.xml
@@ -248,14 +248,14 @@
         on the MDS. Fortunately, the NFSv4.1 protocol <xref target='RFC5661' />
         already has provisions for doing access level checks from
         the DS to the MDS. In order for the DS to validate
-        the subject label presented by the client, it SHOULD
+        the file object label presented by the client, it SHOULD
         utilize this mechanism.
       </t>
   </section>
 
   <section anchor='ss:lnfs:discovery' title='Discovery of Server Labeled NFS Support'>
     <t>
-      The server can easily determine that a client supports Labeled NFS
+      The client can easily determine that a server supports Labeled NFS
       when it queries for the FATTR4_SEC_LABEL label for an object.
       The client might need to discover which LFS the server supports.
     </t>
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Mon, 23 Jun 2014 17:28:09 -0400

Not used.

Signed-off-by: Andy Adamson <[email-masked]>
---
 nfsv42_middle_fileattributes.xml | 20 --------------------
 1 file changed, 20 deletions(-)

diff --git a/nfsv42_middle_fileattributes.xml b/nfsv42_middle_fileattributes.xml
index 28872b2..6e28043 100644
--- a/nfsv42_middle_fileattributes.xml
+++ b/nfsv42_middle_fileattributes.xml
@@ -188,26 +188,6 @@ typedef uint32_t  policy4;
         of a specific MAC model, the client will be aware of the size.
       </t>
 
-      <t>
-        If a server supports sec_label, then it MUST also support
-        change_sec_label. Any modification to sec_label MUST modify
-        the value for change_sec_label.
-      </t>
-    </section>
-
-    <section toc='exclude' anchor='ss:fattr:chsec' title='Attribute 79: change_sec_label'>
-      <t>
-        The change_sec_label attribute is a read-only attribute per file.
-        If the value of sec_label for a file is not the same at two
-        disparate times then the values of change_sec_label at those
-        times MUST be different as well.  The value of change_sec_label
-        MAY change at other times as well, but this should be rare, as
-        that will require the client to abort any operation in progress,
-        re-read the label, and retry the operation.  As the
-        sec_label is not bounded by size, this attribute allows for
-        VERIFY and NVERIFY to quickly determine if the sec_label
-        has been modified.
-      </t>
     </section>
 
     <section toc='exclude' anchor="ss:fattr:sf" title="Attribute 77: space_freed">
-- 
1.8.5.2 (Apple Git-48)

---

From: Tom Haynes <[email-masked]>
Date: Tue, 24 Jun 2014 10:52:43 -0700

> +++ b/nfsv42_middle_introduction.xml

The client does not present an object label, it presents a subject label.

---

From: Tom Haynes <[email-masked]>
Date: Tue, 24 Jun 2014 11:07:58 -0700

On Jun 23, 2014, at 2:28 PM, [email-masked] wrote:

> +      SHOULD request a delegation on each labeled file.

No need to specify multiple files here, it gets confusing in that I start
thinking of directory delegations.

> In order to change such

One of the reasons I like the use of delegations is that we really do not
have a clue as to how often the use case of label changes is going to happen.
So we might end up putting back in the change_sec_label if we find out
labels change that often.

But both the original and new text imply that a label is only valid if there
is a delegation, which is not the intent here. I.e., if the client has cached
a label from the server, then that label MUST be authoritative, irregardless
of whether there is a delegation or not.

I’d also hate to see a client implementation which gets a delegation on
all files just to capture label changes. The delegations could be recalled
for other reasons and we might have an impact we do not want to see. :-)

Unless someone has some phrasing that captures this, I’ll supply a change
after this one to point this out.

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 24 Jun 2014 19:00:54 +0000

> The client does not present an object label, it presents a subject label.

OK - The client presents a label to be stored with the data object? That is called a subject label?

Sorry - I’m trying to catch up on all of this..

—>Andy