[nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL

[nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL

[Thomas Haynes]

[-- Attachment #1.1: Type: text/plain, Size: 1903 bytes --]

In my issues file, I have:

4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to
   be?  Is seLinux going to support it?

   The Labeled NFS prototype in use does not currently support
   change_sec_label.

   In the past, we argued about how big it needed to be - we need
   to close down on this.

If we look at the current text in the NFSv4.2 draft, we see:

      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. If a client wants to
      detect if the label has changed, it MAY use VERIFY and NVERIFY
      on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL
      has been modified.

So the first question is do we need two methods for detecting that the label
has changed?

Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt covers
how the client could use delegations to detect a label change.

To quote Trond out of context:

but that is the only option I can see for implementing a cache
consistency model for labels. Without it, the choices are:

 1) always fetch the label as part of every COMPOUND.
 2) assume the label never changes on the server.

The main use cases that have been presented for Labeled NFS on Linux
would tend to push me towards door number 2, Monty please...

So a client could assume that the label never changes the majority
of the time. Once it decides it does need to start checking for a change
in the label, it can get a delegation.

If we do need the attribute, what size does it need to be?

There has been mention of it being a hash or a timestamp.

[-- Attachment #1.2: Type: text/html, Size: 2881 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Re: Resolving the fate of FATTR4_CHANGE_SEC_LABEL

[Thomas Haynes]

In my issues file, I have:

4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to
   be?  Is seLinux going to support it?

   The Labeled NFS prototype in use does not currently support
   change_sec_label.

   In the past, we argued about how big it needed to be - we need
   to close down on this.

If we look at the current text in the NFSv4.2 draft, we see:

      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. If a client wants to
      detect if the label has changed, it MAY use VERIFY and NVERIFY
      on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL
      has been modified.

So the first question is do we need two methods for detecting that the label
has changed?

Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt covers
how the client could use delegations to detect a label change.

To quote Trond out of context:

> but that is the only option I can see for implementing a cache
> consistency model for labels. Without it, the choices are:
>
>   1) always fetch the label as part of every COMPOUND.
>   2) assume the label never changes on the server.
>
> The main use cases that have been presented for Labeled NFS on Linux
> would tend to push me towards door number 2, Monty please...

So a client could assume that the label never changes the majority
of the time. Once it decides it does need to start checking for a change
in the label, it can get a delegation.

If we do need the attribute, what size does it need to be?

There has been mention of it being a hash or a timestamp.

Re: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL

[Jeff Layton]

On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes
<thomas.haynes@primarydata.com> wrote:
> In my issues file, I have:
>
> 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to
>    be?  Is seLinux going to support it?
>
>    The Labeled NFS prototype in use does not currently support
>    change_sec_label.
>
>    In the past, we argued about how big it needed to be - we need
>    to close down on this.
>
> If we look at the current text in the NFSv4.2 draft, we see:
>
>       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. If a client wants to
>       detect if the label has changed, it MAY use VERIFY and NVERIFY
>       on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL
>       has been modified.
>
> So the first question is do we need two methods for detecting that the label
> has changed?
>
> Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt
> covers
> how the client could use delegations to detect a label change.
>
> To quote Trond out of context:
>
> but that is the only option I can see for implementing a cache
> consistency model for labels. Without it, the choices are:
>
>  1) always fetch the label as part of every COMPOUND.
>  2) assume the label never changes on the server.
>
> The main use cases that have been presented for Labeled NFS on Linux
> would tend to push me towards door number 2, Monty please...
>

In principle, the label should only rarely change, but they do change
for various reasons (admin goofs and forgets to set the label in the
first place and then needs to fix it, SELinux policy changes mandate
that a label changes from some type to another, etc). I think assuming
that the label never changes would be very problematic. If the label
does change, you'd basically need to remount on the client.

That said, I don't see any real need to treat the label differently
from any other attribute. If you're trying to use these for
client-side enforcement, then you just need to be aware that you can
race with label changes on the server.

>
> So a client could assume that the label never changes the majority
> of the time. Once it decides it does need to start checking for a change
> in the label, it can get a delegation.
>
> If we do need the attribute, what size does it need to be?
>
> There has been mention of it being a hash or a timestamp.
>

I guess part of the problem is that we're trying to do client-side
enforcement with these labels, and that's always going to be
difficult. The server should really be what's doing the enforcement.
Once we have that, we can just treat the security label like any other
attribute and not worry about cache coherency.

Re: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL

[Tom Haynes]

> On May 1, 2014, at 7:07 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
> 
> On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes
> <thomas.haynes@primarydata.com> wrote:
>> In my issues file, I have:
>> 
>> 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to
>>   be?  Is seLinux going to support it?
>> 
>>   The Labeled NFS prototype in use does not currently support
>>   change_sec_label.
>> 
>>   In the past, we argued about how big it needed to be - we need
>>   to close down on this.
>> 
>> If we look at the current text in the NFSv4.2 draft, we see:
>> 
>>      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. If a client wants to
>>      detect if the label has changed, it MAY use VERIFY and NVERIFY
>>      on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL
>>      has been modified.
>> 
>> So the first question is do we need two methods for detecting that the label
>> has changed?
>> 
>> Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt
>> covers
>> how the client could use delegations to detect a label change.
>> 
>> To quote Trond out of context:
>> 
>> but that is the only option I can see for implementing a cache
>> consistency model for labels. Without it, the choices are:
>> 
>> 1) always fetch the label as part of every COMPOUND.
>> 2) assume the label never changes on the server.
>> 
>> The main use cases that have been presented for Labeled NFS on Linux
>> would tend to push me towards door number 2, Monty please...
> 
> In principle, the label should only rarely change, but they do change
> for various reasons (admin goofs and forgets to set the label in the
> first place and then needs to fix it, SELinux policy changes mandate
> that a label changes from some type to another, etc). I think assuming
> that the label never changes would be very problematic. If the label
> does change, you'd basically need to remount on the client.
> 
> That said, I don't see any real need to treat the label differently
> from any other attribute. If you're trying to use these for
> client-side enforcement, then you just need to be aware that you can
> race with label changes on the server.
> 
>> 
>> So a client could assume that the label never changes the majority
>> of the time. Once it decides it does need to start checking for a change
>> in the label, it can get a delegation.
>> 
>> If we do need the attribute, what size does it need to be?
>> 
>> There has been mention of it being a hash or a timestamp.
> 
> I guess part of the problem is that we're trying to do client-side
> enforcement with these labels, and that's always going to be
> difficult. The server should really be what's doing the enforcement.
> Once we have that, we can just treat the security label like any other
> attribute and not worry about cache coherency.

So are you advocating one of:

1) No detection of change
2) Client gets a delegation
3) Use the new attribute

FWIW, I like #2. :-)

Re: [nfsv4] Resolving the fate of FATTR4_CHANGE_SEC_LABEL

[Tom Haynes]

On May 1, 2014, at 10:16 AM, Tom Haynes <thomas.haynes@primarydata.com> wrote:

> 
> 
>> On May 1, 2014, at 7:07 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
>> 
>> On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes
>> <thomas.haynes@primarydata.com> wrote:
>>> In my issues file, I have:
>>> 
>>> 4) Labeled NFS - FATTR4_CHANGE_SEC_LABEL - how big does it need to
>>>  be?  Is seLinux going to support it?
>>> 
>>>  The Labeled NFS prototype in use does not currently support
>>>  change_sec_label.
>>> 
>>>  In the past, we argued about how big it needed to be - we need
>>>  to close down on this.
>>> 
>>> If we look at the current text in the NFSv4.2 draft, we see:
>>> 
>>>     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. If a client wants to
>>>     detect if the label has changed, it MAY use VERIFY and NVERIFY
>>>     on FATTR4_CHANGE_SEC_LABEL to detect that the FATTR4_SEC_LABEL
>>>     has been modified.
>>> 
>>> So the first question is do we need two methods for detecting that the label
>>> has changed?
>>> 
>>> Section 8.3 of http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-21.txt
>>> covers
>>> how the client could use delegations to detect a label change.
>>> 
>>> To quote Trond out of context:
>>> 
>>> but that is the only option I can see for implementing a cache
>>> consistency model for labels. Without it, the choices are:
>>> 
>>> 1) always fetch the label as part of every COMPOUND.
>>> 2) assume the label never changes on the server.
>>> 
>>> The main use cases that have been presented for Labeled NFS on Linux
>>> would tend to push me towards door number 2, Monty please...
>> 
>> In principle, the label should only rarely change, but they do change
>> for various reasons (admin goofs and forgets to set the label in the
>> first place and then needs to fix it, SELinux policy changes mandate
>> that a label changes from some type to another, etc). I think assuming
>> that the label never changes would be very problematic. If the label
>> does change, you'd basically need to remount on the client.
>> 
>> That said, I don't see any real need to treat the label differently
>> from any other attribute. If you're trying to use these for
>> client-side enforcement, then you just need to be aware that you can
>> race with label changes on the server.
>> 
>>> 
>>> So a client could assume that the label never changes the majority
>>> of the time. Once it decides it does need to start checking for a change
>>> in the label, it can get a delegation.
>>> 
>>> If we do need the attribute, what size does it need to be?
>>> 
>>> There has been mention of it being a hash or a timestamp.
>> 
>> I guess part of the problem is that we're trying to do client-side
>> enforcement with these labels, and that's always going to be
>> difficult. The server should really be what's doing the enforcement.
>> Once we have that, we can just treat the security label like any other
>> attribute and not worry about cache coherency.
> 
> So are you advocating one of:
> 
> 1) No detection of change
> 2) Client gets a delegation
> 3) Use the new attribute
> 
> FWIW, I like #2. :-)
> 
> 

And we’ve gone with #2. We can revisit the new attribute in NFSv4.3 if
we find we actually have a use for it.