Subject: [nfsv4] Two methods of passing the NFSv4.2 LNFS subject label for Full Mode

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 25 Jun 2014 21:21:34 +0000

I’m getting up to speed on the Full mode LNFS issues in NFSv4.2, and I see two ways to enable it.

Disclaimer: I am new to LNFS issues and MAC implementations and use, so I could easily be missing context. Please inform me in detail if this is so :)

The tuple <subject label, object label, policy engine> provides MAC (Mandatory Access Control), a much finer grained access control than traditional DAC (Discretionary Access Control) which uses UID/GID and ACLs to determine access to a resource. MAC is enforced by the policy engine with subject and object as inputs.

Client guest-mode LNFS occurs when the subject label remains on the client, and the object label for a file or directory is stored on the server. In this mode, the policy enforcement occurs only on the client which retrieves the object label, and then sends both the subject and object labels to a client side policy engine to determine access. This mode is completely described in draft-ietf-nfsv4-minorversion2-27.txt (!!).

To enable full mode, where both the client and the server enforce policy, the subject label needs to be forwarded to the server with each NFS request that the subject label applies to, so that the server can then send the subject and object labels to it’s MAC policy engine.

The problem:
-----------
How to forward the subject label to the server so that it can also enforce MAC with the same subject/object as the client.

I see two ways of looking at MAC info, each with a solution and a protocol impact.

1) The MAC subject is identity information.
---------------------------------------------
The caller is identified not only by the UID/GIDs (after mapping any GSS principal) but by a combination of UID/GIDs and MAC subject e.g. the MAC subject forwarding belongs in the RPC layer.

draft-ietf-nfsv4-minorversion2-27.txt, as well as draft-ietf-nfsv4-rpcsec-gssv3-
08.txt look at MAC info as part of the identity of the caller, and via GSS3, place the communication of the subject in the RPC layer.

There are a few GSS3 draft changes needed to complete this design, but the basic
 idea is that each subject is asserted in a GSS3 label assertion which means that a child gss3 context is created that contains the subject, and both the client and the server store the subject info associated with the new gss3 child handle
.  Each time that subject needs to be asserted across the nework, the associated
 gss3 context is used.Use GSS3 to transport MAC subject to server:
Pros:
        - Subject info transferred once in an RPCSEC_GSS3_CREATE label assertion
        - Use of gss3 child handle asserts subject
        - Once setup, no RPCSEC_GSS privacy or integrity requirements wRT label.
        - Destruction of gss3 child handle invalidates the subject on the server

Cons:
        - May not scale.  Given a bunch of subjects, a parent GSS context
        could be required to store a bunch of assertions.
        I don't don't have the experience to know if the are or will be a
        bunch of subjects being used between a client and a server.
        - Given a subject, the NFS client needs to decide
        which gss3 child context, or the parent context, to use. This could
        be messy WRT implementations which currently make this decision on a        per RPC credential basis (does this mean a lot more RPC credentials?).

2) The MAC subject is like ACL information.
-------------------------------------------

The MAC subject is additional info beyond any ACL info associated with the
NFS file or directory and is independent of the callers identity. e.g. the
MAC subject forwarding belongs in the NFSv4.2 layer.

In this design, I create a new NFSv4.2 operation to hold a subject label, and perhaps a new attribute to query a file systems LFS support (probably could just use sec_label).

This new operation would be placed directly after the SEQUENCE operation in all appropriate NFS requests, and thus would be processed prior to any file access operation.

Use a new NFSv4.2 operation to transport the MAC subject to the server.

Pros:
        - No new storage requirements on the server
        - Scales to the number of subjects
        - Simplify draft-ietf-nfsv4-rpcsec-gssv3 (get rid of label assertions
        and RPCSEC_GSS_LIST.

Cons:
        - Requires GSS integrity or privacy on each NFS request.
        - Adds an operation to NFSv4.2

I'm willing to write up protocol changes for each idea, and/or gather responses and present them at IETF 90.

-->Andy

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 25 Jun 2014 18:10:20 -0400

> To enable full mode, where both the client and the server enforce policy, the subject label needs to be forwarded to the server with each NFS request that the subject label applies to, so that the…

I'm skeptical that storing the <gss context handle>-><subject label>
mapping would be an unreasonable burden for the server.  Presumably it
can purge contexts not recently used, and if it doesn't have the memory
to store the set of handles currently in use then it probably has other
problems.

And it's probably using something other than the label string internally
for access checks, in which case this might be a convenient place to
cache a reference to that thing.

>         be messy WRT implementations which currently make this decision on a        per RPC credential basis (does this mean a lot more RPC credentials?).

I don't understand the problem here.

> 2) The MAC subject is like ACL information.

I understand you're proposing to pass the subject label in a new
operation, but don't understand how this is like ACL information.  We
don't pass ACLs in each operation.  ACL checks use rpc credentials like
everything else.

>         - Adds an operation to NFSv4.2

	- server looks up the subject label each time instead of being
	  able to cache it with the context handle.
	- long subject label is passed with each rpc instead of being
	  incorporated into the shorthand context handle.

The subject label is just more information identifying the caller and I
really think it should go in the rpc credential somehow.

--b.

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

---

From: "Black, David" <[email-masked]>
Date: Wed, 25 Jun 2014 18:23:28 -0400

Andy,

> Disclaimer: I am new to LNFS issues and MAC implementations and use, so I
> could easily be missing context. Please inform me in detail if this is so :)

Ok ...

> The tuple <subject label, object label, policy engine> provides MAC (Mandatory
> Access Control), a much finer grained access control than traditional DAC
> (Discretionary Access Control) which uses UID/GID and ACLs to determine access
> to a resource. MAC is enforced by the policy engine with subject and object as
> inputs.

"a much finer grained access control than" -> "an orthogonal access control mechanism that is independent of"

> 1) The MAC subject is identity information.

Ok, for the purposes of this discussion - it labels the subject with an identity of some form (could be a classification).  MAC is about compartmentalization - if malware breaks into my account, MAC puts the malware in a security box where the malware can do whatever it likes to me all day, but can't get out and go do damage elsewhere, even if it can get "root" (or what it thinks is "root") access and change UIDs, GIDs, ACLs to whatever it wants to ...

> The caller is identified not only by the UID/GIDs (after mapping any GSS
> principal) but by a combination of UID/GIDs and MAC subject e.g. the MAC
> subject forwarding belongs in the RPC layer.

Nope - a crucial property of MAC is that it cannot be bypassed by fiddling with DAC, so the UIDs/GIDs are *not* MAC policy inputs because the MAC policy engine cannot trust them (e.g., because the malware may have control over them).

Nonetheless, I think the approach in 1) is "digging in the right place", but this needs some serious expert review by someone who knows multi-level security (MLS) architectures well.  An important question (expressed in MLS terms) is whether the NFS client can be multi-level or is always single-level (a multi-level NFS client has significant implications for OS architecture and software development practices).  The design approach in 1) appears to be headed for multi-level NFS clients (there will of course be authorization constraints on the server side on what subject labels each NFS client can assert), whereas approach 2) appears to only support single-level NFS clients (server-side authorization comment also applies here).

Thanks,
--David

> -----Original Message-----
> From: nfsv4 [mailto:[email-masked]] On Behalf Of Adamson, Andy
> Sent: Wednesday, June 25, 2014 5:22 PM
> To: [email-masked]
> Subject: [nfsv4] Two methods of passing the NFSv4.2 LNFS subject label for
> Full Mode
> 
> I'm getting up to speed on the Full mode LNFS issues in NFSv4.2, and I see two
> ways to enable it.
> 
> Disclaimer: I am new to LNFS issues and MAC implementations and use, so I
> could easily be missing context. Please inform me in detail if this is so :)
> 
> The tuple <subject label, object label, policy engine> provides MAC (Mandatory
> Access Control), a much finer grained access control than traditional DAC
> (Discretionary Access Control) which uses UID/GID and ACLs to determine access
> to a resource. MAC is enforced by the policy engine with subject and object as
> inputs.
> 
> Client guest-mode LNFS occurs when the subject label remains on the client,
> and the object label for a file or directory is stored on the server. In this
> mode, the policy enforcement occurs only on the client which retrieves the
> object label, and then sends both the subject and object labels to a client
> side policy engine to determine access. This mode is completely described in
> draft-ietf-nfsv4-minorversion2-27.txt (!!).
> 
> To enable full mode, where both the client and the server enforce policy, the
> subject label needs to be forwarded to the server with each NFS request that
> the subject label applies to, so that the server can then send the subject and
> object labels to it's MAC policy engine.
> 
> The problem:
> -----------
> How to forward the subject label to the server so that it can also enforce MAC
> with the same subject/object as the client.
> 
> The caller is identified not only by the UID/GIDs (after mapping any GSS
> principal) but by a combination of UID/GIDs and MAC subject e.g. the MAC
> subject forwarding belongs in the RPC layer.
> 
> 08.txt look at MAC info as part of the identity of the caller, and via GSS3,
> place the communication of the subject in the RPC layer.
> 
>  idea is that each subject is asserted in a GSS3 label assertion which means
> that a child gss3 context is created that contains the subject, and both the
> client and the server store the subject info associated with the new gss3 child handle
> .  Each time that subject needs to be asserted across the network, the associated
>         be messy WRT implementations which currently make this decision on a
> per RPC credential basis (does this mean a lot more RPC credentials?).
> 
> 
> 
> In this design, I create a new NFSv4.2 operation to hold a subject label, and
> perhaps a new attribute to query a file systems LFS support (probably could
> just use sec_label).
> 
> This new operation would be placed directly after the SEQUENCE operation in
> all appropriate NFS requests, and thus would be processed prior to any file
> access operation.
>

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 26 Jun 2014 15:01:46 +0000

> cache a reference to that thing.

OK - so you vote for the GSS3 solution, and you do not propose a different solution than what I suggested.

—>Andy

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 26 Jun 2014 11:38:51 -0400

> OK - so you vote for the GSS3 solution, and you do not propose a different solution than what I suggested.

Yes.

One missing "pro" on the new operation side would be allowing security
labels over auth_sys (or something equivalent).  I suspect that would
actually be useful.  Though if so I'd still hope we could find a way
that used the rpc cred instead of a new operation.

If your main goal is just to drop the label assertions stuff, then
another solution would be just to drop it and not replace it with
anything.  My preference would still be to drop gssv3 entirely for now,
so I'm certainly fine with dropping parts, and leaving them for future
work (gssv4, NFSv4.3, or whatever).

--b.

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 26 Jun 2014 18:58:24 +0000

David,

On Jun 25, 2014, at 6:23 PM, Black, David <[email-masked]> wrote:

> Ok, for the purposes of this discussion - it labels the subject with an identity of some form (could be a classification).  MAC is about compartmentalization - if malware breaks into my account,
> MAC puts the malware in a security box where the malware can do whatever it likes to me all day, but can't get out and go do damage elsewhere, even if it can get "root" (or what it thinks is "root") access and change UIDs, GIDs, ACLs to whatever it wants to …

Got it - a totally separate system from DAC.

> Nonetheless, I think the approach in 1) is "digging in the right place", but this needs some serious expert review by someone who knows multi-level security (MLS) architectures well.

Do you have someone in mind?

>  An important question (expressed in MLS terms) is whether the NFS client can be multi-level or is always single-level (a multi-level NFS client has significant implications for OS architecture and software development practices).  The design approach in 1) appears to be headed for multi-level NFS clients (there will of course be authorization constraints on the server side on what subject labels each NFS client can assert),

So the decision is made once at RPCSEC_GSS3_CREATE time (approach 1), not each time a subject is presented (approach 2)

> whereas approach 2) appears to only support single-level NFS clients (server-side authorization comment also applies here).

Thanks

—>Andy

---

From: "Black, David" <[email-masked]>
Date: Fri, 27 Jun 2014 09:07:57 -0400

Andy,

> > Nonetheless, I think the approach in 1) is "digging in the right place", but
> this needs some serious expert review by someone who knows multi-level
> security (MLS) architectures well.
> 

We could start w/Dave Quigley and Jarret Lu ;-).

> >  An important question (expressed in MLS terms) is whether the NFS client
> can be multi-level or is always single-level (a multi-level NFS client has
> significant implications for OS architecture and software development
> practices).  The design approach in 1) appears to be headed for multi-level
> NFS clients (there will of course be authorization constraints on the server
> side on what subject labels each NFS client can assert),
> 

Taking another look, I'm going to admit to some confusion here - I'm not clear
on how RPCSEC_GSS channel bindings interact with an NFS client that wants to
assert more than one subject label via RPCSEC_GSS, which is related to this "Con"

> >> per RPC credential basis (does this mean a lot more RPC credentials?).

At the very least I think this implies a GSS3 context per subject label.

Thanks,
--David

> From: Adamson, Andy [mailto:[email-masked]]
> Sent: Thursday, June 26, 2014 2:58 PM
> To: Black, David
> Cc: Adamson, Andy; [email-masked]
> Subject: Re: [nfsv4] Two methods of passing the NFSv4.2 LNFS subject label for
> Full Mode
> 
> David,
> 
> > Ok, for the purposes of this discussion - it labels the subject with an
> identity of some form (could be a classification).  MAC is about
> compartmentalization - if malware breaks into my account,
> > MAC puts the malware in a security box where the malware can do whatever it
> likes to me all day, but can't get out and go do damage elsewhere, even if it
> can get "root" (or what it thinks is "root") access and change UIDs, GIDs,
> ACLs to whatever it wants to ...
> 
> > Nope - a crucial property of MAC is that it cannot be bypassed by fiddling
> with DAC, so the UIDs/GIDs are *not* MAC policy inputs because the MAC policy
> engine cannot trust them (e.g., because the malware may have control over
> them).
> >
> > Nonetheless, I think the approach in 1) is "digging in the right place", but
> this needs some serious expert review by someone who knows multi-level
> security (MLS) architectures well.
> 
> >  An important question (expressed in MLS terms) is whether the NFS client
> can be multi-level or is always single-level (a multi-level NFS client has
> significant implications for OS architecture and software development
> practices).  The design approach in 1) appears to be headed for multi-level
> NFS clients (there will of course be authorization constraints on the server
> side on what subject labels each NFS client can assert),
> 
> > whereas approach 2) appears to only support single-level NFS clients
> (server-side authorization comment also applies here).
> 
> Thanks
> 
> ->Andy
> >
> > Thanks,
> > --David
> >

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 27 Jun 2014 15:12:08 +0000

> At the very least I think this implies a GSS3 context per subject label.

Yes - which is my concern WST scaling and server side gss context management. I just don’t know how many subject labels can be expected. 

—>Andy

---

From: Tom Haynes <[email-masked]>
Date: Mon, 30 Jun 2014 10:27:30 -0700

> anything.  My preference would still be to drop gssv3 entirely for now,

^^ If you mean drop it for this and not server-side copy, I’m fine with
that. We have a working LNFS system and the smart server could wait
for gssv4 and someone pushing this actively.