Subject: [nfsv4] [LNFS] Meeting Agenda for 05/12/2011 (new conference number)

From: Thomas Haynes <[email-masked]>
Date: Tue, 10 May 2011 18:52:51 -0500

Thursday's proposed agenda is below. Please let me know if
you would like to add additional topics.

PLEASE NOTE: Both the phone numbers and the conference ID have been changed.

   Time: Thursdays 12:30-1:30 PM CST/1:30-2:30 PM EST/10:30-11:30 AM PST
Dial-in: 1-866-844-9418 (Toll Free)
       1-517-345-9208 (Caller paid)     
         1800-936-206 (Israel toll free)

     Id: 9744122017

Proposed Agenda
---------------

+ IETF Note Well Agreement

 This is a reminder that our discussions are governed by the 
 IETF Note Well Agreement. See:

   http://www.ietf.org/NOTEWELL.html

 We will start each week's meeting with this announcement.

+ Administrivia

This is the new conference number for all further meetings.

+ Multiple labels per object

Simple XDR change to allow multiple labels per object.

Expectation is first implementations will only encode 1, but
want to be flexible.

+ Discovery of DOI supported by server

A per filesystem attribute or is this per object?

Does it matter to the client?

Again, expectation is 99% of the systems will only encode 1.

+ Label aware server

I've proposed we allow a LFS=0 to be a label aware server. I think
Sorin effectively showed this will not work. I.e., we want the
smart clients to use labels that they can understand.

Is this a useful attribute to let a client be aware of?

+ LFS Registry

Sorin has proposed that we pull this into the I-D, which will finally
consolidate all LFS documentation into one. I've done this.

+ Namespace access

Motion is to strike that section as no MOUNT sideband protocol.

Need to add text about READDIR processing.

+ CB_LABEL_CHANGED

Nico proposed that instead of a CB that just flags a label
change, we have a CB that informs the client that the
attributes have changed. Two levels - critical and non-critical.

The client would then query the server for the changes. 

+ Label change algorithm

We went over this both in the last meeting and in the followup
email. I want to make sure I captured what we agreed to...

Server gets request to change object label

Server satisfies preconditions to allow change
1) At the spec level: if open delegations, must be recalled
2) At the DOI level: ala Solaris TX, file must be 'tranquil'

Server makes change

Effects are immediate
1) I.e., if more restrictive, subject loses access, writes lost, etc

Server sends out CB_LABEL_CHANGED

Questions:

Q1) Do we want to differentiate between NFS4ERR_DELAY
and something like NFS4ERR_DOI_BLOCKING?

Q2) Do we want to provide a means for a client to state
that the change must be applied right now! I.e.,
revoke delegations right away and ignore DOI
constraints?

+ Interop Testing at the BAT

NFSv4.2 spec temporarily has XDR for LNFS.

Who is bringing a prototype and what level?

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 May 2011 22:48:21 -0500

> Expectation is first implementations will only encode 1, but

In last week's thread I think we concluded that generic label
composition on the wire (i.e., send N>=1 labels) is fine, and an
example of one operating system was given that generically composes
labels.

> + Discovery of DOI supported by server

s/DOI/DOIs/ ?

> Does it matter to the client?

I'm not sure that it matters.  The client should have some
configuration to decide the label ranges/sets of the servers it speaks
to (though this configuration may be distributed via, e.g., server
certificates).

> Again, expectation is 99% of the systems will only encode 1.

Since we have an example of one OS that does generic composition, I'm
not sure that's really true.  I'd rather we not take a position on
that.

> smart clients to use labels that they can understand.

It'd be just a signalling method: if the client could see that the
server claims to support LFS #0 then clearly the server isn't smart,
just label-aware.  Anything else would not work, no.

> Is this a useful attribute to let a client be aware of?

Not sure.  See comment above regarding configuration.

> consolidate all LFS documentation into one. I've done this.

There's probably interactions here with other parts of the IETF.
Surely NFSv4 will not be the last protocol to have labels on the wire
(it certainly isn't the first).  The registry mught need to be
generic.

> Need to add text about READDIR processing.

READDIR filtering needs to be allowed.  (I.e., two subjects could see
different contents for the same directory due to their operating at
different labels.)

> Server sends out CB_LABEL_CHANGED

I'm not sure that delegations need be recalled -- what would be the point?

What does need to be allowed is for clients (wel, subjects) that lost
access to be able to return delegations after the fact (though without
being able to flush dirty buffers).

If the delegation recall happens before the new label takes effect
then clients will not have lost access that should have, and they'll
be able to flush dirty buffers -- which contradicts the agreement that
revocation should be immediate.  If the delegation recall happens
after the label change, what's the urgency? why recall the delegation
when there's no pressing need (because of some other client, say) for
it?

> and something like NFS4ERR_DOI_BLOCKING?

At label change time, as a return to the client doing the change?  If
the client making the label change wants to quiesce the file, yes, but
we might as well have an operation that lets a client know whether
other clients have a given FH open (generic is better).

> revoke delegations right away and ignore DOI

I think so.  An operating system can see to it that processes are
signaled (killed, whatever) when a user wants to make an object label
change that would cause those processes to lose access -- and there's
always the option of SIGKILL.  We need similar semantics for NFSv4,
no?

Nico
--

---

From: sfaibish <[email-masked]>
Date: Wed, 11 May 2011 10:10:25 -0400

>          1800-936-206 (Israel toll free)
I would like to discuss an additional idea for Label unaware clients.
The idea is to allow partial label aware servers to deny access to
clients that are not supporting labels. I am loking for a mechanism
to allow dumb clients like this to be denied access to labeled
objects as a minimum server reinforcement for label aware server
implementations. It might be in line with the LFS=0.

/Sorin

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 11 May 2011 10:38:19 -0500

> (it certainly isn't the first).  The registry mught need to be

Good point, I agree.

> I'm not sure that delegations need be recalled -- what would be the point?

It is part of the NFSv4.1 spec for making attribute changes. See 18.30.4
of 5661:

   If the object whose attributes are being changed has a file
   delegation that is held by a client other than the one doing the
   SETATTR, the delegation(s) must be recalled, and the operation cannot
   proceed to actually change an attribute until each such delegation is
   returned or revoked.  In all cases in which delegations are recalled,
   the server is likely to return one or more NFS4ERR_DELAY errors while
   the delegation(s) remains outstanding, although it might not do that
   if the delegations are returned quickly.

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 11 May 2011 11:04:28 -0500

On May 11, 2011, at 9:10 AM, sfaibish wrote:

> On Tue, 10 May 2011 19:52:51 -0400, Thomas Haynes <[email-masked]> wrote:
> 
>> 
>> 
>> + Label aware server
>> 

I'm hesitant with proceeding down that route because I don't want
to lose focus on building the infrastructure. I'm not saying such
a proposal is out of scope for NFSv4, just that we have tried to
steer away from making MAC decisions in the server.

What I would like to explore are the fascinating questions that arise
out of your proposal:

1) As from your email last week, you propose a server which has an
LFS different from the clients. Say we gave this server above a PI of
1 and a label unaware server a PI of 0. And assume that the clients
are using LFS 256.

While I'm okay with a client being able to set a label to have a LFS
of 256 in this case, I wonder about the ability of a client to do so if
the server is in a different DOI. I guess this just points out that it is
up to the security system on the server to decide this policy.

I.e., one implementation might allow new DOIs to come into the
name space, whereas another might rewrite the incoming labels
into its domain.

There might be some implications with replication and migration here.

2) How does the server detect a dumb client?

A server can detect a smart client which uses RPCSEC_GSSv3, because
it will detect a subject label.

But a smart client could either not be using RPCSEC_GSSv3 or be
configured to not use subject labels with RPCSEC_GSSv3.

We might want to dust off the proposal that the following:

PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}

return the list of DOIs that the server supports.

In this case, it would return DOI={LFS=0,PI=1}. But the simple
fact that the client queried for the FATTR4_SEC_LABEL would
tell the server that it was a smart client.

---

From: <[email-masked]>
Date: Wed, 11 May 2011 13:13:54 -0400

Sorry, I'm getting a little lost in all of the acronyms being used.

What is a PI?

                Thanx...

                                ps

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Wednesday, May 11, 2011 12:04 PM
To: faibish, sorin
Cc: [email-masked]
Subject: Re: [nfsv4] [LNFS] Meeting Agenda for 05/12/2011 (new conference number)

On Tue, 10 May 2011 19:52:51 -0400, Thomas Haynes <[email-masked]<mailto:[email-masked]>> wrote:

+ Label aware server

/Sorin

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 11 May 2011 12:47:38 -0500

On May 11, 2011, at 12:13 PM, <[email-masked]> <[email-masked]> wrote:

> Sorry, I’m getting a little lost in all of the acronyms being used.
>  
> What is a PI?

From Section 2 of the draft:

   Label Format Specifier (LFS):  is an identifier used by the client to
      establish the syntactic format of the security label and the
      semantic meaning of its components.  These specifiers exist in a
      registry associated with documents describing the format and
      semantics of the label.

   Policy Identifier (PI):  is an optional part of the definition of a
      Label Format Specifier which allows for clients and server to
      identify specific security policies.

   Domain of Interpretation (DOI):  represents an administrative
      security boundary, where all systems within the DOI have
      semantically coherent labeling.  That is, a security attribute
      must always mean exactly the same thing anywhere within the DOI.

And I think we mix and match LFS with DOI with security system too much.

A DOI is a LFS + PI:

       const FATTR4_SEC_LABEL   = 81;

       typedef uint32_t  policy4;
       struct labelformat_spec4 {
         policy4   lfs_lfs;
         policy4   lfs_pi;
       };

       struct sec_label_attr_info {
         labelformat_spec4   slai_lfs;
         opaque              slai_data<>;
       };

Note: We do not yet have a proposed way of assigning PIs.

A security system is that software component on either the smart client
or smart server which implements the DOI on that machine.

So a DOI of {0,0} would be a label aware server which used a CB
to notify clients when a label change occured.

A DOI of {0,1} would be a label aware server which only allowed
smart clients to access the server.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 12 May 2011 09:49:32 -0700

On 05/11/11 08:38 AM, Thomas Haynes wrote:
>> On Tue, May 10, 2011 at 6:52 PM, Thomas Haynes <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>>
>>
>>> + LFS Registry

Labeled IPsec has similar needs.

The draft, 
http://tools.ietf.org/html/draft-quigley-label-format-registry-01 ,
is intended to serve the needs. David Q. agreed to write a SELinux label
format spec. Are there other things we should add to the draft?

- Jarrett

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 12 May 2011 12:02:59 -0500

On May 12, 2011, at 11:49 AM, [email-masked] wrote:

> The draft, http://tools.ietf.org/html/draft-quigley-label-format-registry-01 ,

Where are we going to document PIs?

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