Subject: RE: [nfsv4] issue 40: pNFS: DS and MDS with different security mechanisms in use

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 11 Jul 2006 17:32:45 -0400

> > System administrators have the right to do apparently stupid things.

> > However I don't necessareily think that is stupid.
> > I might use krb5i for the MDS, and krb5 for the data, and put the
MDS 
> > on an open network, and the DSes on physically more secure networks.

> you're envisioning multi-homed clients mounting the MDS on one
netgroup (with
> krb5i) and getting data from another netgroup (physically secure
network).

> you're right! system adminstrators have the right to do apparently 
> stupid things! why not put the MDS on the secure network and be done
with it?

> hmm.

> one of the reasons i would turn on integrity, is that i want to ensure
that 
> the data has not changed due to bit rot in the network. your example
takes 
> away that feature of integrity, diluting the notion of mounting with
integrity.

Yes, but one of the reasons that you might not turn on integrity is its
cost.

Not turning on integrity is a perfectly valid choice, and if it weren't,
then
v4 should not support any security flavors that don't provide integrity
but
we haven't done that.

In mike's example, we have someone who is turning on integrity, not
because of
worries about bit rot but worries about somebody deliberately modifying
the 
data.  He has a right to that and he should have a right to dispense
with
what, when the physical network setup makes that desirable, from his
point
of view.

What Mike has proposed, makes it also possible for him to independently
use
integrity when going to the metadata server, and I think that
flexibility
is good even though people can do silly things with it. 

> > 
> > On the flip side, I might invert your example and use krb5p for
data, 
> > and krb5i for metadata; I may not care if file handles are
encrypted, 
> > but I may care if data is encrypted.

> that's all fine, except, it's not the notion of privacy/integrity that

> NFSv4.0 has, and some combinations of MDS/DS secinfo most definiatly 
> collide with NFSv4.0 security statements.

Strictly speaking, it is not the same notion.  It can't be because v4.0
doesn't have the DS/MDS distinction.  But the privacy/integrity used in
each
particular instance does match the NFSV4.0 notion.  I don't see the
collision you are talking about.  NFSV4.0 allows you to have filesystems
exported with both kerberos-integrity and AUTH_SYS.  You get integrity
in only some of the cases.  Every day people export filesystem allowing
AUTH_SYS for some some set of clients and other not.  Some of those
combinations make sense and some don't.  The point is the protocol does
not enforce good practice but allows a range of choices.

It seems to me that if you are willing to accept less security from 
client A because of network considerations, then it also seems
reasonable
to allow it from the combination of client A and DS B because of 
similar considerations.

> the MDS of course. only READ/WRITE/COMMIT are allowed to the DS. this 
> is not only the trend that the pNFS spec is taking, this is a concrete

> statement!

But is it a concrete accurate statement?

I think we need to have a definitive list of what ops are valid to the 
DS, and whether it includes SECINFO_ON_NAME as Mike's proposal would
imply, there are certainly more than three.

You have to be able to do PUTFH to do the others.
 
Now that sessions are mandatory, you have to be able to do SEQUENCE.

so you also have to be able to create a client-id and create a 
session.  You probably also need to be able to destroy a session.

Even though DS's can't have locks, I think we have a possiblity of
DS's that can be MDS for other file systems.  This probably means that
a give client instance might not have information to be sure that the
server knows it has no locks, so I think ti may be that the client
may have to have the ability to do RECLAIM_COMPLETE.

Anyway, I think the definitive list has yet to be written.

> > NFSv4.0 does allow different security flavors for different replicas

> > of the same file though, so I see a parallel here.

> hmm, i don't. different security flavors for different operations to 
> an export is not the same as different security flavours to different 
> exports.

It's not an identical situation but there are similarities.  The 
critical similarity is that the client is typically accessing a 
different server.

> remember the discussions of security WRT pNFS blocklayout? and how, 
> since SCSI has no security features, that there is a problem with the 
> minor versioning rules - that the security features of NFSv4.0 must 
> be upheld by the storage protocol? this was an IETF critique of the 
> first pNFS draft, and is the issue i'm raising with this proposal.

I disagree.  The issue with the blocklayout is that the storage protocol
does not (or might not be thought to) provide the requisite security
features, i.t. those mandated by v4.0.  Here we have no such issue.
Since the storage protocol is v4, we meet those requirements.  Those
requirements do not mandate use of any particular level of security.
You can use AUTH_SYS, but you must implement support for kerberos.
That remains the way things are in pNFS with or without Mike's proposal.
The server may mandate use of particular flavors and there is nothing
in v4.0 security requirements that I know of that would not allow the
server to be selective about that except that he has to be able to 
communicate his requirement to the client.  Given the way the pNFS
file variant works, he can communicate separate security requirements
for DS and MDS and so he might as well be allowed to.  

> and we will have to resist, and stay within the minor versioning rules

> which don't allow a lessening of NFSv4.0 features, including security.

For the files variant, the only thing that I think would consititute 
a lessening is allowing DS's not to implement kerberos (nobody has 
suggested that), or to ignore permissions, ACL's, etc (and nobody 
suggested that either).

-----Original Message-----
From: William A.(Andy) Adamson [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 12:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] issue 40: pNFS: DS and MDS with different security
mechanisms in use

> 
> 
> --- "William A.(Andy) Adamson" <[email-masked]> wrote:
> 
> > 
> > a couple of comments:
> > 
> > 0) what does it mean to choose krb5p with the MDS and get krb5 to 
> > the DS?
> > krb5p means data privacy, yet it is exactly and only the data in 
> > this example that is _not_ private! this seems like false 
> > advertising! why should an MDS be able to claim to export a file 
> > system with privacy, and yet not encrypt the data! this dilutes the 
> > whole notion of security. what advantage do i as a client get from 
> > having krb5p on the metadata when the data has no privacy????
> 
> System administrators have the right to do apparently stupid things. 
> However I don't necessareily think that is stupid.
> I might use krb5i for the MDS, and krb5 for the data, and put the MDS 
> on an open network, and the DSes on physically more secure networks.

you're envisioning multi-homed clients mounting the MDS on one netgroup
(with
krb5i) and getting data from another netgroup (physically secure
network).

you're right! system adminstrators have the right to do apparently
stupid things! why not put the MDS on the secure network and be done
with it?

hmm.

one of the reasons i would turn on integrity, is that i want to ensure
that the data has not changed due to bit rot in the network. your
example takes away that feature of integrity, diluting the notion of
mounting with integrity.

> 
> BTW, building knowledge or assertions of the relative strength of 
> secinfo tuples is a lose.  Taking your example, the the MDS krb5p 
> protection might be using a ticket with a
> 256 bit AES encryption type, but the DS krb5p protection might be 
> using single DES. Which one is higher protection? I can't tell.

yes, but we _can_ tell that both are stronger than no privacy!

> 
> On the flip side, I might invert your example and use krb5p for data, 
> and krb5i for metadata; I may not care if file handles are encrypted, 
> but I may care if data is encrypted.

that's all fine, except, it's not the notion of privacy/integrity that
NFSv4.0 has, and some combinations of MDS/DS secinfo most definiatly
collide with NFSv4.0 security statements.

> 
> > 
> > 1) this is a change from NFSv4.0 which does not allow different 
> > security flavours on READ/WRITE/COMMIT from other operations. is 
> > this legal under the minor version rules? doesn't this lessen the 
> > notion of security?
> 
> NFSv4.0 does allow different security flavors for different replicas 
> of the same file though, so I see a parallel here.

hmm, i don't. different security flavors for different operations to an
export is not the same as different security flavours to different
exports.

> 
> In any case, a client has to cope with this scenario even if we 
> mandate the MDS and DS use the same secinfo:
> 
> - client contacts MDS, is told to use secinfo X
> - client contacts DS, uses secinfo X for a while
> - server administrator changes secinfo from X to Y
> - client now gets a NFS4ERR_WRONGSEC. Does the current
>   spec say the client goes to the MDS to get the SECINFO, or
>   the DS? If the latter, then the proposal for issue 40 is
>   consistent with the trend the spec was taking.

the MDS of course. only READ/WRITE/COMMIT are allowed to the DS. this is
not only the trend that the pNFS spec is taking, this is a concrete
statement!
 
> 
> > 
> > 2) if we are going to do this, then the DS secinfo_4 MUST be a 
> > subset of the MDS secinfo_4, including associated mount options. an 
> > example would be an export that uses sec=krb5 -o rw and sec=sys -o 
> > ro. the DS should not be allowed to export sec=sys rw.
> 
> I don't understand the subset issue.

it was an attempt (perhaps not a good idea) to limit the choices for the
DS secinfo.

do you think the protocol should allow krb5p on the mount, where the MDS
secinfo has no mention of sec=sys, and allow sec=sys on the DS - so
krb5p to MDS, sys to DS?

remember the discussions of security WRT pNFS blocklayout? and how,
since SCSI has no security features, that there is a problem with the
minor versioning rules - that the security features of NFSv4.0 must be
upheld by the storage protocol? this was an IETF critique of the first
pNFS draft, and is the issue i'm raising with this proposal.

> 
> Keep something else in mind ... in many export models I can do:
> 
>   exportfs -o sec=krb5,rw=netgroup1,sec=sys,ro=netgroup2
> 
> If a pNFS client has multiple interfaces, it is quite possible the 
> interface used to talk to the MDS is different than the interfaces 
> used to talk to the DSes. So the administrator, perhaps by accident 
> could have rw access to the MDS, and ro access to the DS.

in which case, under the current same secinfo for DS as MDS, writes will
fail and the administrator (who did an apparently stupid thing) will fix
it.

> 
> > 
> > 3) if we are going to do this, then the differing DS security 
> > choices should be expressed in the MDS /etc/exports for all to see.
> 
> /etc/exports is an implementation thing.

ok

> 
> > 
> > 
> > to me, this simply adds complexity with little or no value. please 
> > give some examples to show the value of this issue.
> 
> It may be more complex to coordinate secinfo5s across MDS and DSes.
> 
> If it is easier for a server to use one secinfo across the the server 
> cluster, I expect servers will take that route. But there will be 
> customer pressure for relax that restriction.

and we will have to resist, and stay within the minor versioning rules
which don't allow a lessening of NFSv4.0 features, including security.

-->Andy

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

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

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

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Wed, 12 Jul 2006 09:40:17 -0400

> is good even though people can do silly things with it. 

if you don't want the cost of integrity, the don't mount with it turned on!
sheese....

> > > but I may care if data is encrypted.

you've got to be kidding. if you're turning on krb5p for data, which is SLOW, 
why would you care if metadata has integrity instead of privacy, you're 
already slow!
this has nothing to do with the case you presented (more security on the data 
channel), and everything to do with a lessening of the security on the data 
channel compared to the metadata channel.

> Strictly speaking, it is not the same notion.

correct. and when it comes to security, strictly speaking is basically the 
only way to speak.

> It can't be because v4.0
> collision you are talking about. 

this proposal lets you mount with privacy, and have I/O with no security. so 
you can claim to have security, yet have none.

> NFSV4.0 allows you to have filesystems

there is no reason not to put the MDS on the same network as the DS.

> Since the storage protocol is v4, we meet those requirements. 

yes, but what is being proposed is not v4. it is not the case in v4 that 
metadata uses RPCSEC_GSS and data uses AUTH_SYS.

>  Those

we disagree.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 12 Jul 2006 09:44:08 -0700 (PDT)

> you've got to be kidding. if you're turning on krb5p for data, which

Not necessarily. It is energy intensive, contributes to
global warming, etc.,
but with the right hardware it can be fast. I might only
have that hardware on a few nodes.

> why would you care if metadata has integrity instead of privacy,

I might not want MDS traffic encrypted for diagnosability.
Most things that can go wrong in NFS are not READ and WRITE.

> metadata uses RPCSEC_GSS and data uses AUTH_SYS.

BTW, I export with sec=sys:krb5, then
it is perfectly legal for an NFSv4.0 client to choose
to do one operation with AUTH_SYS and and another with RPCSEC_GSS.