On Wed, 2013-06-05 at 08:19 -0700, Chuck Lever wrote: > On Jun 5, 2013, at 10:48 AM, "E.G. Keizer" <E.G.Keizer@xxxxx> wrote: > > > > > > > On 05/06/2013 16:25, Myklebust, Trond wrote: > >> On Wed, 2013-06-05 at 16:05 +0200, E.G. Keizer wrote: > >>> First I would like to wholeheartedly support Neil Brown's comment. We at the > >>> Vrije Universiteit in Amsterdam (NL) also have the situation where the Kerberos > >>> administrator does not hand out machine credentials. A lot of Linux users from > >>> the Faculty of Sciences depend on the functionality that lets them access > >>> the NFS file servers with only their user credentials. > >> > >> They should still be able to do that, but in that case, the state > >> management will have to default to AUTH_SYS to set up the lease, which > >> means that someone else can spoof requests to cancel the lease or change > >> the callback channel parameters. > > We would probably accept that. But can you enlighten me as to why AUTH_SYS is better > > then krb5 (no i, no p)? > > It isn't "better." But if no GSS credential is available on the client, then AUTH_SYS is about the only choice for a client to use. > > > > >> > >>> Secondly I would like to make a remark on basing client id's on the system's kerberos principal's name. > >>> That same faculty, in the times it had its own IT department, used an identical keytab for > >>> all Linux workstations, using the principal names "[nfs|root|host]/workstation@xxxxxxxxx". > >>> I understand this would lead to severe problems when the client id (co_ownerid) is based > >>> solely in the systems root principal name. > >> > >> How so? The only problem should be that any one of those machines can go > >> and cancel or change the lease of any other. That's a compromise that > >> you decided upon when you decided to use one keytab for all of them. > > Mmm, not at the time we made the decision. But I just mentioned that as an example > > of the problems one can meet when deciding on the implementation of client id. > > The same problem, but on a smaller scale, occurs when the client id is based > > on the system principal and two or more systems use the same user principal as system > > principal. > >> > >>> It seems to me that the issues about the client id look like a bag of worms. I've seen that the > >>> newest standard `requires' integrity protection for client id exchanges. I doubt > >>> that that will help when the source code of the NFS client is known and > >>> the client id is guessable. > >> > >> What is the attack and how would it compromise security on the clients > >> that you care about? > > I am personally not that worried about this issue on our environment. But others seem to > > be in their environment. Otherwise the integrity requirement would not have ended up in > > the NFSv4 RFC. As fas as I understand the danger with a man-in-the-middle attack is that the attacker > > can see my client id and thus cancel my lease. When the man-in-the-middle can guess my > > client id he can still invalidate my lease even when i'am using krb5i. > > No, SETCLIENTID would have to be authenticated with a Kerberos principal. That's what protects the lease. > > >> > >>> The wisest thing might be to offer different options > >>> and let the administrators pick the one they like best? > >> > >> We have two options available to you: auth_sys or RPCSEC_GSS w/krb5i. > > I meant different options for choosing the client id. > > Have you seen the nfs4_unique_id boot parameter? (cf. Documentation/filesystems/nfs.txt) Pick a different UUID for each of your clients, and specify that UUID via the kernel command line. Yes, sorry. I misremembered the code... If you specify 'migration' then the uuid is used. Otherwise we use the ip address. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
