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.
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.
> On May 1, 2014, at 7:07 AM, Jeff Layton <[email protected]> wrote:
>
> On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes
> <[email protected]> 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. :-)
On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes
<[email protected]> 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.
On May 1, 2014, at 10:16 AM, Tom Haynes <[email protected]> wrote:
>
>
>> On May 1, 2014, at 7:07 AM, Jeff Layton <[email protected]> wrote:
>>
>> On Sat, Apr 26, 2014 at 12:35 PM, Thomas Haynes
>> <[email protected]> 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.