Subject: Re: [nfsv4] [PATCH 3/4] Labeled NFS miscellaneous clarifications

From: Tom Haynes <[email-masked]>
Date: Mon, 14 Jul 2014 12:48:27 -0400

On Jun 24, 2014, at 1:52 PM, Tom Haynes <[email-masked]> wrote:

> 
> On Jun 23, 2014, at 2:28 PM, [email-masked] wrote:
> 
>> From: Andy Adamson <[email-masked]>
>> 
>> 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
> 
> 
> The client does not present an object label, it presents a subject label.

Can you revert this?

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

And this?

The point here is that a server can always tell whether the client can support
LNFS, but the client has to do some discovery.

>>      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: Tom Haynes <[email-masked]>
Date: Mon, 14 Jul 2014 12:52:18 -0400

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

> nfsv42_middle_lnfs.xml | 34 ++++++++++++++++------------------
> 1 file changed, 16 insertions(+), 18 deletions(-)
> 
> index 0686e23..0221440 100644
> @@ -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

Effectively “and and"

> +        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: "Adamson, Andy" <[email-masked]>
Date: Mon, 14 Jul 2014 18:25:59 +0000

On Jul 14, 2014, at 12:52 PM, Tom Haynes <[email-masked]> wrote:

> Effectively “and and”

OK  - i’ll do all the fixes and send a new patch set (version 2) in a bit.

—>Andy