Subject: Re: [nfsv4] Fwd: New Version Notification for draft-quigley-nfsv4-labeled-00

From: "[email-masked]" <[email-masked]>
Date: Fri, 01 Apr 2011 04:16:44 -0700

Tom,

Thank you for taking the initiative in consolidating the documents. 
Let's work on the consolidated document and try to get it in shape for 
IETF 81.

> Subject:
> Re: [nfsv4] Fwd: New Version Notification for 
> draft-quigley-nfsv4-labeled-00
> From:
> sfaibish <[email-masked]>
> Date:
> Thu, 31 Mar 2011 04:42:21 -0400
>
> To:
> Thomas Haynes <[email-masked]>, [email-masked]
> CC:
> "Moriarty, Kathleen" <[email-masked]>
>
>
> I want to start the discussion on the draft by adding the items and 
> issues
> we need to address in the draft based on my discussions with Jarrett
> and included in the slides I didn't show in the WG meeting.
>
> 1. Add in the introduction in more detail what security issues are not
>    addressed by the current ACL that are resolved by the current draft.

Text in current document is sufficient. No additional action required.

> 2. Add more usecases at least usecases related to virtualization needs,
>    government usecases, Linux usecases, cloud possible usecases, 
> additional
>    usecases from Kathleen (CCed) mentioned during the meeting.

Are we still missing the following use cases?
- MAC in virtualized environment (EMC ?)
- MAC in cloud computing (?)
- additional use cases from Kathleen (?)

Do we know who should provide what use cases? Someone should be assigned 
the action items to collect the known use cases. Sorin, should this 
person be you?

> 3. Add or group in one section addressing the implementation mechanism
>    and new xdr additions to make it clear for implementers.

Tom started doing that.

>    - Change MAC attributes to be represented as 2 separate entities:
>        Domain of Interpretation (DOI, specified by LFS)
>        Opaque without special separator @

This is agreed upon. Still need to specify format.

>    - Mechanism to allow systems to advertise MAC attributes support
>        Negotiated by requesting supported attributes from server 
> (EXCHANGE_ID)
>        May turn off support by not requesting attribute.

Based on the known use cases, how sophisticated does this negotiation 
need to be? It's conceivable that a MAC system may be capable of 
supporting more than one label format. Is there a need for a system to 
express its full capability (e.g. I understand LSF 5 and 7)? BTW, the 
use cases that I know don't require that level of complexity.
>    - Define fixed max size of the opaque (not less than IPv6 HBH 
> extension length?)

I suggested that because CALIPSO label is implement using IPv6 HBH 
extension. A CALIPSO label should fit in the opaque field.

>    - Add text to better define support of full mode MAC security as 
> implementation
>      recommendations for servers not mandating it but rather MAY be 
> implemented.

I thought about this a bit more after the meeting. The protocol 
extension should be made to support full mode. I believe users who 
really care about MAC security want to operate in full mode. Let's also 
examine each of the "half mode" operations and its impact on the 
protocol extension. (1) In the case that only server understands MAC, 
server can enforce its MAC policy without clients knowing it. When a 
non-MAC client requests access to a labeled file object (or its 
attributes), the server may grant access if its MAC policy allows it. 
When such access is granted, should the server hide the labeled 
attribute from the client? If so, there is no protocol impact, and there 
is no reason why older verson NFS clients can't be supported in this 
case. Otherwise, there is protocol impact and older version clients 
can't be supported without changes. (2) In the case where only client 
understands MAC, protocol extension is required because a client can 
request creation of a labeled object. The difference between this case 
and the "full mode" case is that a creation of a labeled object may fail 
in "full mode" if server MAC policy prevents it.

     - Address different policy reinforcement implementations more 
clearily:
>     + full server reinforcement only for dumb MAC unaware clients (define
>       how dumb, v2, v3, v4.0).
>       * Need to define/recommend which policies.
>       * Mention what are goals and non-goals addressed by current draf
>         # full mode for pNFS

If MAC negotiation/checks only happens betwen clients and MDS, this 
should work for pNFS, right?

>         # delegations (directory and files?)

Given MAC clients and MAC server are supposed to perform independent 
policy enforcement, the delegation feature probably does not make sense.

>         # untrusted devfelopments
>       * Separate "visibility" from "access permission" reinforcement.
>     + server policy to just prevent non MAC aware clients access and 
> see the
>           secured objects
>     + full server policy reinforcements for MAC aware clients

We need to distinguish support for MAC label attribute and MAC policy. 
For example, a non-MAC server is capable of get/set MAC label attribute 
(just like any other file attribute) but can't enforce any MAC policies.

>
> 4. Include a section about the pNFS support where to mention why
>    pNFS is different than 4.1. The current explanation may not be
>    enough. I would also include the reasoning why named attributes
>    is not recommended to be used.

I don't think we want to leave named attributes as an option to 
implement MAC attribute, as named attribute does not meet the 
requirement. If this prevents MAC support in NFSv3, so be it.

> 5. Add a section addressing the delegations and explain why delegations
>    are non-goals for 4.2 and what will be the roadmap for adding 
> delegation
>    support in future versions.
> 6. Define in more details all the behaviors: MAC aware cleint, MAC 
> un-aware
>    clients, MAC supportive server, MAC aware server and full mode server.
> 7. Add explanation on the issues related to root protection and/or 
> recommendation
>    how to solve them in the server (or and client)

I don't understand this. Is this related to prevention of privilege 
escalation?

> 8. Define the impact of new labels on dumb clients and MAC un-aware 
> clients both
>    from perspective of backward compatibility (new labels not break 
> the clients)
>    how to inform them that server will reinforce MAC (maybe?)
>
> We discussed additional issues which I may forgot so please jump in
> and add issues I missed that we will discuss during the calls. And I 
> insist
> of having bi-weekly calls as Jarrett, me and Dave recommend to have. It
> worked good last time we had the series. Thank you very much for your
> patience.

I suggest we start tracking issues and assigning action items to people. 
My impression is that if we need to include MAC support in 4.2, we need 
to make steady progress.

Thanks.

- Jarrett

> /Sorin

---

From: <[email-masked]>
Date: Mon, 4 Apr 2011 11:31:37 -0400

Pulling selected items out of Jarret's email:

[A] Stupid opening question for Tom - the new -labeled- draft says the following in Section 1:

   (1)  Clients must be able to convey to the server the security
        attribute of the subject making the access request.  The server
        may provide a mechanism to enforce MAC policy based on the
        requesting subject's security attribute.

[... snip ...]

   The ability to convey the
   security attribute of the subject as described in requirement (1)
   falls upon the RPC layer to implement.

Where is that proposed RPC change/addition specified?  I didn't see it in the -labeled- draft.

[B]

> - additional use cases from Kathleen (?)

At least Kathleen and I are signed up to do something here.  We're not promising that all of these use cases are applicable to MAC, but we'll take a serious look - stay tuned.

[C]

>       Negotiated by requesting supported attributes from server (EXCHANGE_ID)
> Based on the known use cases, how sophisticated does this negotiation need to be? It's conceivable that a MAC
> system may be capable of supporting more than one label format. Is there a need for a system to express its full
> capability (e.g. I understand LSF 5 and 7)? BTW, the use cases that I know don't require that level of complexity.

If there's a mismatch, client will discover quickly when a retrieved label has the wrong LFS value.  This is indicative of a serious security misconfiguration (e.g., client SHOULD disconnect if an LFS value is unexpected).

In the other direction, how does a client announce whether it's MAC capable?  Note that this would be a config check mechanism (e.g., accidentally connected a non-MAC client to a MAC server that it's not supposed to talk to), *not* a security mechanism, because a malicious client will lie.

[D]

>   - Add text to better define support of full mode MAC security as implementation
>     recommendations for servers not mandating it but rather MAY be implemented.
>
> I thought about this a bit more after the meeting. The protocol extension should be made to support full mode. I believe
> users who really care about MAC security want to operate in full mode.

This looks like violent agreement, at least to me.  IMHO, as long as the protocol extension supports full MAC mode, but server implementation of MAC is optional (MAY or a qualified SHOULD, not MUST), I think everyone may be happy - a user who wants MAC server support configures the server to support MAC and perhaps also the clients to check for that support.  In general, it looks like server MAC enforcement is a mostly transparent add-on for MAC-enabled clients (and ditto for MAC-ignorant clients).

[E]

>         # full mode for pNFS
>
> If MAC negotiation/checks only happens between clients and MDS, this should work for pNFS, right?

Not necessarily, because pNFS bypasses the server, and hence bypasses any server MAC checks ;-).  If the client is making MAC checks, the pNFS metadata server is making MAC checks, but one or more of the pNFS data servers is/are not, the "users who really care about MAC security" may not be happy.  Addressing this might just involve explaining what happens and recommending that people not do things that may not work out well (e.g., "users who really care about MAC security" SHOULD NOT use MAC-incapable data servers - for the pNFS block layout, I think this is a specific case of a "SHOULD NOT" security caution that's already in RFC 5663).

[F]

> Given MAC clients and MAC server are supposed to perform independent policy enforcement, the delegation
> feature probably does not make sense.

IMHO, file delegation is probably ok (server MAC check covering file access probably suffices for delegation).  OTOH, directory delegation is problematic, and I would have no problem for 4.2 if we said that directory delegation SHOULD NOT (or even MUST NOT?) be used w/MAC, which is a step towards:

>    are non-goals for 4.2 and what will be the roadmap for adding delegation

[G]

> 7. Add explanation on the issues related to root protection and/or recommendation
> I don't understand this. Is this related to prevention of privilege escalation?

No, some of the implementations apparently allow the root directory to be listed without MAC checks for reasons that I'll leave to the implementers to explain.  Something would be needed in the sequence of operations at mount time, or a recommendation for a workaround where the mounted root directory contains only one entry that is the logical root of the MAC-controlled filesytem (e.g., "secure_root" is the only directory entry in the mounted directory).  Listing that entry should be relatively harmless.

Thanks,
--David

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, April 01, 2011 7:17 AM
To: faibish, sorin; [email-masked]; [email-masked]
Cc: Moriarty, Kathleen
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-quigley-nfsv4-labeled-00

Tom,

Thank you for taking the initiative in consolidating the documents. Let's work on the consolidated document and try to get it in shape for IETF 81.

Subject:
Re: [nfsv4] Fwd: New Version Notification for draft-quigley-nfsv4-labeled-00

From: sfaibish <[email-masked]><mailto:[email-masked]>

Date: Thu, 31 Mar 2011 04:42:21 -0400

To: Thomas Haynes <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

CC: "Moriarty, Kathleen" <[email-masked]><mailto:[email-masked]>

I want to start the discussion on the draft by adding the items and issues
we need to address in the draft based on my discussions with Jarrett
and included in the slides I didn't show in the WG meeting.

2. Add more usecases at least usecases related to virtualization needs,
   government usecases, Linux usecases, cloud possible usecases, additional
   usecases from Kathleen (CCed) mentioned during the meeting.

Do we know who should provide what use cases? Someone should be assigned the action items to collect the known use cases. Sorin, should this person be you?

Tom started doing that.

   - Mechanism to allow systems to advertise MAC attributes support
       Negotiated by requesting supported attributes from server (EXCHANGE_ID)
       May turn off support by not requesting attribute.

Based on the known use cases, how sophisticated does this negotiation need to be? It's conceivable that a MAC system may be capable of supporting more than one label format. Is there a need for a system to express its full capability (e.g. I understand LSF 5 and 7)? BTW, the use cases that I know don't require that level of complexity.

   - Define fixed max size of the opaque (not less than IPv6 HBH extension length?)

I suggested that because CALIPSO label is implement using IPv6 HBH extension. A CALIPSO label should fit in the opaque field.

   - Add text to better define support of full mode MAC security as implementation
     recommendations for servers not mandating it but rather MAY be implemented.

I thought about this a bit more after the meeting. The protocol extension should be made to support full mode. I believe users who really care about MAC security want to operate in full mode. Let's also examine each of the "half mode" operations and its impact on the protocol extension. (1) In the case that only server understands MAC, server can enforce its MAC policy without clients knowing it. When a non-MAC client requests access to a labeled file object (or its attributes), the server may grant access if its MAC policy allows it. When such access is granted, should the server hide the labeled attribute from the client? If so, there is no protocol impact, and there is no reason why older verson NFS clients can't be supported in this case. Otherwise, there is protocol impact and older version clients can't be supported without changes. (2) In the case where only client understands MAC, protocol extension is required because a client can request creation of a labeled object. The difference between this case and the "full mode" case is that a creation of a labeled object may fail in "full mode" if server MAC policy prevents it.

    - Address different policy reinforcement implementations more clearily:

If MAC negotiation/checks only happens betwen clients and MDS, this should work for pNFS, right?

Given MAC clients and MAC server are supposed to perform independent policy enforcement, the delegation feature probably does not make sense.

        # untrusted devfelopments
      * Separate "visibility" from "access permission" reinforcement.
    + server policy to just prevent non MAC aware clients access and see the
          secured objects
    + full server policy reinforcements for MAC aware clients

We need to distinguish support for MAC label attribute and MAC policy. For example, a non-MAC server is capable of get/set MAC label attribute (just like any other file attribute) but can't enforce any MAC policies.

I don't think we want to leave named attributes as an option to implement MAC attribute, as named attribute does not meet the requirement. If this prevents MAC support in NFSv3, so be it.

5. Add a section addressing the delegations and explain why delegations
   are non-goals for 4.2 and what will be the roadmap for adding delegation
   support in future versions.
6. Define in more details all the behaviors: MAC aware cleint, MAC un-aware
   clients, MAC supportive server, MAC aware server and full mode server.
7. Add explanation on the issues related to root protection and/or recommendation
   how to solve them in the server (or and client)

I don't understand this. Is this related to prevention of privilege escalation?

8. Define the impact of new labels on dumb clients and MAC un-aware clients both
   from perspective of backward compatibility (new labels not break the clients)
   how to inform them that server will reinforce MAC (maybe?)

We discussed additional issues which I may forgot so please jump in
and add issues I missed that we will discuss during the calls. And I insist
of having bi-weekly calls as Jarrett, me and Dave recommend to have. It
worked good last time we had the series. Thank you very much for your
patience.

I suggest we start tracking issues and assigning action items to people. My impression is that if we need to include MAC support in 4.2, we need to make steady progress.

Thanks.

- Jarrett

/Sorin

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 11:50:50 -0500

On Mon, Apr 4, 2011 at 10:31 AM, <[email-masked]> wrote:

> [A] Stupid opening question for Tom – the new –labeled- draft says the following in Section 1:
>
> Where is that proposed RPC change/addition specified?  I didn’t see it in the –labeled- draft.

That'd be RPCSEC_GSSv3.  Also, just because it says "must be able
to..." above doesn't mean that RPCSEC_GSSv3 is required.  It's not,
since the server might be able to determine a label for the client
user regardless of what authentication method is used.  With
RPCSEC_GSSv3 the client can use distinct labels in a label set or
range at different times, whereas without RPCSEC_GSSv3 the client can
only operate at a single label.

> > - additional use cases from Kathleen (?)

As long as the protocol supports MAC then I think all of those cases
are met (except for Kathleen's, whose uses cases I may not know
about).

> At least Kathleen and I are signed up to do something here.  We’re not promising that all of these use cases are applicable to MAC, but we’ll take a serious look - stay tuned.

> If there’s a mismatch, client will discover quickly when a retrieved label has the wrong LFS value.  This is indicative of a serious security misconfiguration (e.g., client SHOULD disconnect if an LFS value is unexpected).

I agree.  DOI negotiation is mostly about learning a priori about
misconfiguration rather than a posteriori.

> In the other direction, how does a client announce whether it’s MAC capable?  Note that this would be a config check mechanism (e.g., accidentally connected a non-MAC client to a MAC server that it’s not supposed to talk to), *not* a security mechanism, because a malicious client will lie.

See above.  Note that a client doesn't have to be MAC aware for MAC to
take place, but a MAC-unaware client will have to operate at a single
label per-credential.

> This looks like violent agreement, at least to me.  IMHO, as long as the protocol extension supports full MAC mode, but server implementation of MAC is optional (MAY or a qualified SHOULD, not MUST), I think everyone may be happy – a user who wants MAC server support configures the server to support MAC and perhaps also the clients to check for that support.  In general, it looks like server MAC enforcement is a mostly transparent add-on for MAC-enabled clients (and ditto for MAC-ignorant clients).

MAC-aware clients might want to know that the server is MAC aware, but
MAC-unaware servers can be used by multiple MAC-aware clients just
fine, either by operating entirely at one label or by having per-path
labels, with policy enforced by the clients (plus share-level ACLs at
the server to allow only MAC-aware clients access).  Of course, that's
all kinda iffy, since ultimately we're talking about IP-address-based
share ACLs in this case, but hey.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 12:31:32 -0500

On Mon, Apr 4, 2011 at 10:31 AM, <[email-masked]> wrote:
> Not necessarily, because pNFS bypasses the server, and hence bypasses any server MAC checks ;-).  If the client is making MAC checks, the pNFS metadata server is making MAC checks, but one or more of the pNFS data servers is/are not, the “users who really care about MAC security” may not be happy.  Addressing this might just involve explaining what happens and recommending that people not do things that may not work out well (e.g., “users who really care about MAC security” SHOULD NOT use MAC-incapable data servers – for the pNFS block layout, I think this is a specific case of a “SHOULD NOT” security caution that’s already in RFC 5663).

This could be a real issue.  The pNFS server would have to know about
the label of the file stripe.  But that's not really cool.  However,
with a FH renew op we can have capabilities, and that would solve the
problem.

> IMHO, file delegation is probably ok (server MAC check covering file access probably suffices for delegation).  OTOH, directory delegation is problematic, and I would have no problem for 4.2 if we…

Agreed.  Clients are supposed to ask the server (MDS) whether any
given user can access a file for whichthe client has an open
delegation using a different user's creds.  I'd expect the same for
directory delegation.

Nico
--

---

From: Benny Halevy <[email-masked]>
Date: Mon, 04 Apr 2011 10:45:08 -0700

On 2011-04-04 10:31, Nico Williams wrote:
>> Not necessarily, because pNFS bypasses the server, and hence
>> bypasses any server MAC checks ;-).  If the client is making MAC
>> checks, the pNFS metadata server is making MAC checks, but one or
>> more of the pNFS data servers is/are not, the “users who really
>> care about MAC security” may not be happy.  Addressing this might
>> just involve explaining what happens and recommending that people
>> not do things that may not work out well (e.g., “users who really
>> care about MAC security” SHOULD NOT use MAC-incapable data servers
>> – for the pNFS block layout, I think this is a specific case of a
>> “SHOULD NOT” security caution that’s already in RFC 5663).

I guess that a nfs4.1 file-based MDS that knows that one of its DSs does
not support MAC checks should not provide a layout for it and thus
force I/O via the MDS (if it's configured to prefer security over
performance).

> 
> This could be a real issue.  The pNFS server would have to know
> about the label of the file stripe.  But that's not really cool.
> However, with a FH renew op we can have capabilities, and that would
> solve the problem.
> 
>> [F]
>> 
>>> Given MAC clients and MAC server are supposed to perform
>>> independent policy enforcement, the delegation
>> 
>> IMHO, file delegation is probably ok (server MAC check covering
>> file access probably suffices for delegation).  OTOH, directory
>> delegation is problematic, and I would have no problem for 4.2 if
>> we said that directory delegation SHOULD NOT (or even MUST NOT?) be
>> used w/MAC, which is a step towards:
> 

Directory delegations are separate and read only (with notification
callbacks).  I'm not sure how they relate to MAC security...

Benny

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 12:49:30 -0500

> callbacks).  I'm not sure how they relate to MAC security...

The server might want to allow read access but hide names for objects
whose labels the client cannot observe.  The obvious thing to do is to
say "don't rely on that".

Nico
--

---

From: Benny Halevy <[email-masked]>
Date: Mon, 04 Apr 2011 10:53:53 -0700

> say "don't rely on that".

The client can't cache any entries it doesn't know about so it the
server masks out those secured entries the client wouldn't know about
them.  If the policies change after the client got the dir. delegation
the server can either recall the delegation or notify the client of
the change to delete or update specific entries.

Benny

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Apr 2011 12:56:54 -0500

> the change to delete or update specific entries.

The issue is sharing the cache with multiple users running at
different labels/label sets/label ranges.

The client basically can't share the cache at all in such a case.

---

From: <[email-masked]>
Date: Mon, 4 Apr 2011 14:02:01 -0400

Extracting this from Nico's email:

> are met (except for Kathleen's, whose uses cases I may not know about).
> 
> > At least Kathleen and I are signed up to do something here.  We’re not promising that all of these
> use cases are applicable to MAC, but we’ll take a serious look - stay tuned.

Who's signed up to write up the Red Hat use case that has been discussed?  I think that falls into one or both of the first two categories, and having that soon as input to discussion of those areas would be productive.

Thanks,
--David

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Monday, April 04, 2011 12:51 PM
> To: Black, David
> Cc: [email-masked]; faibish, sorin; [email-masked]; [email-masked]; Moriarty, Kathleen
> Subject: Re: [nfsv4] draft-quigley-nfsv4-labeled-00 - some comments
> 
> > At least Kathleen and I are signed up to do something here.  We’re not promising that all of these
> use cases are applicable to MAC, but we’ll take a serious look - stay tuned.
> 
> >
> > [C]
> >
> > If there’s a mismatch, client will discover quickly when a retrieved label has the wrong LFS
> value.  This is indicative of a serious security misconfiguration (e.g., client SHOULD disconnect if
> an LFS value is unexpected).
> 
> > In the other direction, how does a client announce whether it’s MAC capable?  Note that this would
> be a config check mechanism (e.g., accidentally connected a non-MAC client to a MAC server that it’s
> not supposed to talk to), *not* a security mechanism, because a malicious client will lie.
> 
> > This looks like violent agreement, at least to me.  IMHO, as long as the protocol extension
> supports full MAC mode, but server implementation of MAC is optional (MAY or a qualified SHOULD, not
> MUST), I think everyone may be happy – a user who wants MAC server support configures the server to
> support MAC and perhaps also the clients to check for that support.  In general, it looks like
> server MAC enforcement is a mostly transparent add-on for MAC-enabled clients (and ditto for MAC-
> ignorant clients).
>

---

From: David Quigley <[email-masked]>
Date: Mon, 04 Apr 2011 15:57:21 -0400

[ Resending since I sent it initially with the wrong mail identity
and it got moderated ] 

I've added Dan Walsh to the people on the
email. I'd be happy to write up the Red Hat usecase for the document. I
can work with Dan or we can have Dan write the section if he thinks that
he'd be in a better position to do so. Regardless I think it will have
to be run by him before being added to the document to make sure it
deals with the finer details of the problem since he has more regular
contact with customers needing his virtualization usecase. 

On Mon, 4
Apr 2011 14:02:01 -0400, wrote: 

Extracting this from Nico's email:

[B]
> As long as the protocol
supports MAC then I think all of those cases
> are met (except for
Kathleen's, whose uses cases I may not know about).
>> At least
Kathleen and I are signed up to do something here. We're not promising
that all of these
> use cases are applicable to MAC, but we'll take a
serious look - stay tuned.

Who's signed up to write up the Red Hat use
case that has been discussed? I think that falls into one or both of the
first two categories, and having that soon as input to discussion of
those areas would be productive.

Thanks,
--David

---

From: Daniel J Walsh <[email-masked]>
Date: Mon, 04 Apr 2011 16:38:02 -0400

On 04/04/2011 03:54 PM, merlin wrote:
> I've added Dan Walsh to the people on the email. I'd be happy to write
> up the Red Hat usecase for the document. I can work with Dan or we can
> have Dan write the section if he thinks that he'd be in a better
> position to do so. Regardless I think it will have to be run by him
> before being added to the document to make sure it deals with the finer
> details of the problem since he has more regular contact with customers
> needing his virtualization usecase.
> 
Sure I would be willing to help on this.

I think there are three use cases.

1, secure virtualization, to allow me to prevent one virtual machine
from attacking another virtual machines image when stored on shared NFS
storage.
2. Sandboxing.  Allows me to isolate multiple "namespaced" homedirs on
my homedir.  If the homedir is nfs.
3. NFS homedir labeling to handle process separation.

> On Mon, 4 Apr 2011 14:02:01 -0400, wrote:
>

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 5 Apr 2011 17:46:00 -0500

On Apr 4, 2011, at 10:31 AM, <[email-masked]> <[email-masked]> wrote:

> Pulling selected items out of Jarret’s email:
>  
> 
> [E]
>  
> >         # full mode for pNFS
> >

After thinking about this for some time, I believe that this should follow the access checking
and stateid validation that 5661 already specifies.

When a client accesses a a file from a pNFS MDS, an access check occurs. Only if the
client is allowed access does it get a layout. But just because the client has a valid layout
does not mean that the DS is allowed to provide access to the data.

The DS needs to both validate the stateid and do an export check. As the DS has no
knowledge of valid stateids or exports, it uses the Control Protocol to query the MDS:

] 12.2.6.  Control Protocol
]
]   As noted in Figure 1, the control protocol is used by the exported
]   file system between the metadata server and storage devices.
]   Specification of such protocols is outside the scope of the NFSv4.1
]   protocol.  Such control protocols would be used to control activities
]   such as the allocation and deallocation of storage, the management of
]   state required by the storage devices to perform client access
]   control, and, depending on the storage protocol, the enforcement of
]   authentication and authorization so that restrictions that would be
]   enforced by the metadata server are also enforced by the storage
]   device.

The extension we would need here is for the DS to either:

1) Send on the MAC label it got from the client to the MDS, or

2) Query the MDS for the labels on the file.

The first is simpler in that it allows the MDS to be smart and the DS pretty dumb. If the
MDS says okay, then the DS says okay. The same caching mechanism (or lack thereof) 
being used for access checks (and/or stateid validation) can be used to cache the
response for the MAC check.

With the second approach, the DS has to be smarter and the cache contains the file MAC.

FWIW - I see the choice of these methods to be implementation dependent. I.e., we don't
specify the control protocol.

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 6 Apr 2011 09:51:41 -0500

> I suggested that because CALIPSO label is implement using IPv6 HBH extension. A CALIPSO label should fit in the opaque field. 

Jarrett,

One thing that isn't clear to me is why does the opaque array need a max size?

I.e., what is driving that requirement?

Thanks,
Tom

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 13:31:00 -0400

Selecting excerpts pieces to make the discussion somewhat coherent:

[A] > > Where is that proposed RPC change/addition [to convey security level of subject] specified?

> user regardless of what authentication method is used.  

That needs to be clearly explained in the new -quigley-nfsv4-labeled draft.

[B] Use cases - work is in progress son this, but I would really like to see the more detailed writeup of the Red Hat use cases.

[C] MAC attribute negotiation/announcement

Server announcement mechanism (client determines attribute support) seems fine, but ...

> See above. [RPCSEC-GSSv3]

Hmm - between [A] and [C], RPCSEC_GSSv3 seems like a lot to require in implementations if the only purpose is to enable a client to announce its MAC capabilities.  Would it make sense to define a simpler mechanism to cover [A] and [C] w/o RPCSEC_GSSv3, or should it always be required in order to use MAC for other reasons (e.g., RPCSEC_GSSv3 can certainly improve the trust level of a network wrt MAC's assurances)?

[D] Level of requirement for Server MAC implementation

> share ACLs in this case, but hey.

I agree with this. 

Thanks,
--David

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 12:39:54 -0500

[David, your method of quoting e-mails is really painful to follow.]

> That needs to be clearly explained in the new -quigley-nfsv4-labeled draft.

Yes.

> Server announcement mechanism (client determines attribute support) seems fine, but ...

I don't know what the brackets above are supposed to mean.

> Hmm - between [A] and [C], RPCSEC_GSSv3 seems like a lot to require in implementations if the only purpose is to enable a client to announce its MAC capabilities.  Would it make sense to define a s…

No, the label has to be part of the authorization context, which in
NFS comes from the RPC security layer.  It _has_ to be that way.  It'd
be really gross to do anything else.

Nico
--

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 13:50:57 -0400

Tom,

I believe that some text should to be written on this topic to provide some warnings.

For use of MAC with the pNFS block layout, it is necessary to trust the MAC code on the clients.  If that client MAC code is not sufficiently trustable in some environment, then pNFS block SHOULD NOT be used with MAC in that environment.  I'll leave it to Dave Quigley to supply a suitable definition of "trusted", but (as noted previously), this parallels language on security considerations in the pNFS block layout RFC.

I think a version of the above statement applies to file and object, but it's somewhat longer:

For the pNFS file and object layouts, there are three alternatives:
- If the DS does not support MAC, MAC is not enabled at the DS and/or MAC labels are not applied
to the DS files or objects, then the MAC code on the clients has to be trusted.  If it is
not appropriate to trust that code in some environment, then the pNFS file and object layouts
SHOULD NOT be used with MAC in that environment under these conditions.
- If the DS fully supports MAC and MAC labels are propagated from the MDS to the DS via the control
      protocol between those two, MAC operates independently on the MDS and DS.  In this scenario,
clients may encounter MAC-caused DS access denials for layouts granted by an MDS in accordance
with its MAC checks.
- Finally, the DS may use the control protocol to ask the MDS to provide the MAC information as
required for the MAC checks that the DS needs to perform.

Thanks,
--David

From: Thomas Haynes [mailto:[email-masked]]
Sent: Tuesday, April 05, 2011 6:46 PM
To: Black, David
Cc: [email-masked]; faibish, sorin; [email-masked]; Moriarty, Kathleen
Subject: Re: draft-quigley-nfsv4-labeled-00 - some comments

On Apr 4, 2011, at 10:31 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

[E]

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 13:04:06 -0500

Also, note that for RPCSEC_GSSv3, we could make it something that can
be profiled, so that clients that only need it for communicating
process labels need not implement the rest of it.  In fact, that's
already possible -- we just didn't write that out explicitly.

---

From: Tom Haynes <[email-masked]>
Date: Wed, 06 Apr 2011 13:09:27 -0500

> clients may encounter MAC-caused DS access denials for layouts granted 

I don't see how this can be the case. If the DS has the MAC label gotten 
from the MDS,
then the DS and the MDS MUST have the same MAC labels. If the MAC label 
is changed
on the MDS, I would consider this to be the same scenario as an access 
policy change.
I.e., the MDS can recall the layout and fence the file.

The MDS would also use the Control Protocol to inform the DS that the 
attribute changed.

I am looking at my assumptions and I think I know where our models differ:
the access checks belong to the MDS and not the DS. If the MDS has an 
export policy
that grants a client RW access to a file, the DS better not have 
different behavior. Likewise,
if the MDS has a MAC label which grants access to a file, the DS better 
not deny access.

I'll grant there are corner cases as a policy is being modified (with 
the resultant delay), but
the MDS ought to be able to rectify this pretty quickly.

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 14:11:40 -0400

That sounds like a promising approach. 

Thanks,
--David

> Sent: Wednesday, April 06, 2011 2:04 PM
> To: Black, David
> Cc: [email-masked]; Moriarty, Kathleen
> Subject: Re: [nfsv4] draft-quigley-nfsv4-labeled-00 - some comments ([A] - [D])
>

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 14:04:14 -0400

> [David, your method of quoting e-mails is really painful to follow.]

Inserting responses inline this time ...

Thanks,
--David

> Sent: Wednesday, April 06, 2011 1:40 PM
> To: Black, David
> > [B] Use cases - work is in progress on this, but I would really like
> > to see the more detailed writeup of the Red Hat use cases.
> >

Client asks server what attributes are supported.  I'm not sure that this distinguishes
a server that only stores the MAC labels from one that actually does the MAC checks, but
it's definitely useful.

> >> > In the other direction, how does a client announce whether it’s MAC
> >> > capable?  Note that this would be a config check mechanism (e.g.,
> >> > accidentally connected a non-MAC client to a MAC server that it’s
> > Hmm - between [A] and [C], RPCSEC_GSSv3 seems like a lot to require in 
> > implementations if the only purpose is to enable a client to announce
> > its MAC capabilities.  Would it make sense to define a simpler mechanism
> > to cover [A] and [C] w/o RPCSEC_GSSv3, or should it always be required
> > in order to use MAC for other reasons (e.g., RPCSEC_GSSv3 can certainly
> > improve the trust level of a network wrt MAC's assurances)?
> 
> No, the label has to be part of the authorization context, which in NFS comes from the RPC security
> layer.  It _has_ to be that way.  It'd be really gross to do anything else.

I agree with this when the label is passed on every RPC (e.g., client is multi-level and is passing actual subject ID).  I wonder about this if the label is per-client or per-client-session and passed once (e.g., to help the server determine the appropriate label for a single-level client).

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 13:28:04 -0500

> Inserting responses inline this time ...

Thanks!

> a server that only stores the MAC labels from one that actually does the MAC checks, but

It's certainly useful _and_ required.  The operation can fail because
MAC policy can deny read access to the label -- labels can be security
sensitive.

> I agree with this when the label is passed on every RPC (e.g., client is multi-level and is passing actual subject ID).  I wonder about this if the label is per-client or per-client-session and pas…

RPCSEC_GSSv3 would require that the client establish a distinct
RPCSEC_GSSv3 handle for each distinct process credential (where
distinctions are drawn based on process credential attributes that the
client wants RPCSEC_GSSv3 to reflect).  The process' label is/should
be part of its credential.  This means that the label wouldn't be sent
as such on every RPC (though labels are small enough that, who cares).
 It does mean, on the flip side, that RPCSEC_GSSv3 would require more
exchanges than RPCSEC_GSSv1/2 -- I don't anticipate that will be a big
deal for most labeling systems, but the one exception might be
SElinux, since it's rife with label transitions for processes.  We
might want to look at an option where the process label is affixed to
the RPCSEC_GSSv3 handle so as to minimize the number of RPCSEC_GSSv3
handles needed in an SElinux environment.

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 14:38:29 -0400

Tom,

Our models are similar, as we're in violent agreement on:

> I'll grant there are corner cases as a policy is being modified (with the resultant delay),
> but the MDS ought to be able to rectify this pretty quickly.

In addition, I suspect that there are also partial communication
behavior cases that can cause this.

>From a client protocol perspective, how quickly the MDS cleans this up is secondary -
the client code may see a MAC-caused access denial from a DS on an I/O that was
valid wrt the layout when the I/O was issued.  OTOH, we may not need (or want) to
tell the client whether that denial was caused by MAC vs. DAC.

Thanks,
--David

From: Tom Haynes [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 2:09 PM
To: Black, David
Cc: [email-masked]; Moriarty, Kathleen; [email-masked]
Subject: Re: [nfsv4] draft-quigley-nfsv4-labeled-00 - some comments [pNFS]

On 4/6/11 12:50 PM, [email-masked]<mailto:[email-masked]> wrote:
Tom,

I don't see how this can be the case. If the DS has the MAC label gotten from the MDS,
then the DS and the MDS MUST have the same MAC labels. If the MAC label is changed
on the MDS, I would consider this to be the same scenario as an access policy change.
I.e., the MDS can recall the layout and fence the file.

The MDS would also use the Control Protocol to inform the DS that the attribute changed.

I am looking at my assumptions and I think I know where our models differ:
the access checks belong to the MDS and not the DS. If the MDS has an export policy
that grants a client RW access to a file, the DS better not have different behavior. Likewise,
if the MDS has a MAC label which grants access to a file, the DS better not deny access.

I'll grant there are corner cases as a policy is being modified (with the resultant delay), but
the MDS ought to be able to rectify this pretty quickly.

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 07 Apr 2011 06:29:09 -0700

Still catching up with email after a few days of vacation...

On 04/ 4/11 08:31 AM, [email-masked] wrote:
> > Based on the known use cases, how sophisticated does this 
> negotiation need to be? It's conceivable that a MAC
>
> > system may be capable of supporting more than one label format. Is 
> there a need for a system to express its full
>
> > capability (e.g. I understand LSF 5 and 7)? BTW, the use cases that 
> I know don't require that level of complexity.
>
> If there's a mismatch, client will discover quickly when a retrieved 
> label has the wrong LFS value.  This is indicative of a serious 
> security misconfiguration (e.g., client SHOULD disconnect if an LFS 
> value is unexpected).
>
> In the other direction, how does a client announce whether it's MAC 
> accidentally connected a non-MAC client to a MAC server that it's not 
> supposed to talk to), **not** a security mechanism, because a 
> malicious client will lie.
>

I know one implementation which punted that problem entirely to 
configuration. By looking up some database, a MAC aware client knows 
whether the server is MAC aware and communicate with the server 
appropriately according to its MAC awareness. I think that was sensible 
because there was no MAC label support in NFS protocol. Now we are 
adding MAC label support. I think it'd be nice to add protocol support 
for this negotiation. I don't know all the implications of doing that, 
e.g. additional protocol complexity, compatibility, etc.. In MAC 
awareness world, it's desirable to know something about the party you 
communicate with, even when operating in a trusted environment. On the 
other hand, we are not aiming to support interoperability between 
different security models. I'm OK with "leaving negotiation as part of 
configuration". I just want some NFS expert opinion on this. The most 
critical part of the extension is to be able to express MAC label of a 
file system object.

> extension should be made to support full mode. I believe
>
> This looks like violent agreement, at least to me.  IMHO, as long as 
> the protocol extension supports full MAC mode, but server 
> implementation of MAC is optional (MAY or a qualified SHOULD, not 
> MUST), I think everyone may be happy -- a user who wants MAC server 
> support configures the server to support MAC and perhaps also the 
> clients to check for that support.  In general, it looks like server 
> MAC enforcement is a mostly transparent add-on for MAC-enabled clients 
> (and ditto for MAC-ignorant clients).
>

I also think we are in agreement. Just want to rephrase it so it's clear 
to everyone. By "protocol extension supports full mode", we mean adding 
a MAC label attribute. MAC ignorant client and server can get/set the 
label attribute but does not interpret it or apply MAC policy based on 
it. MAC aware client and server can be configured to interpret label 
attributes and enforce MAC policy based on label attributes.

> Not necessarily, because pNFS bypasses the server, and hence bypasses 
> any server MAC checks ;-).  If the client is making MAC checks, the 
> pNFS metadata server is making MAC checks, but one or more of the pNFS 
> data servers is/are not, the "users who really care about MAC 
> security" may not be happy.  Addressing this might just involve 
> explaining what happens and recommending that people not do things 
> that may not work out well (e.g., "users who really care about MAC 
> security" SHOULD NOT use MAC-incapable data servers -- for the pNFS 
> block layout, I think this is a specific case of a "SHOULD NOT" 
> security caution that's already in RFC 5663).
>

I agree with the security warning. I'm more interested in the full mode 
pNFS, which I don't know enough about. Can this MAC label extension be 
used for client/DS , and MDS/DS, communication?

> policy enforcement, the delegation
>
> IMHO, file delegation is probably ok (server MAC check covering file 
> access probably suffices for delegation).  OTOH, directory delegation 
> is problematic, and I would have no problem for 4.2 if we said that 
> directory delegation SHOULD NOT (or even MUST NOT?) be used w/MAC, 
> which is a step towards:
>

I need to learn more about the difference between file and directory 
delegation. My original thinking was that a MAC server may need to 
consult a policy module to know whether an access to a file can be 
granted. If the file is delegated to a client, there may not be a way to 
transfer that knowledge to client.

> No, some of the implementations apparently allow the root directory to 
> be listed without MAC checks for reasons that I'll leave to the 
> implementers to explain.  Something would be needed in the sequence of 
> operations at mount time, or a recommendation for a workaround where 
> the mounted root directory contains only one entry that is the logical 
> root of the MAC-controlled filesytem (e.g., "secure_root" is the only 
> directory entry in the mounted directory).  Listing that entry should 
> be relatively harmless.
>

I see. Thanks.

- Jarrett

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 09:43:40 -0500

On Thu, Apr 7, 2011 at 8:29 AM, Jarrett Lu <[email-masked]> wrote:
>> accidentally connected a non-MAC client to a MAC server that it’s not
>> supposed to talk to), *not* a security mechanism, because a malicious client
>> will lie.
>
> configuration. By looking up some database, a MAC aware client knows whether
> the server is MAC aware and communicate with the server appropriately
> according to its MAC awareness. I think that was sensible because there was
> no MAC label support in NFS protocol. Now we are adding MAC label support. I
> think it'd be nice to add protocol support for this negotiation. I don't
> know all the implications of doing that, e.g. additional protocol
> complexity, compatibility, etc.. In MAC awareness world, it's desirable to
> know something about the party you communicate with, even when operating in
> a trusted environment. On the other hand, we are not aiming to support
> interoperability between different security models. I'm OK with "leaving
> negotiation as part of configuration". I just want some NFS expert opinion
> on this. The most critical part of the extension is to be able to express
> MAC label of a file system object.

The subject/process label is also critical to communicate.

If we want MAC-aware servers we need to either map non-MAC-aware
clients to a single label (or each principal to a single label, or
each {principal, client} to a single label), or have the client
communicate the subject label to the server.

And we need security (authentication, transport protection,
authorization), of course.

Since RPCSEC_GSSv1 and 2 have no compound authentication facilities we
can't map {principal, client} to a single label -- we can only map
each principal to a label.  And since we lack GSS-API mechanisms that
communicate subject labels directly (and we lack Kerberos extensions
to do the same, though we could define some), we really have to map
each principal to a single label.  OR we can define RPCSEC_GSSv3.

Another aspect of security, besides "who/what is authenticated and
how?" is "how to decide if an assertion of subject label is to be
trusted?".  The answer for RPCSEC_GSSv3 is that the server maps the
{client host princ, user princ} to a set of labels or a label range,
then the server checks that the label asserted by the client is within
that set/range.  This is *much* more flexible than what we can do with
RPCSEC_GSSv1 and 2.

Surely you agree with me that the server needs to know the subject's
label and that we want something better than a single label
per-principal, no?

> I also think we are in agreement. Just want to rephrase it so it's clear to
> everyone. By "protocol extension supports full mode", we mean adding a MAC
> label attribute. MAC ignorant client and server can get/set the label
> attribute but does not interpret it or apply MAC policy based on it. MAC
> aware client and server can be configured to interpret label attributes and
> enforce MAC policy based on label attributes.

See above.

I agree that MAC-unaware clients and servers could support the label
attribute and allow unchecked reads and updates of it.  As long as
both are MAC-unaware, who cares.  And if the server is MAC-unaware but
all clients are MAC-aware (and share ACLs and so on are used to
enforce access only by trusted MAC-aware clients) then that's OK too
-- the clients will then enforce MAC.  But the best combination is of
MAC-aware clients and servers, so that users (and client hosts) can
operate at more than just one label, and so that servers can enforce
more of the MAC policies without having to trust clients as much.

That is, we can get a fair bit of functionality with any mix of
MAC-aware and unaware clients and servers, with the most functionality
reserved for MAC-aware clients and servers.

> delegation. My original thinking was that a MAC server may need to consult a
> policy module to know whether an access to a file can be granted. If the
> file is delegated to a client, there may not be a way to transfer that
> knowledge to client.

I think a problem only arises for directory delegations if the server
would allow a subject to READDIR a directory while also at the same
time hiding some of the directory entries from that subject due to the
subject not being authorized to see them.  If we don't allow such
behavior then there's no problem.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 7 Apr 2011 10:31:47 -0500

> behavior then there's no problem.

The problem being of course that the client could create an entry that
conflicts with a name already on the server?

Another question might be who plans to ever implement directory
delegations?

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 10:50:01 -0500

> conflicts with a name already on the server?

No, that a user, "joe", on a multi-user client could see an entry
named "Covert operations in Foobania.doc" that he was not allowed to
see but that another user, "jane", on that client was allowed to see.
Conversely, if "joe" was first to readdir that directory then "jane"
won't see that directory entry whereas she should.

The simplest fix is to say that all names in a given directory have
the same label as the directory itself, even though the named objects
themselves might have different labels.

Nico
--

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 12:08:50 -0400

How does directory delegation affect this, by the way?  This seems more like a standard sort of problem with caching the contents of directories.

	Thanx...

		ps

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Thursday, April 07, 2011 11:50 AM
To: Thomas Haynes
Cc: [email-masked]; Moriarty, Kathleen; [email-masked]
Subject: Re: [nfsv4] draft-quigley-nfsv4-labeled-00 - some comments

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 11:12:30 -0500

> How does directory delegation affect this, by the way?  This seems more like a standard sort of problem with caching the contents of directories.

Well, that's one sub-topic here.  As long as clients can cache the
direcotry contents and use ACCESS to validate each distinct user (or,
rather, process credential), we're good.  But if the server would show
different users different contents for the same directory, _then_ we
have a problem (whether we have directory delegation or not).  My
solution is to not allow the server to do that.

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 7 Apr 2011 11:44:08 -0500

>> conflicts with a name already on the server?

But my point is still an issue. If Jane tries to create a document called
"Covert operations in Foobania.doc" and was denied, then she could
surmise that such a document existed at a security clearance above hers.

> themselves might have different labels.

But that allows Jane to deduce there were covert operations in Foobania.
She might even be able to see the date and based on the size, deduce
how many operations or how large of an operation it was.

If the client is MAC aware, then I would argue that it needs to maintain
separate name spaces for all users. If the client is non-MAC aware, then
it has to consistently get the minimum label afforded to it.

I.e., the MAC aware server has to assume that the aware client can safely
hand out directory entries based on labels, but it also has to assume that
the non-aware client cannot mix and match different labels.

I would then argue that such decisions are implementation specific to the
security model. I.e., in a business world, seeing entries might be acceptable.
Whereas in a clandestine government agency, it might not be acceptable.

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 07 Apr 2011 09:48:51 -0700

On 04/ 7/11 07:43 AM, Nico Williams wrote:
> On Thu, Apr 7, 2011 at 8:29 AM, Jarrett Lu<[email-masked]>  wrote:

Yes, RPCSEC_GSSv3 will be great. It offers so many goodies. Other
than fine grained subject label, it can also be used to convey privileges
and privilege set, which could be very useful information among like
systems.

RPCSEC_GSSv3 is considered a related but separate piece from NFS
MAC label extensions. So it's great to have but not required, i.e. we
should be able to do labeled NFS without RPCSEC_GSSv3. Again, I'd
love to have both.

> reserved for MAC-aware clients and servers.

Agree.

Thanks.

- Jarrett

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 7 Apr 2011 12:00:44 -0500

On Apr 7, 2011, at 8:29 AM, Jarrett Lu wrote:

> 
> I agree with the security warning. I'm more interested in the full mode pNFS, which I don't know enough about. Can this MAC label extension be used for client/DS , and MDS/DS, communication? 
> 
>> 

So in an cluster implementation, all of the communication is already
internal or via a private protocol. I don't see how we can mandate
MAC labels on that.

And likewise, in an asynchronous implementation, all of the
communication would be over a private protocol. But in such
a case, the MDS is authoritative and owns the data being
stored on the DS.

The interesting case is the asynchronous I/O (i.e., when the
client writes/reads via the MDS). In that scenario, the MDS
is doing all of the MAC checking when the READ or WRITE ops
arrive. When it sends/receives data with the DS, the DS
has to accept that the MDS has permission to do so.

Nothing prevents this private protocol from being kerberized,
but in my mind, there is no notion of a specific user/group
coming from the MDS. All credentials are machine based. Just
as there are no DAC checks across this private protocol, there
would be no MAC checks.

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 12:02:25 -0500

> how many operations or how large of an operation it was.

Not so.  The classification officer might move or create that document
in a sub-directory with a harmless name.  Of course, if one were to do
that one might as well rely on the Solaris TX approach of mapping
paths to labels...

> it has to consistently get the minimum label afforded to it.

That's one approach, yes.

> the non-aware client cannot mix and match different labels.

I'd rather the server make authorization decisions based on labels.
Consider Smack... the server might have policies that the client
doesn't, so I'd want the client to call ACCESS for all distinct
process credentials trying to access an object.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 12:07:35 -0500

> should be able to do labeled NFS without RPCSEC_GSSv3. Again, I'd

"Is considered"?  By whom?  I consider it a requirement for some of
the cases where both, the client and the server are MAC-aware
(specifically: whenever you need support for label sets or ranges,
which is generally the case in MLS deployments for example).  (But
clearly not a requirement for the cases where either or both of the
client and server are MAC-unaware.)

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 07 Apr 2011 10:13:21 -0700

On 04/ 7/11 08:50 AM, Nico Williams wrote:
> On Thu, Apr 7, 2011 at 10:31 AM, Thomas Haynes<[email-masked]>  wrote:

This sounds like a standard multilevel directory on MLS MAC system.
A multilevel directory usually has a label range associated with it.
The label of each file under that directory falls within the label range.
A subject is only supposed to see the file entries with label it
dominates. Subject label and object label play an important role in
what object is visible. For example, a user 'joe' is cleared to read
both PUBLIC files and RESTRICTED files. When joe assumes the
PUBLIC label and read /home/joe/foo file, the file contains PUBLIC
information; when joe assumes the RESTRICTED label and reads
the file with same pathname /home/joe/foo, he is reading a different
file with RESTRICTED information in it. I don't know how to implement
all this in "delegation" context, but that is how multilevel directory
is supposed to work.

- Jarrett

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 12:14:26 -0500

> all this in "delegation" context, but that is how multilevel directory

If the client is trusted to apply policy then the client could fetch
the label attributes of the names (note: names, not files, but maybe
we want to make the equivalence between name and file here for
simplicity!) when it readdirs, then the client can enforce policy
locally.

Or the client could know not to share its cache with different
subjects unless they operate at the same labels.  Or the client could
simply refrain from sharing directory caches amongst its local users
altogether.

Those are the two main implementation choices to get this visibility
issue right.

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 07 Apr 2011 10:28:30 -0700

On 04/ 7/11 10:07 AM, Nico Williams wrote:
> On Thu, Apr 7, 2011 at 11:48 AM, Jarrett Lu<[email-masked]>  wrote:

I got the impression from the WG meeting session that RPCSEC_GSSv3
is related but separate from labeled NFS. Can others chime in on this?
I also think about this "requirement" in terms of dependency, e.g. does
NFS MAC label extension depends on RPCSEC_GSSv3? Is the extension
useless with RPCSEC_GSSv3? My opinion is labeled NFS works best with
RPCSEC_GSSv3. It can also work, in a less secure or less expressive way,
absent of RPCSEC_GSSv3. For example, a MAC server may need to do
some mapping to get client's subject label.

- Jarrett

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 12:39:54 -0500

> is related but separate from labeled NFS. Can others chime in on this?

Meetings are not authoritative for anything.  Consensus calls must be
confirmed on the list.

David Q. has stated that RPCSEC_GSSv3 is important for his interest in
labeled NFS.

> some mapping to get client's subject label.

It's required for some uses/deployments.  It's not REQUIRED in the
sense of "to implement", as in RFC2119.

If the issue is "can we leave it out of NFSv4.2" then IMO: no, we must
not.  But then, IMO we must stop the train model nonsense.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 07 Apr 2011 11:16:03 -0700

On 04/ 7/11 10:39 AM, Nico Williams wrote:
> On Thu, Apr 7, 2011 at 12:28 PM, Jarrett Lu<[email-masked]>  wrote:

For the record, I really like RPCSEC_GSSv3, and surely I'm not alone.
I guess the question is: Should we not work on labeled NFS extension
unless we also complete RPCSEC_GSSv3 at same time? I believe there are
users out there who could benefit from just labeled NFS extension work if
RPCSEC_GSSv3 needs to come in later. What does the list think?

- Jarrett

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 14:25:57 -0400

> > useless without RPCSEC_GSSv3? My opinion is labeled NFS works best with

Good - that's my crucial concern, and I agree with most of the above
comments.  I want to see implementation of RPCSEC_GSSv3 not be REQUIRED (in
the RFC 2119 sense), so that MAC labels can be used in some fashion
in the absence of RPCSEC_GSSv3 support.

Of course if RPCSEC_GSSv3 is not implemented, then environments that require
RPCSEC_GSSv3 functionality (and there are some) can't be supported by such
implementations.  Yes, that was obvious, ... but what may be less obvious
is that we're likely to need some limited additional functionality to replace
things that RPCSEC_GSSv3 does in order to ensure that MAC labels are useful
in the absence of RPCSEC_GSSv3 support (e.g., client ability to send its label
to the MAC server for cross-checking by the MAC server).

Thanks,
--David

> Sent: Thursday, April 07, 2011 1:40 PM
> To: [email-masked]
> Cc: Black, David; faibish, sorin; Moriarty, Kathleen; [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 13:31:16 -0500

> RPCSEC_GSSv3 needs to come in later. What does the list think?

That's not the right question to ask at this point because it assumes
that RPCSEC_GSSv3 won't fit into the schedule -- I'm not willing to
make that assumption and it bothers me to see others making that
assumption without ever actually making a determination as to whether
that's actually the case.  Let us for determine whether RPCSEC_GSSv3
does or does not fit the schedule, and if there's any reason to push
if off the schedule, then let's consider whether labeled NFS can
proceed without it, or whether to reform the silly train model.

I understand that the pressure to push an item off the schedule might
rise if we think that we can do without it, but there's not even been
a suggestion that this or that item won't fit in the NFSv4.2 train yet
either.

Let's get the horse before the cart.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 13:39:56 -0500

On Thu, Apr 7, 2011 at 1:25 PM,  <[email-masked]> wrote:
> the RFC 2119 sense), ...

Agreed.

> ... so that MAC labels can be used in some fashion

But that's already true today.  It's possible to use NFS in a MAC
environment without modifying the protocol.  Solaris TX proves it.

There's a set of trade-offs to make regarding what the deployed
environment looks like according to which features we have or lack.

> to the MAC server for cross-checking by the MAC server).

Yes, this is true.  We could conclude that a MAC environment w/o
RPCSEC_GSSv3 is insufficiently useful.

Solaris TX manages by labeling paths and requiring trusted clients --
the clients enforce MAC policy.

If you don't want to trust the clients quite as much then not only do
you need MAC-aware servers, but most users will (I assume) also need
RPCSEC_GSSv3 because you will need multi-label clients.

Note that defining a label attribute does not make the server
MAC-aware.  A MAC-aware server is one that can enforce MAC policy, but
since that requires knowing the label of each subject, that requires
either each principal, each client IP address, or each {principal,
client IP address} to be at a single label, OR that the clients use
RPCSEC_GSSv3.  Only the latter is terribly usable.

IOW, I think that RPCSEC_GSSv3 is required when MAC-aware _servers_
are desired.  RPCSEC_GSSv3 is only not required when dumb servers are
used.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 07 Apr 2011 14:28:01 -0700

On 04/ 7/11 11:39 AM, Nico Williams wrote:
> On Thu, Apr 7, 2011 at 1:25 PM,<[email-masked]>  wrote:

There are cases where deriving a file object label becomes difficult or 
impossible.
So having labeled NFS extension helps. Having RPCSEC_GSSv3 helps even more.
If both RPCSEC_GSSv3 and Labeled NFS fit in 4.2 time frame, great! If 
not, I don't
see why users should not get the incremental benefit, whichever piece 
becomes
available first.

> the clients enforce MAC policy.

Solaris Trusted Extensions MAC server can work with MAC aware clients
as well as MAC ignorant clients. In the former case, the subject label is
derived from the CIPSO option of an IP packet; in later case, the subject
label is defined in a centrally managed database. Not a very granular
labeling scheme, but is deployed and deemed sufficient in some environments.

So there are accredited solution that uses MAC clients and servers that
has neither labeled NFS extension nor RPCSEC_GSSv3. Either one will improve
over existing solutions. I think we agree on having both is better; we 
disagree
on having only labeled NFS extension is not useful.

- Jarrett

---

From: Jarrett Lu <[email-masked]>
Date: Thu, 07 Apr 2011 14:46:31 -0700

On 04/ 7/11 11:31 AM, Nico Williams wrote:
> On Thu, Apr 7, 2011 at 1:16 PM, Jarrett Lu<[email-masked]>  wrote:

It sounds like (to me) that you are assuming people want to push
RPCSEC_GSSv3 off 4.2 list. I'm not making that assumption. As
far as I know, nothing is really off 4.2 list. It all depends on how
much progress can be made in next a few months. In fact it'd
be great if RPCSEC_GSSv3 and Labeled NFS both make 4.2 as the
combo provides a much stronger solution. In this case, I see
working on the two pieces separately makes sense.

- Jarrett

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 7 Apr 2011 16:51:30 -0500

> working on the two pieces separately makes sense.

Ah, something I know the answer for!

RPCSEC_GSSv3 is not on the NFSv4.2 train.

It SHOULD be a separate WG item. I think the WG chairs are
arranging this.

My goal would be for us to wrap up RPCSEC_GSSv3 before we had
NFSv4.2 approaching last call. But that is just my preference to
not choke David H. with multiple documents at the same time.

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 16:56:36 -0500

> not choke David H. with multiple documents at the same time.

I am now more confused than ever :)  So, the train model is NOT
exclusive?  I.e., there can be work items that are part of a minor
version train and others that progress outside the train?

My head hurts...

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 7 Apr 2011 17:01:28 -0500

> version train and others that progress outside the train?

RPCSEC_GSS has never been a part of NFS.

What I mean by this is that these are two distinct protocols. We
do not want to produce one document that introduces changes
to both of them.

The NFSv4.2 spec will have a normative reference to RPCSEC_GSSv3,
just like 5661had these:

   [4]   Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
         Specification", RFC 2203, September 1997.

   [12]  Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February 2009.

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 17:02:23 -0500

> labeling scheme, but is deployed and deemed sufficient in some environments.

But with one label per-packet flow, meaning one label per-TCP
connection, meaning one label per-NFS session.  So, really, not
multi-label.  There's really no chance that the Solaris stack could
support labeling different packets for the same TCP connection with
different labels, nor would that be a sane thing to do.  MAC-aware,
multi-label applications MUST handle labeling at the application
protocol layer, and they must pick a single label (the most sensitive
one) for the entire packet flow (unless there's a packet flow
per-label, but that's not going to work for NFSv4 unless the client
pretends to be a different client in each session, though someone who
knows more about sessions should confirm this assertion).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 17:03:16 -0500

> The NFSv4.2 spec will have a normative reference to RPCSEC_GSSv3,

Fair enough.  Thanks!

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 7 Apr 2011 22:04:11 +0000

Why is this so hard to understand? :-)

The working group has a variety of things that it needs
to finish (yes, David, I owe you the shepherding write ups).

Once that is complete (or simultaneously), we will be putting
forth the update to the WG charter.  This charter update will
move the FedFS items to maintenance and add as new work items:
	NFSv4.2
	RPCSECGSSv3

There is a large category of functionality in NFSv4.2 that is
being considered and we are using a date driven model to 
manage that content.  As Tom suggests, the RPCSEC updates
can be done in parallel or before or after.  Presumably we
will want to do them in parallel so that we can ensure 
requirements are being met between the two.

How they are managed beyond WG last call and via the remainder
of the IETF process is the responsibility of the WG chairs
to manage.  Let's just get the work done that people want
and we'll go from there.

Spencer

> Sent: Thursday, April 07, 2011 2:57 PM
> To: Thomas Haynes
> Cc: [email-masked]; Kathleen Moriarty; [email-masked]
> > It SHOULD be a separate WG item. I think the WG chairs are arranging
> > this.
> >
> > NFSv4.2 approaching last call. But that is just my preference to not
> > choke David H. with multiple documents at the same time.
> 
> I am now more confused than ever :)  So, the train model is NOT exclusive?
> I.e., there can be work items that are part of a minor version train and
> others that progress outside the train?
> 
> My head hurts...
> 
> Nico
> --

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 7 Apr 2011 17:06:22 -0500

One of the things that has become apparent in the
various WG meetings (and discussions) is that more
than Labeled NFS has a need for RPCSEC_GSSv3:

1) Server-side copy
2) Multi-domain access
3) Trond has a use case

These will all benefit from it.

The focus in the online discussions has been more on LNFS
because it is a high-energy component that various groups
are trying to bring in.

Nico has started up a discussion on what needs to be
done with RPCSEC_GSSv3 and we'll provide some
energy to it.

---

From: Dave Quigley <[email-masked]>
Date: Fri, 08 Apr 2011 00:03:50 -0400

So I'm unfamiliar with what profiling means in this context. How does 
that work in the context of RPCSEC_GSS?

---

From: Dave Quigley <[email-masked]>
Date: Fri, 08 Apr 2011 00:40:49 -0400

> David Q. has stated that RPCSEC_GSSv3 is important for his interest in

I agree that RPCSEC_GSSv3 gives me the most control over SELinux 
policies on the server and the client. However, I intentionally 
separated them making the RPCSEC_GSSv3 a nice to have because I felt 
that I wasn't going to be able to get both documents through. However I 
believe that RPCSEC_GSSv3 is moving forward in the NFSv4.2 timeline just 
like we want to move Labeled NFS. If that is the case and both are on 
the same timeline that I think it would be a good idea to add a text on 
how both components work together. My original goal was baby steps for 
getting things in but it seems like we've taken a hop skip and a jump to 
the moon with the discussion that happened at the last meeting. That 
being said there are environments where RPCSEC_GSSv3 would be a 
requirement. My Compliance use case from the impact study would be more 
secure if we had RPCSEC_GSSv3 between the database and the file server. 
I know for a fact that there are government applications where it is 
required.

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 23:42:56 -0500

On Thu, Apr 7, 2011 at 11:03 PM, Dave Quigley <[email-masked]> wrote:
> So I'm unfamiliar with what profiling means in this context. How does that
> work in the context of RPCSEC_GSS?

A "profile" of a protocol is a like a subset of it.  The idea is here
is to make clear to client implementors that they are free to not
implement those subsets of RPCSEC_GSSv3 _features_ (the XDR itself has
to remain as-is) that they have no use for or no easy way to implement
in the short-term.

The server side too could be profiled, particularly with the change I
sent out earlier tonight, since the server could decide that it's not
going to accept privilege assertions, because it doesn't understand
them, and tell the client as much while still setting up a context
handle.  Most clients will want to proceed in such a situation, though
they wouldn't be obligated to.

Nico
--

---

From: Dave Quigley <[email-masked]>
Date: Fri, 08 Apr 2011 11:42:28 -0400

> environment looks like according to which features we have or lack.

It is true that TX provides the ability to combine NFS and MAC but I had 
spoken with Glen Faden a few years back about the solaris implementation 
of NFS and the way that is it handled is suboptimal (Although we've 
gotten a request for something similar). From what I understand(and this 
was a couple of years ago so I may be misremembering) there is some sort 
of internal security database to solaris. When the NFS server gets a 
connection from somewhere it either uses the label from some form or 
labeled networking or does a lookup based on some properties of the NFS 
session to determine the label (authenticated user, IP address, etc...). 
The problem with this is that it is very configuration heavy. People 
have asked us to do something similar for SELinux though where user 
authenticated as BoB runs at a certain clearance level. Ideally 
RPCSEC_GSSv3 would send BOB's real context over and we wouldn't have to 
worry about mappings. Just the ability to restrict the labels that bob 
asserts.

> are desired.  RPCSEC_GSSv3 is only not required when dumb servers are

I agree with this statement. I think for certain environments though 
that there are people with security models where dumb servers are 
acceptable.

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 14:14:41 -0500

On Fri, Apr 8, 2011 at 10:42 AM, Dave Quigley <[email-masked]> wrote:
> I agree with this statement. I think for certain environments though that
> there are people with security models where dumb servers are acceptable.

Indeed.  We really have two models: dumb servers + smart clients, and
smart servers + clients of either flavor.  But in the case of smart
server + smart client we really, really want to have RPCSEC_GSSv3 --
not having it means that we might as well have dumb server + smart
clients and a configuration-heavy environment like Solaris TX.

Of course, and to be fair to Solaris TX, a lot of configuration could
be needed in all cases.  For example, an MLS environment with smart
servers and clients using RPCSEC_GSSv3 would either need as much
configuration as Solaris TX _or_ it would require that the GSS-API
credentials bear their principals' label ranges (which would then have
to be configured in the KDCs, CAs, AAA servers, and other
authorities).

It is the prospect of being able to push the configuration to the
credentials issuers that is particularly enticing here!  It's not that
that reduces configuration, but that it simplifies management.

Nico
--

---

From: <[email-masked]>
Date: Fri, 8 Apr 2011 17:52:28 -0400

Nico,

> clients and a configuration-heavy environment like Solaris TX.

I think we need to count to three, as Dave Quigley's drafts did ;-).

(1) Dumb clients + smart server: Are any protocol additions needed?
(2) Smart clients + dumb server: Server stores labels for clients.
(3) Smart clients + smart server: Extend (2) by adding ability for
	server to understand labels.

I understand the argument for RPCSEC_GSSv3 for (3) - the ability to pass
a label for the process on whose behalf the client invoked the NFS operation
enables multi-level clients with the server MAC enforcement at process
granularity.  This does process-granularity information containment at
the server.

OTOH, if RPCSEC_GSSv3 is not present in (3), the server can only enforce
against client granularity - this is still useful, especially for single-level
clients because the upgrade from (2) to (3) isolates the information that
a client shouldn't see at the server.  For multi-level smart clients and
no RPCSEC_GSSv3, the server can't do much for a client that is allowed to
access everything, but some reduction in scope of accessed info is possible
if the server knows the subset of levels that a client is authorized for.

So, at least for single-level clients, I see the utility of RPCSEC_GSSv3,
but don't view it as effectively mandatory in practice as implied by the
quoted text.

Thanks,
--David

> Sent: Friday, April 08, 2011 3:15 PM
> To: Dave Quigley
> Cc: [email-masked]
> Subject: Re: [nfsv4] RPCSEC_GSSv3 implementation requirement
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 17:03:20 -0500

> I think we need to count to three, as Dave Quigley's drafts did ;-).

What David Q. and I are saying is that smart server + dumb client
isn't all that useful.

Nico
--

---

From: David Quigley <[email-masked]>
Date: Fri, 08 Apr 2011 18:15:15 -0400

On Fri, 8 Apr 2011 17:03:20 -0500, Nico Williams wrote: 

> On Fri,
Apr 8, 2011 at 4:52 PM, wrote:
>>> Indeed. We really have
two models: dumb servers + smart clients, and smart servers + clients of
either flavor. But in the case of smart server + smart client we really,
really want to have RPCSEC_GSSv3 -- not having it means that we might as
well have dumb server + smart clients and a configuration-heavy
environment like Solaris TX.
> What David Q. and I are saying is that
smart server + dumb client isn't all that useful. Nico -- We actually
kind of have that today. We can have SELinux running on a server with no
labels going in either direction. The problem today is that the NFS
server runs as the kernel_t type which is all powerful so there is no
real policy being enforced. We have an extension that never made it into
the public Labeled NFS code which allows you to take a user and assign a
label to the connection from that user. That is the dumb client/smart
server scenario. We had one customer ask for it and outside of their
specific deployment I don't see it being very
useful.

Links:
------
[1] mailto:[email-masked]

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 17:36:57 -0500

On Fri, Apr 8, 2011 at 5:15 PM, David Quigley <[email-masked]> wrote:
> We actually kind of have that today. We can have SELinux running on a server
> with no labels going in either direction. The problem today is that the NFS
> server runs as the kernel_t type which is all powerful so there is no real
> policy being enforced. We have an extension that never made it into the
> public Labeled NFS code which allows you to take a user and assign a label
> to the connection from that user. That is the dumb client/smart server
> scenario. We had one customer ask for it and outside of their specific
> deployment I don't see it being very useful.

Right, you can do smart server/dumb client.  It's just not that
useful.  So to summarize: we have three cases, of which only two are
particularly useful, the most useful one of which requires
RPCSEC_GSSv3.  RPCSEC_GSSv3 not only enables the most useful MAC
scenario, it promises to simplify management by pushing a) label
range/set assignments to credentials issuers (KDCs, CAs, AAA servers,
...), b) making it possible to have multi-label clients with all
parties able to "negotiate" (as it were) useful subject labels for all
operations, c) without having to rely on the network (IP, IPsec) for
security.

I do think this horse has been beaten pretty bad :)  We all seem to be
in agreement regarding the need for RPCSEC_GSSv3.  And RPCSEC_GSSv3
appears to be on course.  We have at least one implementor
contributing comments.  And surely we can get adequate review.

We might be able to WGLC RPCSEC_GSSv3 withing weeks, though I'd feel
more comfortable with a bit longer.

Nico
--

---

From: David Quigley <[email-masked]>
Date: Fri, 08 Apr 2011 20:49:42 -0400

Apr 8, 2011 at 5:15 PM, David Quigley wrote:
>> We actually kind of have
that today. We can have SELinux running on a server
>> with no labels
going in either direction. The problem today is that the NFS
>> server
runs as the kernel_t type which is all powerful so there is no real
policy being enforced. We have an extension that never made it into
the
security.
> Is
the implementor my guys (or atleast they use to be my guys) at
SPARTA/Cobham or do we have a 2nd implementation besides
ours?

Links:
------
[1] mailto:[email-masked]