Subject: [nfsv4] make change_sec_label optional

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 22 Jan 2013 17:06:20 -0500

The initial labeled NFS implementation people have been working on for
Linux doesn't appear to need the change_sec_label attribute--labels are
expected to be static.

So, let's make this optional.

Assuming we do end up needing this in the future, all this means is that
future clients will need a little logic to handle servers without
change_sec_label support.  That doesn't seem like a huge deal.

--b.

diff --git a/nfsv42_middle_fileattributes.xml b/nfsv42_middle_fileattributes.xml
index 116b794..ac92119 100644
--- a/nfsv42_middle_fileattributes.xml
+++ b/nfsv42_middle_fileattributes.xml
@@ -192,9 +192,8 @@ typedef uint32_t  policy4;
       </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.
+        A server that supports sec_label may still choose not to support
+	change_sec_label.
       </t>
     </section>

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 23 Jan 2013 04:03:37 +0000

On Jan 22, 2013, at 4:06 PM, J. Bruce Fields <[email-masked]> wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

Thanks Bruce, I'd still like to hear from Jarrett before we do that.

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Jan 2013 22:17:24 -0600

The server could return ENOACCES or say it's not supported.  What's
the difference?

Well, if the client can see that the server doesn't implement it
without first trying it... that could be good, except that how's the
client going to tell the user about this?  It won't.  On the other
hand, the server might implement it but only for some filesystems and
not others, in which case making it optional does nothing (the server
will have to implement it).

In the end I think it's pointless to make this optional, and for a
server that truly doesn't support it to implement a trivial stub is
hardly a burden.

But maybe I'm missing some motivation?

And yes, in some label systems labels of resources *can* and *do*
change.  In MLS, for example, there's supposed to be a classification
officer who can re-classify (into more secret levels) files, and
there's also an officer who can reclassify down (i.e., declassify).

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 23 Jan 2013 11:52:31 -0500

> The server could return ENOACCES or say it's not supported.  What's

What's ENOACCES?

Sorry, I don't understand the question.

> server that truly doesn't support it to implement a trivial stub is

What trivial stub, exactly?

> But maybe I'm missing some motivation?

The only client implementation I've seen (for Linux) doesn't plan to use
this attribute.  I therefore see no reason to require a server to
implement it.

--b.

---

From: Nico Williams <[email-masked]>
Date: Wed, 23 Jan 2013 10:56:01 -0600

> Sorry, I don't understand the question.

If the operation is not supported, return an error.

> What trivial stub, exactly?

A function (or method) that only returns an error back to the client.

> this attribute.  I therefore see no reason to require a server to

What's that got to do with anything?  Solaris certainly has this
operation, and if it's NFSv4 client doesn't yet then it's only a
matter of time.  We know some people will need this operation, and we
know support for it will vary by filesystem, not just server, thus
negotiation seems useless.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 23 Jan 2013 12:16:34 -0500

> If the operation is not supported, return an error.

change_sec_label is a read-only attribute.

--b.

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 23 Jan 2013 10:41:30 -0800

On 01/22/13 08:03 PM, Haynes, Tom wrote:
> On Jan 22, 2013, at 4:06 PM, J. Bruce Fields<[email-masked]>  wrote:
>

 From reading the draft, the meaning and purpose of the change_sec_label 
attribute is to provide a way for client to know whether the label 
attribute of an object (on server) has changed, not whether the label 
may change at a future time or the operation of changing a label.

The combo of allowing setting/modifying label but having no way of 
knowing such change appears odd to me. When a client does a verify on 
change_sec_label and gets back a "not supported" error, what will that 
mean to the client, and what action should the client take? The 
change_sec_label is not needed if labels can't be changed. Current Linux 
client implementation does not verify the change_sec_label attribute 
does not seem to be a strong enough reason to change it to optional, IMO.

I do have a question on the change_sec_label attribute: Will the 
attribute ever get reset? If a client finds out a file label is changed 
and reopens the file, will it continue to say the label has changed?

- Jarrett

---

From: Nico Williams <[email-masked]>
Date: Wed, 23 Jan 2013 12:40:21 -0600

> change_sec_label is a read-only attribute.

Oh.  Never mind then :)

---

From: "Myklebust, Trond" <[email-masked]>
Date: Wed, 23 Jan 2013 18:48:26 +0000

> -----Original Message-----
> From: Jarrett Lu [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2013 1:42 PM
> To: Haynes, Tom
> Cc: J. Bruce Fields; nfsv4 list; Myklebust, Trond
> Subject: Re: [nfsv4] make change_sec_label optional
> 
> >> The initial labeled NFS implementation people have been working on
> >> for Linux doesn't appear to need the change_sec_label
> >> attribute--labels are expected to be static.
> >>
> >> Assuming we do end up needing this in the future, all this means is
> >> that future clients will need a little logic to handle servers
> >> without change_sec_label support.  That doesn't seem like a huge deal.
> >>
> >> --b.
> >>
> attribute is to provide a way for client to know whether the label attribute of
> an object (on server) has changed, not whether the label may change at a
> future time or the operation of changing a label.
> 
> The combo of allowing setting/modifying label but having no way of knowing
> such change appears odd to me. When a client does a verify on
> change_sec_label and gets back a "not supported" error, what will that mean
> to the client, and what action should the client take? The change_sec_label is
> not needed if labels can't be changed. Current Linux client implementation
> does not verify the change_sec_label attribute does not seem to be a strong
> enough reason to change it to optional, IMO.

Unless the client is broken, it should never request change_sec_label. The server will simply not include change_sec_label in the list of supported attributes.

> I do have a question on the change_sec_label attribute: Will the attribute
> ever get reset? If a client finds out a file label is changed and reopens the file,
> will it continue to say the label has changed?

A change attribute is a cookie that only changes when the thing it protects changes.
IOW: there is no set/reset, only a 'current value is', and whenever the label changes, so does the value of the change attribute.

You can trivially implement a change attribute as a simple counter that is bumped every time the label changes.

Cheers
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 23 Jan 2013 13:59:01 -0500

On Wed, Jan 23, 2013 at 10:41:30AM -0800, Jarrett Lu wrote:
> From reading the draft, the meaning and purpose of the
> change_sec_label attribute is to provide a way for client to know
> whether the label attribute of an object (on server) has changed,
> not whether the label may change at a future time or the operation
> of changing a label.

Right.

> knowing such change appears odd to me.

For the use case people seem to care about now (vm images?) the label
will be set once on object creation and then never changed.

(Or if it is changed it would be such an exceptional event that it would
be acceptable to require the client to remount.)

> When a client does a verify
> on change_sec_label and gets back a "not supported" error, what will
> that mean to the client, and what action should the client take? The
> change_sec_label is not needed if labels can't be changed. Current
> Linux client implementation does not verify the change_sec_label
> attribute does not seem to be a strong enough reason to change it to
> optional, IMO.
> 
> attribute ever get reset? If a client finds out a file label is
> changed and reopens the file, will it continue to say the label has
> changed?

It's not a boolean, it's an integer that's incremented on every change.

(Nitpick: that's a lie, it could change in some other way other than
incrementing--the point is that you compare it to old values to
determine whether something changed.)

--b.

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 23 Jan 2013 11:19:17 -0800

> Unless the client is broken, it should never request change_sec_label. The server will simply not include change_sec_label in the list of supported attributes.

OK, so clients won't ask. How will clients get notified when labels do 
change, by recall of delegation? Section 8.1 says:

    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 register a delegation on that file.

How does a client know the label will change or does it always assume it 
needs to? I'd agree if clients can be reliably notified when label 
changes, then change_sec_label can be optional.

> You can trivially implement a change attribute as a simple counter that is bumped every time the label changes.

Makes sense.

Thanks.

- Jarrett

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 23 Jan 2013 11:45:07 -0800

> be acceptable to require the client to remount.)

I agree that change_sec_label can be optional when (1) labels don't 
change, and (2) there are other means to reliably inform clients that 
label has changed, e.g. via recalling a delegation, forcing a remount, 
etc.. What's not acceptable is that clients aren't informed of a label 
change when they should be. This probably means that a server needs to 
realize it's not supporting the change_sec_label attribute and needs to 
take more drastic actions when labels do change.

> determine whether something changed.)

Got that.

Thanks.

- Jarrett

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 23 Jan 2013 19:38:07 +0000

On Jan 23, 2013, at 1:19 PM, Jarrett Lu <[email-masked]> wrote:

> OK, so clients won't ask. How will clients get notified when labels do change, by recall of delegation? Section 8.1 says:
> 
> How does a client know the label will change or does it always assume it needs to? I'd agree if clients can be reliably notified when label changes, then change_sec_label can be optional.

The client finds out pretty quickly on a given operation.

But, we had talked before about having the change_sec_label be a
timestamp. Could we not mandate that if the label is changed, the
ctime must also be modified?

Then if the client cared, it could scan the ctime to see if it needed
to get the label.

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 23 Jan 2013 12:38:00 -0800

On 01/23/13 11:38 AM, Haynes, Tom wrote:
> On Jan 23, 2013, at 1:19 PM, Jarrett Lu<[email-masked]>  wrote:
>

I just like to understand the error case scenario a little better. A 
client which has registered a delegation will see the delegation 
recalled as a result of label change. A client which didn't register a 
delegation will be forced to do a remount as a result of a label change 
that it didn't expect?

> Then if the client cared, it could scan the ctime to see if it needed

I'm OK with that.

When you make change_sec_label to be optional, I prefer to see some text 
to the effect of "existence of other means to notify clients of label 
change", as the "label change notification" requirement hasn't gone 
away. The other means are less graceful when needed.

BTW, while you are at it, sec_label_changed is a better name than 
change_sec_label which implies an operation.

Thanks.

- Jarrett

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 23 Jan 2013 17:08:13 -0500

> I just like to understand the error case scenario a little better. 
> A client which has registered a delegation will see the delegation recalled 
> as a result of label change. A client which didn't register a delegation will 
> be forced to do a remount as a result of a label change that it didn't expect?

I don't understand how "forced to do a remount" happens.  Can people suggest 
spec text that will make clear what the server has to do to force this to happen
and to determine when it has happened?  Please keep in mind that "mount" is not 
an operation in the NFSv4 protocol.

> BTW, while you are at it, sec_label_changed is a better name than change_sec_label 
> which implies an operation.

Agree that this is better but sec_label_changed suggests a boolean attribute.

How about:

   sec_label_change?

   sec_label_changeval?

   sec_label_change_thingy :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jarrett Lu
Sent: Wednesday, January 23, 2013 3:38 PM
To: Haynes, Tom
Cc: J. Bruce Fields; Myklebust, Trond; nfsv4 list
Subject: Re: [nfsv4] make change_sec_label optional

On 01/23/13 11:38 AM, Haynes, Tom wrote:
>>>>>> The initial labeled NFS implementation people have been working 
>>>>>> on for Linux doesn't appear to need the change_sec_label 
>>>>>> Assuming we do end up needing this in the future, all this means 
>>>>>> is that future clients will need a little logic to handle servers 
>>>> not whether the label may change at a future time or the operation of changing a label.
>>>>
>>>> knowing such change appears odd to me. When a client does a verify 
>>>> on change_sec_label and gets back a "not supported" error, what 
>>>> will that mean to the client, and what action should the client 
>>>> take? The change_sec_label is not needed if labels can't be 
>>>> changed. Current Linux client implementation does not verify the 
>>>> change_sec_label attribute does not seem to be a strong enough reason to change it to optional, IMO.

I just like to understand the error case scenario a little better. A client which has registered a delegation will see the delegation recalled as a result of label change. A client which didn't register a delegation will be forced to do a remount as a result of a label change that it didn't expect?

I'm OK with that.

When you make change_sec_label to be optional, I prefer to see some text to the effect of "existence of other means to notify clients of label change", as the "label change notification" requirement hasn't gone away. The other means are less graceful when needed.

BTW, while you are at it, sec_label_changed is a better name than change_sec_label which implies an operation.

Thanks.

- Jarrett

>>>> changed and reopens the file, will it continue to say the label has changed?

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 23 Jan 2013 14:46:08 -0800

> an operation in the NFSv4 protocol.

It may not need to be remount. If client's file handle can be made stale 
as a result of label change, that's probably sufficient. In this case 
the client needs to reopen the file object. What's important is that 
clients don't miss out on a label change event. On Solaris, I believe 
the client gets an EACCES error if file label is changed mid-stream. 
That will stop information flow right away but may not be the right 
error semantics as applications may not expect or be able to handle that 
error in the middle of reading a file.

>     sec_label_change_thingy :-)

Or sec_label_state?

Thanks.

- Jarrett

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 23 Jan 2013 17:46:23 -0500

On Wed, Jan 23, 2013 at 02:46:08PM -0800, Jarrett Lu wrote:
> It may not need to be remount. If client's file handle can be made
> stale as a result of label change, that's probably sufficient. In
> this case the client needs to reopen the file object. What's
> important is that clients don't miss out on a label change event. On
> Solaris, I believe the client gets an EACCES error if file label is
> changed mid-stream. That will stop information flow right away but
> may not be the right error semantics as applications may not expect
> or be able to handle that error in the middle of reading a file.

Will there be a Solaris client implementation at Connectathon?

For now the proposed Linux client implementation just assumes labels
don't change.  So that doesn't give a server implementation of
sec_label_change anyone to test against.

--b.

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 23 Jan 2013 15:01:30 -0800

> sec_label_change anyone to test against.

Solaris implemented labeled NFS based on NFS4.0 and is not compatible 
with current labeled NFS spec. I hope to have something for the June 
Connectathon. I know my manager isn't reading this thread. ;-)

- Jarrett

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 24 Jan 2013 01:07:15 +0000

On Jan 23, 2013, at 4:46 PM, Jarrett Lu <[email-masked]> wrote:

> It may not need to be remount. If client's file handle can be made stale as a result of label change, that's probably sufficient. In this case the client needs to reopen the file object. What's important is that clients don't miss out on a label change event. On Solaris, I believe the client gets an EACCES error if file label is changed mid-stream. That will stop information flow right away but may not be the right error semantics as applications may not expect or be able to handle that error in the middle of reading a file.
> 

Applications have to be able to deal with that already - an admin may change export permissions at any point.

There are two concerns here:

1) Admin changes the policy and we need to be able to stop all now unauthorized access to the object.

This will work without change_sec_label.

2) Admin changes the policy and wants all client cached data flushed.

The delegation allows for this.

So the only uses I can see for change_sec_label is when the admin makes a change that is
more permissive or when they make one that is more permissive but still allowed by the subject's label.

I.e., consider the MLS of:

Top Secret
Secret
Confidential
Unclassified

If the subject has Secret and the object has Unclassified, then if the object is changed to Confidential,
then access is still granted, but the client might want to reget the object label to prevent
a subject with Unclassified access from being allowed to read the file.

Likewise if the subject has Secret and the object has Secret, then if they object is changed to
Confidential, the client might want to get the new object label to allow subjects with a
Confidential access to be allowed to get the file.

But in either case, if the ctime changes, the client can deduce it needs to get the possibly changed label.

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 24 Jan 2013 09:52:33 -0800

On 01/23/13 05:07 PM, Haynes, Tom wrote:
> On Jan 23, 2013, at 4:46 PM, Jarrett Lu<[email-masked]>  wrote:
>

This makes sense. Actually DAC access permission can be taken away 
asynchronously as well.

> Confidential access to be allowed to get the file.

In MLS model, when an object label is lowered from Secret to 
Confidential, the Secret labeled subject should lose write access. The 
object becomes read only.

Given the use cases you provided for change_sec_label, I now believe 
this attribute is not worthwhile. In all cases, if clients are not made 
aware of a label change on the object, it's a risk to the MAC model 
although it may not in violation of a particular MAC operation. For 
example, a subject labeled SECRET is reading an object labeled 
CONFIDENTIAL. The object is then downgraded to UNCLASSIFIED. Although 
the subject can continue reading the object without violating MAC 
policy, the client should immediately update the label info on the 
object for obvious reasons. Without (1) and (2) you cited above, the 
only way for clients to find out such a label change is to do getattr on 
change_sec_label on every operation. Given label change is rare, that's 
hardly an optimization. If getattr becomes a local operation on clients 
when delegation is in effect, it's more broken. So I suggest that server 
MUST recall delegations when object label changes and do away with the 
change_sec_label attribute.

Thanks for presenting the use cases.

- Jarrett

---

From: David Quigley <[email-masked]>
Date: Thu, 24 Jan 2013 12:45:05 -0500

On 01/23/2013 13:59, J. Bruce Fields wrote:
>> for
>> is that

Actually to clarify something. We do intend on implementing this. We do 
find it useful and it is on our list of things to do. The reason we 
don't currently have it implemented is that it wasn't part of the 
original spec we proposed and the current prototype was written against 
the earlier spec. In the VM image use case we do have the label 
changing. sVirt will use the category fields of the SELinux labels for 
process separation for individual qemu instances. For this to happen 
libvirt will set the qemu instance and modify the disk images for the vm 
in question to match the categories of the qemu instance. What I've said 
in the past is currently we've found that the 5 second attribute cache 
timeout that Linux currently has by default seems ok for now however 
there are definitely environments which needs quicker change 
notification.

Dave

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 24 Jan 2013 17:56:27 +0000

> Sent: Thursday, January 24, 2013 12:53 PM
> To: Haynes, Tom
> Cc: David Noveck; J. Bruce Fields; Myklebust, Trond; nfsv4 list
> >>>> A client which has registered a delegation will see the delegation
> >>>> recalled as a result of label change. A client which didn't
> >>>> register a delegation will be forced to do a remount as a result of a label
> change that it didn't expect?
> >>> I don't understand how "forced to do a remount" happens.  Can people
> >>> suggest spec text that will make clear what the server has to do to
> >>> force this to happen and to determine when it has happened?  Please
> >>> keep in mind that "mount" is not an operation in the NFSv4 protocol.
> >> It may not need to be remount. If client's file handle can be made stale as
> a result of label change, that's probably sufficient. In this case the client
> needs to reopen the file object. What's important is that clients don't miss
> out on a label change event. On Solaris, I believe the client gets an EACCES
> error if file label is changed mid-stream. That will stop information flow right
> away but may not be the right error semantics as applications may not expect
> > So the only uses I can see for change_sec_label is when the admin
> > makes a change that is more permissive or when they make one that is
> more permissive but still allowed by the subject's label.
> >
> > If the subject has Secret and the object has Unclassified, then if the
> > object is changed to Confidential, then access is still granted, but
> > the client might want to reget the object label to prevent a subject with
> Unclassified access from being allowed to read the file.
> >
> > Likewise if the subject has Secret and the object has Secret, then if
> > they object is changed to Confidential, the client might want to get
> > the new object label to allow subjects with a Confidential access to be
> allowed to get the file.
> 
> In MLS model, when an object label is lowered from Secret to Confidential,
> the Secret labeled subject should lose write access. The object becomes read
> only.
> 
> Given the use cases you provided for change_sec_label, I now believe this
> attribute is not worthwhile. In all cases, if clients are not made aware of a
> label change on the object, it's a risk to the MAC model although it may not in
> violation of a particular MAC operation. For example, a subject labeled
> SECRET is reading an object labeled CONFIDENTIAL. The object is then
> downgraded to UNCLASSIFIED. Although the subject can continue reading
> the object without violating MAC policy, the client should immediately
> update the label info on the object for obvious reasons. Without (1) and (2)
> you cited above, the only way for clients to find out such a label change is to
> do getattr on change_sec_label on every operation. Given label change is
> rare, that's hardly an optimization. If getattr becomes a local operation on
> clients when delegation is in effect, it's more broken. So I suggest that server

Are you seriously proposing that we tie labels to delegations? How do you propose to make that scale?

Trond

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 24 Jan 2013 10:19:23 -0800

> Are you seriously proposing that we tie labels to delegations? How do you propose to make that scale?

I have not thought about scalability. In MLS world, label change is 
rare, and delegation recall due to label change will be rare. It's very 
possible that I don't understand delegation well enough. Can you 
elaborate on the potential problems?

Thanks.

- Jarrett

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 24 Jan 2013 18:28:43 +0000

> Sent: Thursday, January 24, 2013 1:19 PM
> To: Myklebust, Trond
> Cc: Haynes, Tom; David Noveck; J. Bruce Fields; nfsv4 list
> >>>>>> A client which has registered a delegation will see the
> >>>>>> delegation recalled as a result of label change. A client which
> >>>>>> didn't register a delegation will be forced to do a remount as a
> >>>>>> result of a label
> >>>>> I don't understand how "forced to do a remount" happens.  Can
> >>>>> people suggest spec text that will make clear what the server has
> >>>>> to do to force this to happen and to determine when it has
> >>>>> happened?  Please keep in mind that "mount" is not an operation in
> the NFSv4 protocol.
> >>>> stale as
> >> a result of label change, that's probably sufficient. In this case
> >>> Applications have to be able to deal with that already - an admin
> >>> may
> >> change export permissions at any point.
> >>
> >>> If the subject has Secret and the object has Unclassified, then if
> >>> the object is changed to Confidential, then access is still granted,
> >>> but the client might want to reget the object label to prevent a
> >>> subject with
> >>> Likewise if the subject has Secret and the object has Secret, then
> >>> if they object is changed to Confidential, the client might want to
> >>> get the new object label to allow subjects with a Confidential
> >>> access to be
> >> allowed to get the file.
> >>
> >> Confidential, the Secret labeled subject should lose write access.
> >> The object becomes read only.
> >>
> >> this attribute is not worthwhile. In all cases, if clients are not
> >> made aware of a label change on the object, it's a risk to the MAC
> >> model although it may not in violation of a particular MAC operation.
> >> For example, a subject labeled SECRET is reading an object labeled
> >> only way for clients to find out such a label change is to do getattr
> >> on change_sec_label on every operation. Given label change is rare,
> >> that's hardly an optimization. If getattr becomes a local operation
> >> on clients when delegation is in effect, it's more broken. So I
> >> suggest that server MUST recall delegations when object label changes
> and do away with the change_sec_label attribute.
> >>
> I have not thought about scalability. In MLS world, label change is rare, and
> delegation recall due to label change will be rare. It's very possible that I don't
> understand delegation well enough. Can you elaborate on the potential
> problems?
> 

My point is that delegations are

a) not a lock.
b) only practical for a subset of applications.

Your colleagues in the database branch can't use them, for instance, so they wouldn't be able to use a server with labeled nfs at all. All database reads would have to check the label _before_ copying the data into the user buffer (no O_DIRECT) and writes would not be possible at all (you're not caching a label).

In addition, directories only have read delegations, so operations like CREATE that change the directory would be out of the question.

IOW: Delegations are no option if you really want to protect all operations.
 
The point of the change attribute was to allow the client to use VERIFY to check that the label is still unchanged before attempting a subsequent protected operation (like READ, WRITE, OPEN, CREATE,...). Maybe we can replace that with a VERIFY of the sec_label attribute itself, but the current spec assumes that there can be a large array of label data per sec_label, which would appear to make that option impractical (it will impose a ridiculously high burden on the client and server, and so can't scale).

Trond

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 13:18:49 -0600

On Wed, Jan 23, 2013 at 4:46 PM, Jarrett Lu <[email-masked]> wrote:
> a result of label change, that's probably sufficient. In this case the
> client needs to reopen the file object. What's important is that clients
> don't miss out on a label change event. On Solaris, I believe the client
> gets an EACCES error if file label is changed mid-stream. That will stop
> information flow right away but may not be the right error semantics as
> applications may not expect or be able to handle that error in the middle of
> reading a file.

Returning EACCES from read(2) or write(2) is definitely not
POSIX-compliant.  Arguably labeling at all means you've left POSIX
because re-doing authorization *after* the file descriptor is created
is definitely non-POSIX behavior.  You might return EIO, but I think
any error you return will cause problems, given which I think EACCES
is the best error to return because it's appropriately descriptive.

This is something that should be taken the Unix standards bodies.
Standardized labeled system behavior at this level would be nice.

Anyways, forgive me for going off-topic.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 24 Jan 2013 11:40:23 -0800

> IOW: Delegations are no option if you really want to protect all operations.

Thanks for the elaboration. Labeled NFS does not mandate or depend on 
delegation. If some apps can't use NFS, addling labeled NFS won't change 
that. If apps can use NFS but not delegation, they should be able to use 
labeled NFS without delegation. I'm also with you on that delegation is 
not a protection mechanism. On the other hand, when delegation is 
applicable, it needs to take label into consideration and preserve 
labeling semantics. For example, client cached data needs to be flushed 
back to server when a file label is changed. That's scenario (2) in 
Tom's earlier email.

> The point of the change attribute was to allow the client to use VERIFY to check that the label is still unchanged before attempting a subsequent protected operation (like READ, WRITE, OPEN, CREATE…

I see this as a trade off between (1) paying a small cost to verify 
label has not changed for every protected operation (very frequent), and 
(2) paying no cost when label does not change and incur a bigger cost 
when label does change (very rare). I believe (2) is easier to implement 
and require less protocol extensions.

As for the attribute size, typical usage is a single, small label. But 
we tend to design for "future"....

- Jarrett

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 24 Jan 2013 15:14:04 -0500

On Thu, Jan 24, 2013 at 11:40:23AM -0800, Jarrett Lu wrote:
> label has not changed for every protected operation (very frequent),
> and (2) paying no cost when label does not change

If you're talking about delegations here--that's not true, there's a
cost to delegations even in the absence of label changes.

But I've lost the thread of the discussion.  We seem to be re-opening
the question of how to inform clients about label changes.  All the
possibilities that raised on this thread (callbacks, filehandle
revocation) have been discussed here before.

My only question is whether we can make change_sec_label optional.

The proposed Linux client implementation doesn't query change_sec_label,
because it just doesn't worry much about label changes, as far as I can
tell.  The effort of informing clients is wasted if they don't use the
information.

As I understand it we've already accepted that there are legitimate uses
of labelled NFS that don't require race-free notification of label
changes.  (If the server doesn't enforce, then even the VERIFY trick
doesn't close the check label/change label/do operation race.)

--b.

> and incur a bigger
> cost when label does change (very rare). I believe (2) is easier to
> implement and require less protocol extensions.
> 
> As for the attribute size, typical usage is a single, small label.
> But we tend to design for "future"....
> 
> - Jarrett
> 
> >
> >Trond
>

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 24 Jan 2013 20:39:57 +0000

> tell.  The effort of informing clients is wasted if they don't use the

Here is my contention with this - the push to make the change comes
from one implementation for a specific use case. Quiqley has indicated
that might solely be an artifact of developing against an older version of
the spec.

If the change_sec_label an optional attribute, then at what level is it optional?

The file?
The filesystem?
The server?

I.e., if the client asks once for the change_sec_label and is told it is not
set for the current object, can it make any assumptions about whether it
needs to ask for it again?

> changes.  

Have we?

> (If the server doesn't enforce, then even the VERIFY trick

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 13:27:44 -0600

> Applications have to be able to deal with that already - an admin may change export permissions at any point.

Ah, right.  Also NFSv3 servers re-check permissions on every READ and
WRITE -- statelessness leaves the server no choice.  NFSv4 servers
with stateless clients have to do the same.

That reminds me of the perennial revoke(2) discussion, that always
seems to fail to progress in Linux-land.  The BSD revoke(2) system
call was originally intended (and, I think, to this still is only for)
revoking access to ptys/ttys, but clearly it'd be useful to have
something like it for plain files as well.

One might want to be able to change DAC and/or MAC permissions and
possibly *separately* explicitly revoke access by subjects that are no
longer permitted by the new policy, or even revoke access by all
subjects that were accessing the object statefully (this last is
difficult to manage in distributed filesystems).  This would require a
revoke operation in the NFSv4 protocol.  Of course, it's easier to
stick to implicit revocation.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 24 Jan 2013 16:03:18 -0500

> that might solely be an artifact of developing against an older version of

OK, maybe I misunderstood.

> needs to ask for it again?

Yes, it's per-filesystem.

(The supported_attrs attribute is per-filesystem, and the getattr
description says:

	The server MUST return a value for each attribute that the
	client requests if the attribute is supported by the server for
	the target file system.  If the server does not support a
	particular attribute on the target file system, then it MUST NOT
	return the attribute value and MUST NOT set the attribute bit in
	the result bitmap. 

So, file-by-file support for particular attributes.)

> > doesn't close the check label/change label/do operation race.)

If we've decided to allow that, then we're OK with at least some race
window.

And from David Quigley's followup, it sounds like they don't need
immediate notification for their case.

--b.

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 24 Jan 2013 13:16:56 -0800

> cost to delegations even in the absence of label changes.

Let me clarify: I didn't mean to say delegation is cost free. I was 
suggesting to use delegation recall as a way of notifying client that 
label has changed *when delegation is already in use*. In current spec, 
server already needs to recall delegation due to label change in some 
cases. I merely expanded its usage. I contrasted that with the 
"verifying change_sec_label attribute on every protected operation" 
approach. Not having to verify label change on fast path ops is 
desirable. When delegation is not in use, clients will have to contact 
server for every op and will get the current label value.

> revocation) have been discussed here before.

Sorry if I reopened settled issues. With Tom's use case for 
change_sec_label, I revisited its usefulness.

> My only question is whether we can make change_sec_label optional.

I think it can be make optional. I'm exploring whether this attr can be 
removed so that implementers won't even have to worry about it.

> doesn't close the check label/change label/do operation race.)

We are not aiming to solve race problem. But it'd be wrong if clients 
are unaware of label change and continue to treat the object at the old 
label.

- Jarrett

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 24 Jan 2013 16:32:07 -0500

> So, file-by-file support for particular attributes.)

Uh, there was supposed to be a "no" somewhere in that last line.  You
knew what I meant!

--b.

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 24 Jan 2013 13:50:44 -0800

On 01/24/13 12:39 PM, Haynes, Tom wrote:
> On Jan 24, 2013, at 2:14 PM, J. Bruce Fields<[email-masked]>  wrote:
>

Wouldn't it save the day if change_sec_label is not needed? I still 
think the two existing mechanisms can cover all client notification 
requirements for label changes. IMO, they probably do a better job than 
the change_sec_label attribute approach.

- Jarrett

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 24 Jan 2013 16:53:15 -0500

On Thu, Jan 24, 2013 at 01:50:44PM -0800, Jarrett Lu wrote:
> requirements for label changes. IMO, they probably do a better job
> than the change_sec_label attribute approach.

You mean, delegations and the (already-existing) change attribute?

Fine by me.  (That's what Tom meant when he suggested ctime should
change, right?)

I don't remember (or wasn't paying attention): how did we end up giving
sec_label its own change attribute instead of treating it like any other
metadata?

Is it because we didn't want to have to re-fetch other attributes
whenever the label changed?  Probably not, because we assume label
changes are very rare.

So it must be because we don't want to have to re-fetch the label every
time the other attributes change?  Is that such a burden?

Despite the designers reserving the right for labels to be larger,
it sounds like typically they'll be no larger than file owners, and
probably smaller than ACLs.

--b.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 24 Jan 2013 21:55:02 +0000

> Sent: Thursday, January 24, 2013 4:51 PM
> To: Haynes, Tom
> Cc: J. Bruce Fields; Myklebust, Trond; David Noveck; nfsv4 list
> >>>> The point of the change attribute was to allow the client to use VERIFY
> to check that the label is still unchanged before attempting a subsequent
> protected operation (like READ, WRITE, OPEN, CREATE,...). Maybe we can
> replace that with a VERIFY of the sec_label attribute itself, but the current
> spec assumes that there can be a large array of label data per sec_label,
> which would appear to make that option impractical (it will impose a
> ridiculously high burden on the client and server, and so can't scale).
> >> The proposed Linux client implementation doesn't query
> >> change_sec_label, because it just doesn't worry much about label
> >> changes, as far as I can tell.  The effort of informing clients is
> >> wasted if they don't use the information.
> > that might solely be an artifact of developing against an older
> > version of the spec.
> >
> > I.e., if the client asks once for the change_sec_label and is told it
> > is not set for the current object, can it make any assumptions about
> > whether it needs to ask for it again?
> 
> Wouldn't it save the day if change_sec_label is not needed? I still think the
> two existing mechanisms can cover all client notification requirements for
> label changes. IMO, they probably do a better job than the change_sec_label
> attribute approach.
> 

No. You can't treat client-side security the way that you treat server-side security. Close-to-open cache consistency works because the security is enforced by the server. If the client is caching attributes too aggressively, it really doesn't matter because the server will stop it from doing a READ or WRITE or MKDIR that is prohibited due to a permissions change.

Verifying that they are unchanged in a compound just before (and after) an operation is easily done. You can compare it to using a stateid to check that locking state is still valid on a READ/WRITE.
Actually, that would be the other way to do this. I believe that a couple of years ago, we did actually discuss the option of having a stateid represent the state of the label, and protect the operations that follow it in a COMPOUND (i.e. a "current label stateid"). I can't remember why we rejected that idea, though...

Trond

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 15:56:08 -0600

> whenever the label changed?  Probably not, because we assume label

Probably so that client-side revocation on label change could be
implemented without having to retrieve the label every time ctime
changes?

Nico
--

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 24 Jan 2013 22:00:15 +0000

> From: J. Bruce Fields [mailto:[email-masked]]
> Sent: Thursday, January 24, 2013 4:53 PM
> To: Jarrett Lu
> Cc: Haynes, Tom; Myklebust, Trond; David Noveck; nfsv4 list
> > >>>label has not changed for every protected operation (very
> > >>>frequent), and (2) paying no cost when label does not change
> > >>But I've lost the thread of the discussion.  We seem to be
> > >>re-opening the question of how to inform clients about label
> > >>changes.  All the possibilities that raised on this thread
> > >>(callbacks, filehandle
> > >from one implementation for a specific use case. Quiqley has
> > >indicated that might solely be an artifact of developing against an
> > >older version of the spec.
> > >
> Is it because we didn't want to have to re-fetch other attributes whenever
> the label changed?  Probably not, because we assume label changes are very
> rare.
> 
> So it must be because we don't want to have to re-fetch the label every time
> the other attributes change?  Is that such a burden?
> 
> Despite the designers reserving the right for labels to be larger, it sounds like
> typically they'll be no larger than file owners, and probably smaller than ACLs.

Requesting file owners is already recognised as a burden. We don't request them unless we have to...
The difference here is that getting the file owner wrong has very limited security implications.

Trond

---

From: Rick Macklem <[email-masked]>
Date: Thu, 24 Jan 2013 20:37:48 -0500 (EST)

Nico Williams wrote:
> > the
Yes, because NFS servers check access for every read/write, no NFS mount
can be POSIX compliant. In another post, you hinted that this is different
for NFSv4 and I do not believe that is the case. A stateid refers to lock
state (an NFSv4 Open is a form of lock) and does not "authorize" a read/write.
My NFSv4 server still checks access for every read/write and I believe that
is appropriate. (The exception is when a client holds a delegation, but the
delegation should be recalled when mode bits or ACL for the file changes.)

And, yes, this is off-topic. I don't have an opinion w.r.t. change_sec_label, rick.