Subject: [nfsv4] [lnfs] MAC Security NFS Modes of Operation

From: Thomas Haynes <[email-masked]>
Date: Fri, 15 Apr 2011 09:53:57 -0500

We seem to have a lot of energy behind discussions about whether we will
support Smart Server Mode (aka dumb client mode) or Smart Client Mode
(aka dumb server model). A variant of this is what we will do with NFSv2,
NFSv3. NFSv4.0, NFSv4.1, NFSv4.2 without LNFS, and NFSv4.2 without RPCSEC_GSSv3.

While interesting, I think the whole area is one big rat hole we want to
avoid. We are designing a transport mechanism for labels and it is
up to the security system put in place to decide what to do with the
content or the lack thereof.

LNFS provides a transport mechanism to set and get the object label.

RPCSEC_GSSv3 provides a transport mechanism to provide the subject label
to the server from the client.

LNFS Server:
===========

Lets consider the LNFS Server that gets a request from one of the following
types of client: NFSv2, NFSv3. NFSv4.0, NFSv4.1, NFSv4.2 without LNFS,
and NFSv4.2 without RPCSEC_GSSv3. As far as that server is concerned,
each of those cases result in selecting a default subject label for that
client. And the decision for that label is entirely the provenance of the security
system. It may be based on user, IP, netgroup, phase of the moon, etc. The
point is that as the transport mechanism, we don't care.

The other interesting cases here are the wrong LFS identifier and the NFSv4.2
without RPCSEC_GSSv3 accessing object labels. The first can either result
in a NFS4ERR_WRONG_LFS or the assignment of a default subject label.  And
again, that is up to the security system to decide. In the second case, if the
security system decides that the applied subject label has MAC permissions,
then the request to access/modify/set the object label will proceed and
can flow across the network.

Finally, we consider the sweet spot, the LNFS aware client that is using RPCSEC_GSSv3.
It can provide a subject label and process an object label.

LNFS Client:
===========

A much simpler scenario - the client decides if it wants to use RPCSEC_GSSv3 (or
if the server doesn't support it, fall back).  BTW - it cannot make any determination
as to whether the server provides LNFS support based on the support for RPCSEC_GSSv3.

The client can then determine whether the server supports LNFS or not with a simple
compound: PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}.  Based on the error
code set, the client is able to determine:

NFS4_OKAY - the server supports LNFS. Further, by examining the LFS of the 
FATTR4_SEC_LABEL, the client can easily tell if they are in the same DOI. BTW:
they can be in a different DOI and the server's security system knows how to map
the client's DOI to it's DOI. The client security system will need to decide if it can also
do the mapping.

NFS4ERR_NOTSUPP - the server does not support LNFS.

NFS4ERR_WRONG_LFS - the server supports LNFS and has decided the client
is presenting a different DOI than it handles.

NFS4ERR_MAC_ACCESS - the server supports LNFS and has decided the client
does not have a subject label that will grant access.

Once the client has this information, the security system on it can decide how to
interact with the server in case it does not support LNFS. I.e., if it does not access
object labels, the security system can determine which to apply to an object.

Conclusion:
==========

We will support the infrastructure for all Modes of Operation. We are the transport
authority. It is up to the security system to decide what to do when a label is
present and what to do when it is not present. We do not create any default labels,
it does.

---

From: <[email-masked]>
Date: Fri, 15 Apr 2011 11:50:56 -0400

Tom,

I have one additional piece of functionality to suggest.

> can flow across the network.

I think we can do better for the NFSv4.2 without RPCSEC_GSSv3 case.  I'll start by agreeing that for NFSv4.2, RPCSEC_GSSv3 adds significant functionality.  My interest is in Smart Client + Smart Server for a s there's no RPCSEC_GSSv3 support.  In that scenario, I think we can provide a useful assist to the server's selection of the subject label for the client.

In this case, the Smart Client has a single label and knows what that label is (in contrast to dumb clients for which the only possible approach is subject label assignment by the server w/o client awareness).  The ability for a Smart Client to communicate its subject label to the server allows the server to check that both the client is using an appropriate subject label (if not, something is wrong, and the server may need to refuse access to the client).  This sort of cross-check can be very useful in practice to catch misconfiguration issues before they do actual damage.

Thanks,
--David

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Friday, April 15, 2011 10:54 AM
To: [email-masked]
Subject: [nfsv4] [lnfs] MAC Security NFS Modes of Operation

LNFS Server:
===========

LNFS Client:
===========

Conclusion:
==========

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Apr 2011 11:20:21 -0500

On Fri, Apr 15, 2011 at 10:50 AM,  <[email-masked]> wrote:
> I think we can do better for the NFSv4.2 without RPCSEC_GSSv3 case.  I’ll
> start by agreeing that for NFSv4.2, RPCSEC_GSSv3 adds significant
> functionality.  My interest is in Smart Client + Smart Server for a s
> there’s no RPCSEC_GSSv3 support.  In that scenario, I think we can provide a
> useful assist to the server’s selection of the subject label for the client.
>
> In this case, the Smart Client has a single label and knows what that label
> is (in contrast to dumb clients for which the only possible approach is
> subject label assignment by the server w/o client awareness).  The ability

I don't see what the smart client really gets from knowing that the
server _probably_ thinks the client's operating at some label that the
client knows...

> for a Smart Client to communicate its subject label to the server allows the
> server to check that both the client is using an appropriate subject label
> (if not, something is wrong, and the server may need to refuse access to the
> client).  This sort of cross-check can be very useful in practice to catch
> misconfiguration issues before they do actual damage.

RPCSEC_GSSv3 allows the client to assert a label while also doing
compound authentication, which then allows the server to decide
whether to allow that label or pick a more appropriate one for the
{client host principal, user principal} combined entity.  The server
should do that by looking up label ranges/sets for the client host and
user principals, then intersecting them, then checking if the asserted
label falls within that intersection.

That's what RPCSEC_GSSv3 buys us here.  Without it we have various
issues, and serious limits to what a smart client and server could do,
even if we had an operation to set the subject label early in a
compound RPC.  At best we could use IPsec to authenticate the client
and RPCSEC_GSSv1/2 to authenticate the user, and pretend that's good
enough combined authentication, but in terms of implementation, that's
a lot of work to get right, and even to get it wrong it's non-trivial.

In other words, I don't really see much, if any, benefit to a smart
client / smart server / no RPCSEC_GSSv3 combination over dumb client /
smart server.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 15 Apr 2011 12:15:49 -0500

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

> I think we can do better for the NFSv4.2 without RPCSEC_GSSv3 case.  I’ll start by agreeing that for NFSv4.2, RPCSEC_GSSv3 adds significant functionality.  My interest is in Smart Client + Smart Server for a s there’s no RPCSEC_GSSv3 support.  In that scenario, I think we can provide a useful assist to the server’s selection of the subject label for the client.
>  

David,

How does the client convey its subject label without RPCSEC_GSSv3? 

What am I not getting about your proposal?

Thanks,
Tom

---

From: "Matthew N. Dodd" <[email-masked]>
Date: Fri, 15 Apr 2011 13:37:52 -0400

On 4/15/11 13:15 PM, Thomas Haynes wrote:
>>> The other interesting cases here are the wrong LFS identifier and
>>> the NFSv4.2 without RPCSEC_GSSv3 accessing object labels. The
>>> first can either result in a NFS4ERR_WRONG_LFS or the assignment
>>> of a default subject label.  And again, that is up to the
>>> security system to decide. In the second case, if the security
>>> system decides that the applied subject label has MAC
>>> permissions, then the request to access/modify/set the object
>>> label will proceed and can flow across the network.
>> 
>> I think we can do better for the NFSv4.2 without RPCSEC_GSSv3 case.
>> I’ll start by agreeing that for NFSv4.2, RPCSEC_GSSv3 adds
>> significant functionality.  My interest is in Smart Client + Smart
>> Server for a s there’s no RPCSEC_GSSv3 support.  In that scenario,
>> I think we can provide a useful assist to the server’s selection of
>> the subject label for the client.
>> 
>> In this case, the Smart Client has a single label and knows what
>> that label is (in contrast to dumb clients for which the only
>> possible approach is subject label assignment by the server w/o
>> client awareness).  The ability for a Smart Client to communicate
>> its subject label to the server allows the server to check that
>> both the client is using an appropriate subject label (if not,
>> something is wrong, and the server may need to refuse access to the
>> client).  This sort of cross-check can be very useful in practice
>> to catch misconfiguration issues before they do actual damage.
> 
> David,
> 

I can't answer for David but I will say that conveying the client
process label in a compound operation (OP_PUTCLIENTLABEL) was something
that was investigated back in 2008.

It was fine from the protocol level but introduced a number of intrusive
changes in the implementation and was deemed unlikely to be accepted.

---

From: <[email-masked]>
Date: Fri, 15 Apr 2011 13:29:59 -0400

> What am I not getting about your proposal?

I haven't (yet) proposed protocol details for how the client conveys its subject label.  I'd like to get through the discussion of whether its useful before embarking on the details of how to do it.

Thanks,
--David

From: Thomas Haynes [mailto:[email-masked]]
Sent: Friday, April 15, 2011 1:16 PM
To: Black, David
Cc: [email-masked]
Subject: Re: [nfsv4] [lnfs] MAC Security NFS Modes of Operation

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

Tom,

Thanks,
--David

David,

Thanks,
Tom

---

From: <[email-masked]>
Date: Fri, 15 Apr 2011 13:44:22 -0400

> server _probably_ thinks the client's operating at some label that the

IMHO, this is looking in the proverbial "wrong place" because it's not the smart client that gains.

The gains are for the security administrator who is responsible for both the smart client and the smart server; she gains assurance that both the smart client and the smart server are applying MAC to the same information in the same fashion because they are using the same subject label for the client.  As should be clear from what follows, there are limits here because the single client subject label prevents the server from enforcing process/user distinctions within the client.

> compound RPC.

I agree that there are "serious limits" - in particular, I'm prepared to accept the limitation that in the absence of RPCSEC_GSSv3, a smart client has to use a single subject label for all of its activity for reasons that include:

> At best we could use IPsec to authenticate the client

That's a "strawman demolition" exercise.  I'm not particularly interested in authenticating the user - the client has to enforce MAC distinctions among its users in this scenario because the client has a single subject label in the absence of RPCSEC_GSSv3.  I want to communicate that one-and-only client subject label to the server when the client first contacts the server, so that the client and server can check that the same label is in use.  I do not see a good reason to communicate the client's subject label after that initial check.

Thanks,
--David

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Friday, April 15, 2011 12:20 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Apr 2011 12:49:31 -0500

> that was investigated back in 2008.

I figured that's what the idea was.

But there's a number of problems with it.  For example, if the GSS
security mechanism is Kerberos and IPsec is not used, then the user
knows or can work out the session key, which means that the user can
bypass the client altogether.  Worse, the user can impersonate the
server to the client and poison the client's cache (this is the real
reason for the RPCSEC_GSSv3 compound authentication feature, though it
also happens to be incredibly helpful for LNFS).  But also, the server
can't really know what client the user is coming from (except via
inspecting the client's IP address), which means that the server can't
do any of the interesting things I described in the RPCSEC_GSSv3 case.

What is the allure of avoiding RPCSEC_GSSv3 though??

> changes in the implementation and was deemed unlikely to be accepted.

And there's that too.  Without this the local credentials are derived
from the RPC security layer.  With this operation you now have to
construct a new credential when you see this operation, and then
substitute it for the old one.  Many such hacks add up to an ugly,
unmaintainable mess.  Moving the problem to the RPC security layer
-where it always belonged- solves the problem in an architecturally
clean way.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Apr 2011 12:56:31 -0500

> IMHO, this is looking in the proverbial "wrong place" because it's not the smart client that gains.

I don't get that comment, but OK.

> The gains are for the security administrator who is responsible for both the smart client and the smart server; she gains assurance that both the smart client and the smart server are applying MAC…

What, because the client happens to claim to be?  You don't need an
NFS op for this.

IOW, smart client / smart server / no RPCSEC_GSSv3 works the same
whether you add an NFS set-subject-label op or not IF you constrain
the client to a single label.

Also, dumb client refers to the inability to speak the new protocol,
not to the inability to apply MAC locally.  A dumb client can still
apply MAC locally.  If the server authenticates the client (whether
strongly with, say, IPsec, or weakly, with, say IP address checks)
then the server knows it can trust the client to apply MAC policy
locally.  But without RPCSEC_GSSv3 the server has to see the client at
a single label.

> That's a "strawman demolition" exercise.  I'm not particularly interested in authenticating the user - the client has to enforce MAC distinctions among its users in this scenario because the client…

Why communicate the one-and-only subject label when you can just look
it up in the same way as in the dumb client / smart server?  It's not
like you can trust an unauthenticated client to assert just any label
-- you have to apply constraints, and since the constraint must yield
a single label, what's the point of the client asserting it??  What am
I missing?

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 15 Apr 2011 14:22:44 -0500

> I think we can do better for the NFSv4.2 without RPCSEC_GSSv3 case.  I’ll start by agreeing that for NFSv4.2, RPCSEC_GSSv3 adds significant functionality.  My interest is in Smart Client + Smart Se…

I'd have to question why someone would go to all of the trouble
of implementing LNFS on the client and server, setting up a DOI,
and then not using RPCSEC_GSSv3.

It implies to me either that RPCSEC_GSSv3 is too heavy and hard
to implement or that there is a fundamental issue with
RPCSEC_GSSv3.

I'd really like to know why someone would not want RPCSEC_GSSv3
before I'd want to consider alternate methods of communicating the
subject label.

Also, if the client could have one-and-only one subject label, then
I don't see why it would be needed to be communicated via LNFS.
That falls into the provenance of the security system determining
the subject label. Unless of course the aim is to only have port 2049
open in a firewall and there is no other way for the client to
convey that information to the server.

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Apr 2011 14:24:44 -0500

> convey that information to the server.

+1

---

From: <[email-masked]>
Date: Fri, 15 Apr 2011 15:51:16 -0400

> a single label, what's the point of the client asserting it??  What am

Suppose server lookup yields label A for the client, but the client asserts
label B.  That's not a good situation to ignore - something is wrong that
needs the security admin's attention (and security policy could prohibit
that client's access until this situation is corrected, as opposed to allowing
that client access with subject label A).  The difference here is that the
dumb client can't do anything MAC-aware, whereas the smart client can, and
inconsistent application of MAC is not good.

While the security admin is supposed to be careful to get the MAC policy
configured correctly and consistently everywhere, to err is human,
and this extra check can help catch a config mismatch.

The "unauthenticated" statement is correct - one can't just trust the
subject label.  This is a configuration check - if the client's not
doing what it's supposed to be doing (based on subject label), go
get (admin) help.  In addition, there will be other restrictions - if
the network is not otherwise secured against man-in-the-middle attacks,
this could be a denial-of-service vector that requires something else
(e.g., IPsec, older version of RPCSEC_GSS) to protect it.

Beyond that (at the risk of opening a Pandora's box), I believe Sorin
has mentioned the notion of a server "reinforcing" smart client MAC -
this could take the form of a partially smart server (e.g., that enforces
coarser grain MAC policy/controls by comparison to the finer grain
complete MAC policy/controls on the clients).

Tom writes:

> It implies to me either that RPCSEC_GSSv3 is too heavy and hard to
> implement or that there is a fundamental issue with RPCSEC_GSSv3.

The former - I'm anticipating implementation concerns.

Thanks,
--David

> Sent: Friday, April 15, 2011 1:57 PM
> To: Black, David
> Cc: [email-masked]
> > The gains are for the security administrator who is responsible for both the smart client and the
> smart server; she gains assurance that both the smart client and the smart server are applying MAC
> to the same information in the same fashion because they are using the same subject label for the
> client.  As should be clear from what follows, there are limits here because the single client
> subject label prevents the server from enforcing process/user distinctions within the client.
> 
> > I agree that there are "serious limits" - in particular, I'm prepared to accept the limitation
> that in the absence of RPCSEC_GSSv3, a smart client has to use a single subject label for all of its
> activity for reasons that include:
> >
> > That's a "strawman demolition" exercise.  I'm not particularly interested in authenticating the
> user - the client has to enforce MAC distinctions among its users in this scenario because the
> client has a single subject label in the absence of RPCSEC_GSSv3.  I want to communicate that one-
> and-only client subject label to the server when the client first contacts the server, so that the
> client and server can check that the same label is in use.  I do not see a good reason to
> communicate the client's subject label after that initial check.
>

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 18 Apr 2011 16:05:15 -0500

> inconsistent application of MAC is not good.

By smart client, you mean one which has implemented the security system
for the DOI and can speak LNFS. In this case, if the client asserts label
B, it can just as easily convey that information to the process which
hands out the information in the dumb client/smart server approach.

I think we need to be very careful here in realizing we are a transport
mechanism and not part of the security system. If the server has a
security policy in place to disallow clients who yield a different label
than their own lookup, then that policy should trump our decision.

Isn't it a maxim in security that when in doubt, deny access?

As a matter of fact, we make no MAC decisions at all, that is all
passed into the security layer.

BTW - what would happen in the case that a smart client asserted label
B by this mechanism, but was also using RPCSEC_GSSv3 and it
asserted label C?

We can avoid all of these issues if we stay with the very simple
requirement that if the smart client wants to provide a subject label, it
does so through RPCSEC_GSSv3.

> and this extra check can help catch a config mismatch.

I think someone who can't access data will be a very good extra
check for a config mismatch and will quickly inform the server
admin.

The argument being presented here has a precedent in the
export model most servers implement. If I deploy a new client,
I don't look to it to see if it is allowed access. If it is not allowed
access via an export policy, it does not get access. And users
on that client will be very diligent in filing a helpdesk ticket to
get the policy corrected.

> (e.g., IPsec, older version of RPCSEC_GSS) to protect it.

Why require an older version of RPCSEC_GSS and not the one designed
to provide a secure subject label?

> complete MAC policy/controls on the clients).

Again, I think we need to separate designing the transport layer from
designing a security system.

Subject label is provided via RPCSEC_GSSv3.
Object label is provided via LNFS.

All defaults are handled by the implementation of the security system.

> The former - I'm anticipating implementation concerns.

Then we address them.

I would rather we focus on making RPCSEC_GSSv3 a good design
that people will want to implement rather than to compromise the
design for LNFS.

---

From: <[email-masked]>
Date: Tue, 19 Apr 2011 17:05:24 -0400

Tom,

> that people will want to implement rather than to compromise the

If we can define a minimum subset/profile of RPCSEC_GSSv3 that communicates the label with reasonably low implementation impact (some of the usual security services may not be implemented), then that provides a cleaner solution than going outside of RPCSEC_GSSv3.  I'm ok with putting this topic on hold for now, and pick it up in the context of the implementation requirements for RPCSEC_GSSv3.

Thanks,
--David

From: Thomas Haynes [mailto:[email-masked]]
Sent: Monday, April 18, 2011 5:05 PM
To: Black, David
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] [lnfs] MAC Security NFS Modes of Operation

On Apr 15, 2011, at 2:51 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Nico writes:

Tom writes:

Then we address them.

Thanks,
--David

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Apr 2011 17:21:11 -0500

David,

Before speculating that RPCSEC_GSSv3 is difficult to implement, could
you... review the I-D and give us some feedback?

Also, since we have an implementor, maybe we could ask them for
feedback (as I've suggested earlier).  Indeed, we do have some
feedback, but not along the lines of "wow that was difficult" nor "wow
that was easy", nor anything in between.

I mean, is it the case that any new is presumed to be difficult to
implement?  Or is it anything new with "SEC" in its name?  Or anything
new in ONC RPC security?  Is it that the RPCSEC_GSSv3 I-D deals in
things other than subject labels?  Is it that anything new authored by
yours truly is presumed to be difficult?

I don't appreciate argument by FUD.  Especially when an argument by
FUD would have us violating abstraction layers -- an extraordinary
requirement that ought to require extraordinary justification.  Have
you stopped to consider that a trivial operation that violates
abstraction layers may not be trivial to implement?  (I don't think
that's the case, but we ought to discuss that too, shouldn't we, since
simple but wrong ought not be presumed to be simple.)

+1

> If we can define a minimum subset/profile of RPCSEC_GSSv3 that communicates
> the label with reasonably low implementation impact (some of the usual
> security services may not be implemented), then that provides a cleaner
> solution than going outside of RPCSEC_GSSv3.  I’m ok with putting this topic
> on hold for now, and pick it up in the context of the implementation
> requirements for RPCSEC_GSSv3.

I have already explained that I'm happy to add "profiling", though
since all feature use is up to the _client_ it is already the case
that RPCSEC_GSSv3 is trivially profiled, thus profiling it is a mere
matter of adding text (not XDR) to the effect that implementors are
free to omit features they wouldn't use -- but... that should be
obvius.

What I'm NOT willing to do is go along with your presumption that
until we've added such trivial text then RPCSEC_GSSv3 is too
difficult.  I will oppose the addition of any "set process label"
operation to NFSv4.2 until you make a convincing argument for it.  I
imagine from his comments that Thomas' position is similar to mine.

Nico
--

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 19 Apr 2011 15:51:35 -0700

I agree with Nico that RPCSEC_GSSv3 won't be difficult to implement.
If you have implemented RPCSEC_GSSv1 (and AFAIK, every NFSv4.0
implementation shipped for commercial sale [including Linux from
distributors like RedHAt and Novell] has RPCSEC_GSSv1 support).

I suspect the issue is deployment of the underlying security mechanism
that makes RPCSEC_GSS real, i.e., Kerberos V5. Outside of Windows,
Kerberos V5 deployments are non-trivial.

At some point, this has to be fixed. The worm that exploits AUTH_SYS and
reads and or deletes every byte of data stored on NFS servers has yet to
be written, but it will be written and deployed. It's too glorious a hack
for a Black Hat to not enjoy.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 19 Apr 2011 18:14:32 -0500

> for a Black Hat to not enjoy.

So you are saying we have a hard shell protecting a medium core?

I.e., a data center is secured by Firewalls, other security, or even a
lack of external access. The clients and servers are protected via
a security system which controls MAC label checking.

But the transport layer is not protected?

This is a somewhat similar issue as to how we authenticate server side
copy if RPCSEC_GSSv3 is not deployed.

I still see this as an issue for the security system in constructing default
subject labels. If a subject label is constructed via RPCSEC_GSSv3, then
it is taken to be authoritative. If the client is using AUTH_SYS, then we
are able to present to the security system the client IP (network, subdomain,
netgroup, yada yada), the user UID, and the user GID(s).

The security system can then decide if "Bob Smith" from 192.168.12.13 has
'Top Secret' or 'Secret' classification. It may decide that either by static rules
encoded on the server or it may consult some external authority. If it is
a static ruleset, then the burden is on the admin to get the rules correct.

If it is some external authority, then the client can register a label with it.
I.e., this is the proposed new feature op, just taken out of LNFS and into
the control of the security system.

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Apr 2011 18:28:38 -0500

Regarding the difficulty of deploying infrastructures and credentials for
security mechanisms: if you need or want to do labeling and can afford it,
then you can afford to deploy security mechanisms :/

Nico
--

---

From: <[email-masked]>
Date: Tue, 19 Apr 2011 19:30:06 -0400

Nico,

> yours truly is presumed to be difficult?

Give me a break - this is getting silly ... particularly the last question.

> obvious.

My concern is server-side, and I may well take up that "profiling"
offer at some point in the future.  If both clients and servers are free
to pick and choose among what features to implement, interoperability
becomes interesting.

Thanks,
--David

> Sent: Tuesday, April 19, 2011 6:21 PM
> To: Black, David

---

From: David Quigley <[email-masked]>
Date: Tue, 19 Apr 2011 21:30:06 -0400

On Tue, 19 Apr 2011 18:14:32 -0500, Thomas Haynes wrote: 

>> I agree with Nico that
RPCSEC_GSSv3 won't be difficult to implement. If you have implemented
RPCSEC_GSSv1 (and AFAIK, every NFSv4.0 implementation shipped for
commercial sale [including Linux from distributors like RedHAt and
Novell] has RPCSEC_GSSv1 support). I suspect the issue is deployment of
the underlying security mechanism that makes RPCSEC_GSS real, i.e.,
Kerberos V5. Outside of Windows, Kerberos V5 deployments are
non-trivial. At some point, this has to be fixed. The worm that exploits
AUTH_SYS and reads and or deletes every byte of data stored on NFS
servers has yet to be written, but it will be written and deployed. It's
too glorious a hack for a Black Hat to not enjoy.
> So you are saying we
have a hard shell protecting a medium core? I.e., a data center is
secured by Firewalls, other security, or even a lack of external access.
The clients and servers are protected via a security system which
controls MAC label checking. But the transport layer is not protected?
This is a somewhat similar issue as to how we authenticate server side
copy if RPCSEC_GSSv3 is not deployed. I still see this as an issue for
the security system in constructing default subject labels. If a subject
label is constructed via RPCSEC_GSSv3, then it is taken to be
authoritative. If the client is using AUTH_SYS, then we are able to
present to the security system the client IP (network, subdomain,
netgroup, yada yada), the user UID, and the user GID(s). The security
system can then decide if "Bob Smith" from 192.168.12.13 has 'Top
Secret' or 'Secret' classification. It may decide that either by static
rules encoded on the server or it may consult some external authority.
If it is a static ruleset, then the burden is on the admin to get the
rules correct. If it is some external authority, then the client can
register a label with it. I.e., this is the proposed new feature op,
just taken out of LNFS and into the control of the security system.
_______________________________________________ nfsv4 mailing list
[email-masked] [1] https://www.ietf.org/mailman/listinfo/nfsv4 [2]

I
agree with what Tom is proposing here. I think that is the most flexible
way of handling this. We should strongly encourage people to implement
RPCSEC_GSSv3 along with the label transport mechanism because it
provides the best capability for developing a coherent security policy
but falling back to subject labeling based on other criteria in its
absence is probably the best that we can do. 

Dave

Links:
------
[1]
mailto:[email-masked]
[2] https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Matthew N. Dodd" <[email-masked]>
Date: Tue, 19 Apr 2011 21:37:32 -0400

> that was easy", nor anything in between.

FWIW the GSSv3 stuff hasn't been a big issue.  It's interfacing with the
existing GSSv1 implementation that has consumed the most time.  I'd be
more than happy to discuss this in detail but it's not really cogent to
the standards discussion.

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Apr 2011 21:48:42 -0500

> Give me a break - this is getting silly ... particularly the last question.

You're right, of course, that was over the top.  I was frustrated at
the lack of substance coupled with an alternative that seems like a
cop out (and I needed dinner).

So let me try a different approach: doing the review that I wanted to
see from you, using your point of view that as much of RPCSEC_GSSv3
should be optional as possible.  Additionally, I'm going to make
explicit something that needs to be: reasonable client behavior vs.
server-side optionality.  Finally, we'll keep security in mind.

> to pick and choose among what features to implement, interoperability

Yes, and because this is a security mechanism we must also not lose
track of what is critical and what is optional.

RPCSEC_GSSv3 adds only these three features over v1: a) compound
authentication, b) channel binding, c) assertions.

(a) is necessary for a number of reasons that I will not cover here --
we'll leave it at compound authentication being REQUIRED in the real
world and, therefore, that we have no good reason not to make it
REQUIRED in RPCSEC_GSSv3.

(b) is and should be REQUIRED to implement, and it's really trivial to
do so.  NOTE: it's NOT trivial to implement IPsec CB, but that's a
matter for the IPsec layer, not for the RPCSEC layer, and implementing
CB in the RPCSEC layer is quite simple.  If there's no channel to bind
to, then CB is not used, and if there is a channel to bind to it's
much better bind to it than not.

(c) is where client choices of criticality versus optionality matter.
And here it's likely that we need to at least provide more guidance to
client implementors.  (c) is also where identify, privileges and
labeling come in.

Therefore (c) is what's interesting to cover here, from your point of
view.  Though I suppose you might reasonably disagree with my
characterization of (b), but before you disagree regarding (a) wait
for a subsequent message explaining why (a) is so important.

So what kinds of assertions might a client want to make critically vs.
optional?  I think:

 - all assertions that, if accepted, would result in more access for
the subject should be optional;
 - all assertions that, if accepted, would result in *less* access for
the subject should be critical.

For identify and privileges the critical assertions would be those
where the subject's client-side process credentials are reduced
relative to the user's initial process credentials (think of running
processes with reduced privileges (Least Privilege) and or fewer
supplementary groups), as well as process credentials where the user
ID and/or primary group ID are different from the user's but
nonetheless the process credentials somehow share the user's GSS-API
credentials (think of AFS PAGs, which is a way to associate network
credentials with _groups of processes_).

For labels, the client should make critical assertions in general.
It's not critical that the server use the client's asserted process
label because the server might want to map it to another, but it's
critical that the server _understand_ the client's asserted process
label.

Now, RPCSEC_GSSv3 does allow critical and optional assertions, and it
allows many assertions, including multiple assertions of the same sort
(i.e., identity, privilege, label).  Which does mean that the server
can fail to implement assertions that will typically be optional --
and this is the key: we must minimize critical assertions if we want
any of the three assertion types to be optional-to-implement on the
server-side, otherwise the pressure to implement them will be very
high and therefore those assertion types will be de facto
required-to-implement.

So how does a client minimize the need to make critical assertions?
Good question!!  There's an answer, but it really needed to be thought
of.  Here's my answer: clients must distinguish between "process
credentials for user logon" from reduced credentials for the same
logon.  Which means, in terms of client kernel architecture (for
Windows, Linux, *BSD, and Solaris) that the process token/cred_t must
have a reference to the initial, unadulterated token/cred_t for the
user so that the client can determine in what ways a process
credential differs from the initial process credentials for a given
login session.  If a process credential is strictly a super-set of an
initial one, then no critical assertions need be made (even process
label could be obtained by the server in the same way as by the
client, using the user's GSS credentials).  If a process credential is
in any way (identity, privileges, or label) a sub-set of the user's,
then the client must make corresponding critical assertions and be
prepared to deal with the server's rejection of any or all of those.

I'm expecting that typically reduced privilege processes of a user
will either a) not be reduced w.r.t. filesystem privileges, and/or b)
wont try to access files over NFS.  So reduced privilege processes
will not often cause critical assertions to be needed in RPCSEC_GSSv3.
 In the disk-less case critical privilege assertions will be needed
quite often, but where specific support from the server will also be
desired, thus making critical privilege assertions a non-issue in that
case.

I'm also expecting that reduced privilege via reduced supplementary
group lists will also be an infrequent use case for critical
assertions.

Critical assertions where a process' user ID and/or primary group ID
differ from the user's whose network credentials the process uses for
NFS will also probably be infrequent, mostly because the user will
typically not be accessing NFS resources in those cases (see above
regarding disk-less-ness though).  And where such processes do try to
access NFS resources, failure presumably will not be fatal.  If I'm
wrong about the frequency of such events, however, pressure to add
server-side support for critical identity assertions will go up, of
course.

Note that _today_ clients rarely need to make critical assertions
about identity and privileges for these reasons -- otherwise we'd have
seen a lot of market pressure for something like RPCSEC_GSSv3 much
earlier.  I.e., today clients either do not use a user's network
credentials on behalf of reduced privilege processes of or related to
that user, or else the do use those credentials and the attendant
security problem is simply considered acceptable and that's that.

This leaves process (subject) label assertions.  These will only
differ from the user's initial subject label in multi-label capable
clients, and only when the client's and/or user's label set/range
permit it (for a properly functioning client anyways).  And
multi-label clients will probably login users with processes running
at a variety of labels, with most user processes probably defaulting
to least-dominant labels.  Such clients will surely, then, need to
make frequent critical process label assertions.  Servers,
nonetheless, need not support labeling at all -- such servers can only
be used in the smart client / dumb server label model.

Aha!  We probably need a way for clients and servers to use
RPCSEC_GSSv3 even when the server doesn't support labeling at all (or
not for a DOI requested by the client).

Alright, so there's at least one change we need to make to the
protocol then, plus text changes to cover all of what I've written
here, and whatever else you and others contribute.

Note also that I proposed a change earlier to the XDR: that we remove
the new enum auth_stat values -- RPCSEC_GSSv3 should always succeed,
even in cases where critical assertions are rejected or not supported,
and the client should see what the server rejected and decide whether
to continue or abort.  This change too helps obtain optionality of
feature support.

All that said, I think server implementors will want to implement all
three assertion types.  Critical assertions, then, will typically fail
only because of mapping problems or for policy reasons (e.g., the
client asserted a privilege not understood by the server, or maybe
made a negative assertion about a basic privilege not understood by
the server, or made a critical identity assertion for an identity that
the server cannot understand or locally represent, or perhaps a
critical assertion was rejected by policy because the client and/or
user are not allowed to make such an assertion, and so on).

Also, server implementors kinda have to (and often do) handle at least
subject identity in a fine-grained way, and easily could (and some do
or very easily could) handle privileges in a fine-grained way (there's
relatively few filesystem-related process privileges, even with all
the additions over Solaris' that I found in Linux, TrustedBSD, and
Windows).  This leaves process labels as the one area where server
support is likely to be brand new, and even then probably not really,
since quite a few operating systems exist that have label support for
one or more label systems.

Does this about cover it for you?

Now's your turn to berate me for having failed to make such a detailed
analysis earlier.  It's only fair, after my previous message :(

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Apr 2011 23:46:50 -0500

> REQUIRED in RPCSEC_GSSv3.

Reasons why (a) is necessary:

1) The client is a proxy for its users, and it is typically a
multi-user client, and the server does need to trust it to operate
correctly.  Ergo, it does seem clear that the server should want to
authenticate BOTH, the client and the user(s) on that client.  It's
also clear that clients and users have different credentials from each
other since clients could act on the own behalf instead of on behalf
of any users, and also since each user must be authenticated
distinctly from other users.

2) The server can make more interesting decisions about what a
client-side subject process' credentials will be on the server based
on a combination of constraints on assertions allowed to the client
and user separately.  For example, the server might allow the client
to assert privileges that a user lacks when the server trusts the
client to operate correctly (and has authenticated the client) and
also has authenticated the user and knows the user's max privileges --
here the server might compute the set union of the client's and user's
max privileges and then intersect with the asserted privileges to
obtain a set of actual privileges.  Clearly this requires the server
to know the authenticated identities of both, the client and user,
which in turn requires authenticating both.  Sure, RPCSEC_GSSv1 can
authenticate both, but not at the same time -- a security context that
authenticates the user cannot authenticate the client, leaving the
server to, at best, do IP address-based client "authentication", which
is to say: not really.

3) Some GSS-API mechanisms work in such a way that a user can recover
the session keys for GSS security contexts where the user is the
initiator principal.  This means that with such mechanisms the user
can impersonate the server to client and poison the client's cache
unless the client takes such steps as would render such an attack
impossible.  One obvious fix is to do channel binding to a channel
whose session keys the user cannot recover -- but there won't always
be a channel to bind to, and for now there won't be any anyways.
Another fix is to authenticate the client and the user separately and
then use the client's security contexts for itself to protect the
exchanges where it acts on behalf of a user.  The latter is quite
simple, thus the obvious strategy to pursue here (though CB is also
desirable for independent reasons, thus also thrown in, just not to
solve this problem).

There's probably other reasons, but any one of the above ought to more
than suffice to make (a) REQUIRED to implement.  I hope I've convinced
you that (a) is critically important to us.

(b) is trivial to implement in RPCSEC_GSSv3, and will be useful, thus
there's no reason to oppose it being REQUIRED to implement.  (As
opposed to IPsec, where one must first implement RFC5660, which likely
no one has done yet -only two implementations that I know of coming
close to it- but that doesn't mean that one should not implement CB in
RPCSEC_GSSv3).

We need only figure out the negotiability/optionality/criticality of assertions.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Apr 2011 23:53:49 -0500

To summarize, we should:

 - Add much text explaining when assertions should be critical.
 - Point out the fact that in order to determine when an assertion
should be critical the client needs to keep track of a model,
unadulterated (e.g., by local policy) process credential for a user to
compare related process credentials to, the comparison yielding such
assertions (critical or not) that must be made on the wire.  This is
an architectural change for most clients.  To put it in Unix terms, a
new system call may well  be needed by which PAM (or PAM applications)
may mark a process' credentials as the "model" for a user's
credentials.
 - Integrate the previous change I proposed in response to Matthew's
implementation comments.
 - We may need to add a mechanism by which the client can decide to
continue talking to a server that doesn't support labeling or a the
client's specific LFS/DOI.  Comments on this one?  Please refer to the
I-D text!

Any other changes?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 Apr 2011 09:26:07 -0500

> may mark a process' credentials as the "model" for a user's

Also, note that lacking the ability to do this the client has to
choose between making all its assertions optional or all critical (or
label critical and all others optional).  Making all of its assertions
optional will interop best but be least secure, while making all its
assertions critical will only interop well with servers that support
all three assertion types well, but will have the best security.  I
expect most clients to do one of these at first.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 24 Apr 2011 21:05:41 -0500

> expect most clients to do one of these at first.

I think then one can make the argument that server implementors will
really want to implement all three assertion types (IDs, privs,
labels).  The first is easy -- clients and servers already have to
deal with identities in ACLs and what not.  The second is also easy
since there's a fairly small set of imaginable process privileges
relating to filesystems -- at most a few more privs than there are
NFSv4 ops, and actually many fewer -- and most general purpose
operating systems already support a fine-grained privilege model
including methods for splitting existing privileges into more
fine-grained ones.

That leaves the third assertion (labels) type as potentially difficult
to implement.  And labeling is going to be by far the most difficult
assertion type to implement because that's where we have a fairly
large amount of variation (MLS, SELinux, Smack, ...) and the need for
for extensive policy replication/distribution (e.g., in the cases of
SELinux and Smack).

IOW, we really need not worry about the implementation complexity of
the non-labeling aspects of RPCSEC_GSSv3 -- labeling is the hardest
aspect of it, and that's just inherent in labeling.  There's little
point in being concerned about the difficulty of implementing the
remainder of RPCSEC_GSSv3.

Given this I'd be quite happy to make all of RPCSEC_GSSv3 REQUIRED to
implement on the server side.  I'd also be happy to not do that.

Nico
--