> On May 22, 2018, at 1:38 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Tue, May 22, 2018 at 4:22 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> >>> On May 22, 2018, at 1:17 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>> >>> On Tue, May 22, 2018 at 4:08 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>>> >>>> >>>>> On May 22, 2018, at 1:03 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>>>> >>>>> I'm looking for comments on the approach to deal with the following >>>>> denial-of-service issue. >>>>> >>>>> Currently, during the nfs4.0 mount, the code takes the content >>>>> supplied by the user in the mount command for "clientaddr" and that >>>>> becomes part of the content of the SETCLIENTID client id. There are no >>>>> verifications that the supplied address belongs to the client >>>>> initiating the mount. >>>>> >>>>> A denial of services comes from where there are 2 clients with IP A >>>>> and IP B (bad one). Client IP A mounts and has "IP A" in the >>>>> SETCLIENTID. Client IP B does a mount and specified "clientaddr=IP A". >>>>> This causes the server to invalidate the lease for the legitimate >>>>> client IP A. >>>> >>>> Generally if this is a concern, Kerberos can be used during >>>> the SETCLIENTID to mutually authenticate the client and >>>> server. Shouldn't that prevent client B from tampering with >>>> client A's lease? >>> >>> It turns out to be a concern by folks (customers) that are using the >>> code. Kerberos does not help here. Client IP B can have a valid >>> Kerberos identity and still supply "clientaddr=" not belonging to it >>> for the SETCLIENTID and interfere with the other's lease. >> >> SETCLIENTID is associated with a client ID string and a Kerberos >> principal. The server is supposed to deny a client with the same >> string (and perhaps the same callback information) but a different >> Kerberos identity from purging an existing lease belonging to a >> different principal. NFS4ERR_CLID_INUSE. >> >> Are you saying the two clients have exactly the same host >> principal? That seems... wrong. >> > > Are you sure client ID is associated with a Kerberos principal? > > Looking ta the code that constructs the clientid content. I don't see > that cl_nodename takes in principal identity. > scnprintf(str, len, "Linux NFSv%u.%u %s", > clp->rpc_ops->version, clp->cl_minorversion, > clp->cl_rpcclient->cl_nodename); That's correct. Normally the Linux client picks up the host principal in the client's keytab and uses that as the credential for lease management operations like SETCLIENTID, without any regard to whether sec=sys or sec=krb5-yada is used on the mount command. The client ID string is not supposed to change between those cases. The server associates the client ID string with the Kerberos principal the client used to perform the SETCLIENTID. If a different Kerberos principal is used with a SETCLIENTID that bears the same client ID string as a client whose lease is still active, the server is supposed to reject that SETCLIENTID with NFS4ERR_CLID_INUSE. > I have also tried to do a mount with and without Kerberos and the > clientid string is that same has NFSv4.0 client ip/server ip. A quick way to disable the use of Kerberos for lease management is to sudo mv /etc/krb5.keytab /etc/krb5.keytab.bak and then restart rpc.gssd. If the clients are using AUTH_UNIX credentials for SETCLIENTID, client A and client B would have to have the same cl_nodename to be able to futz with each others leases. Is that the case? There used to be a way to get the client to include a uniquifier in the client ID string. Has that logic been removed? -- Chuck Lever -- 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
