Subject: [nfsv4] Scribe 5/17

From: "Reyes-Ortiz, Talia" <[email-masked]>
Date: Thu, 17 May 2012 21:29:06 +0000

Tom, Jared, Chuck Leaver, Sorin, Dean, Bruce, Dave, James Lentini, Pranoop

Note-well agreement

START 7.4.1
2259, 2234 - Chuck: (Meta-item) "L NFS" change to "Labeled NFS" for consistency [Tom AI, also in requirement document]

2279 - Tom: How does the server convey support for multiple MAC models?
- Tom: In general, can a file return multiple security labels?

2330 - Tom: AI SHOULD or a MUST ?

2367 - Jared: Change "LFS is 0" to another well-defined number (Tom AI #TBD)

2392 - Chuck: Paragraph to be added about security of transport layer.

4842 - Chuck: First paragraph is giving conflicting information then in line 2047-2053

2052-2053 - Chuck: Last sentence is not adequate, doesn't make sense (Tom gave a good explanation in call-back section)

4835 - Dave: For a way to limit this just to the security label changing
                Peter (AI): Is this too general? Should we specific?

4824 - Bruce: why aren't we also handling directory objects?

4850 - Bruce: What is the client's responsibility in giving a response?
                - Bruce: What is the server responsible for giving when the client responds with an error or doesn't
respond at all

2229-2230 - Bruce: Check MUSTs

Cheers!
Talia Reyes-Ortiz
Program Manager
CTO Office
NetApp Inc.
408.822.1566 Direct Phone
[email-masked]
[Description: http://media.netapp.com/images/esigs-innovative-company-480x75.png]<http://www.forbes.com/special-features/innovative-companies.html>

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 17 May 2012 17:50:34 -0700

> Tom, Jared, Chuck Leaver, Sorin, Dean, Bruce, Dave, James Lentini, Pranoop

Peter was also a participant.

> 2259, 2234 - Chuck: (Meta-item) "L NFS" change to "Labeled NFS" for consistency [Tom AI, also in requirement document]

This is done in both documents.

> 2279 - Tom: How does the server convey support for multiple MAC models?

The answer here is that we cannot do so with the current proposed XDR:

  2674     struct labelformat_spec4 {
  2675             policy4 lfs_lfs;
  2676             policy4 lfs_pi;
  2677     };
  2678
  2679     struct sec_label4 {
  2680             labelformat_spec4       slai_lfs;
  2681             opaque                  slai_data<>;
  2682     };

> - Tom: In general, can a file return multiple security labels?

We discussed whether the file can return labels for multiple LFS models. As
shown above, we see the answer is no.

But we also see that for a given LFS, multiple "labels" can be returned.

I'm pretty sure Nico had a use case for this.

-- 
[email-masked], ex-cfb

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 18 May 2012 13:27:04 -0400

> 4824 - Bruce: why aren't we also handling directory objects?

Nit: for "directory", read "anything other than a regular file".

E.g., "ls -Z /dev/" on a Fedora box shows that selinux makes use of
labels on device nodes.  Do we need notifications when those labels
change?

--b.

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 18 May 2012 18:53:06 +0000

On 5/18/12 10:27 AM, "J. Bruce Fields" <[email-masked]> wrote:

>> 2259, 2234 - Chuck: (Meta-item) "L NFS" change to "Labeled NFS" for
>>consistency [Tom AI, also in requirement document]
>> 
>> 2052-2053 - Chuck: Last sentence is not adequate, doesn't make sense
>>(Tom gave a good explanation in call-back section)
>> 

In the document, we say "files" when we should say "object".

When the object is a regular file, we have a sense that the client is
using it because of the file being open.

With a directory, if the client had a directory delegation, we have a
sense that the client is using it.

So, what I would suggest is that we change the text to state if the server
can determine if the client is using the object, it should use the CB.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 18 May 2012 15:09:56 -0400

> can determine if the client is using the object, it should use the CB.

That would rule out notifications for objects (like device files) that
aren't regular files or directories.

I mean, sure, maybe that's reasonable.

But I don't think you or I can come up with an answer on our own.  We
need someone that could say, for example, "yes, notifications on regular
files only would still be sufficient for us to implement selinux in the
dumb-server case."

--b.

---

From: David Quigley <[email-masked]>
Date: Fri, 18 May 2012 15:28:58 -0400

On 05/18/2012 15:09, J. Bruce Fields wrote:
>> >> Tom, Jared, Chuck Leaver, Sorin, Dean, Bruce, Dave, James 
>> Lentini,
>> >>Pranoop
>> >>
>> >> Note-well agreement
>> >>
>> >> START 7.4.1
>> >> 2367 - Jared: Change "LFS is 0" to another well-defined number 
>> (Tom AI
>> >>#TBD)
>> >>
>> >> 4842 - Chuck: First paragraph is giving conflicting information 
>> then in
>> >>line 2047-2053
>> >>

For the usecases we have envisioned I don't think we would be sharing 
device nodes over NFSv4. I'm actually not sure what usecase would 
require that behavior. For reasonable SELinux enforcement on NFS mouted 
shares we'd want label notification on regular files, directories, and 
symlinks. I could comb through the other object classes which have a 
corresponding object type in NFS and make a better decision but I'd have 
to do that later when I get home from work. For now though I feel safe 
stating that those three object types I mentioned above would be 
sufficient for the dumb-server case as that case is mostly for labeling 
files and directories.

Dave

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 18 May 2012 16:27:08 -0400

On Fri, May 18, 2012 at 03:28:58PM -0400, David Quigley wrote:
> For the usecases we have envisioned I don't think we would be
> sharing device nodes over NFSv4. I'm actually not sure what usecase
> would require that behavior. For reasonable SELinux enforcement on
> NFS mouted shares we'd want label notification on regular files,
> directories, and symlinks.

OK.

> I could comb through the other object
> classes which have a corresponding object type in NFS and make a
> better decision but I'd have to do that later when I get home from
> work.

>From http://tools.ietf.org/html/rfc5661#section-5.8.1.2 :

	o  NF4REG designates a regular file.
	o  NF4DIR designates a directory.
	o  NF4BLK designates a block device special file.
	o  NF4CHR designates a character device special file.
	o  NF4LNK designates a symbolic link.
	o  NF4SOCK designates a named socket special file.
	o  NF4FIFO designates a fifo special file.
	o  NF4ATTRDIR designates a named attribute directory.
	o  NF4NAMEDATTR designates a named attribute.

> For now though I feel safe stating that those three object
> types I mentioned above would be sufficient for the dumb-server case
> as that case is mostly for labeling files and directories.

--b.

---

From: Dave Quigley <[email-masked]>
Date: Sun, 20 May 2012 18:48:51 -0400

>> as that case is mostly for labeling files and directories.

Ok so looking at that list it would be nice to have everything except 
named attribute directory and named attribute. We have object classes 
for all of the other types. You might want to allow labels on the named 
attrs though as well. We wouldn't make use of it but someone else might.

Dave

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 22 May 2012 14:03:50 -0400

On Sun, May 20, 2012 at 06:48:51PM -0400, Dave Quigley wrote:
> Ok so looking at that list it would be nice to have everything
> except named attribute directory and named attribute. We have object
> classes for all of the other types. You might want to allow labels
> on the named attrs though as well. We wouldn't make use of it but
> someone else might.

So at least for the selinux case, if I'm understanding you right:

	- You *need* regular files, directories, and symlinks at a
	  minimum.
	- You don't need named attribute files and directories.
	- The rest would be nice, but you could still live without them?

In any case, I assume that means we need label-change notifications for
those things.  And the current spec only handles that for the file case.

So we have to figure out how to handle directories and symlinks.  Tom
suggests we could handle directories by just adding language requiring a
server to notify clients that hold directory delegations.  We'd need to
look at that.  For symlinks we'd probably need more protocol?

--b.

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 22 May 2012 12:26:23 -0700

> look at that.  For symlinks we'd probably need more protocol?

Thanks for bringing this up. I think we really only care about things
the client might have open state.

For the files, we only do the CB if the client has it open. If it
does not, then when the client tries to access it, we will deny that.

For a directory, I see these scenarios:

1) Delegation exists - CB
2) No delegation, but actively being used in a readdir - the NFSv4
   ops will deny access
3) No delegation, client not "under" node - when crossing into the node,
   access is denied
4) No delegation, client is under the node

In the last one, what are the expectations when the client tries to
access a file/subdir inside the directory? With DAC, this is allowed.

For symlinks, I think we don't need a CB depending on the answer to 4) above.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 23 May 2012 14:35:16 -0400

> the client might have open state.

I assume you meant: "... only care about regular files that have open
state", but I'm nost sure.

That wouldn't agree with what Dave's said.

Looking at http://tools.ietf.org/html/draft-ietf-nfsv4-labreqs-03 it
says a couple different things:

	Servers MUST provide a mechanism for notifying clients of
	attribute changes of files on the server."

I'd be willing to take "files" to mean regular files, except the
sentence above says "Servers MUST be able to store and retrieve the
security attribute of exported files as requested by the client", and in
that case "files" was clearly meant to be all filesystem objects.

Then later for limited server mode it says "The server MUST inform
clients when an object label changes for a file the client has open."

So I don't know.

My concern is just that the authors may not have overlooked the fact
that in NFSv4 only regular files can be opened.  In which case we could
end up with something that doesn't actually work for their purposes.

--b.

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 23 May 2012 11:52:55 -0700

> clients when an object label changes for a file the client has open."

BTW - Please bring this up on the Last Call for that document. :->

(see below for some comments)

> end up with something that doesn't actually work for their purposes.

I agree.

A goal of Labeled NFS is to remove the need for MAC based NFS servers to create
default labels for incoming NFS requests.

If we consider a case where the MAC NFS server running NFSv4.1 has an
implementation which simply maps client IP to a label:

192.168.34.21 -> Top Secret
192.168.23.10 -> Secret

then it is clear that the server has no means to inform the clients when
a security label on an object is modified.

So the only means the server has to interact via MAC policies is to
either accept or reject the operations as they try to access an object.

The minimum bar we have to meet is that above - it keeps parity with
existing implementations.

We can make improvements iff we know the client has state (open file handle,
directory delegation) that the server can reasonably detect. In such cases,
the server can notify the client of an attribute change on an object.

As for the Requirmens, what we want is probably:

       Servers SHOULD provide a mechanism for notifying clients of
       attribute changes of objects on the server.

       Servers MUST be able to store and retrieve the
       security attribute of objects as requested by the client.