On Apr 8, 2014, at 12:40, Dr Fields James Bruce <bfields@xxxxxxxxxxxx> wrote:
>
> On Tue, Apr 08, 2014 at 12:22:51PM -0400, Trond Myklebust wrote:
>> How is it not better just to rip out that hostname comparison in the
>> back channel?
>
> Rip it out entirely?
>
> At that point anyone who can get a credential in the right realm can
> send a recall. RFC made this requirement to prevent that.
>
OK. Let’s examine what RFC3530 and RFC3530bis actually says here:
Regardless of what security mechanism under RPCSEC_GSS is being used,
the NFS server MUST identify itself in GSS-API via a
GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE
names are of the form:
service@hostname
For NFS, the "service" element is
nfs
Implementations of security mechanisms will convert nfs@hostname to
various different forms. For Kerberos V5, the following form is
RECOMMENDED:
nfs/hostname
For Kerberos V5, nfs/hostname would be a server principal in the
Kerberos Key Distribution Center database. This is the same
principal the client acquired a GSS-API context for when it issued
the SETCLIENTID operation, therefore, the realm name for the server
principal must be the same for the callback as it was for the
SETCLIENTID.
So as I read the above, technically the client is supposed to read off the principal name that the server uses to authenticate itself to the SETCLIENTID and check that in the callback. Am I wrong?
If so, then the steps are:
1) Modify process_krb5_upcall() and have the call to gss_inquire_context() also request the context acceptor name
2) Modify the rpc.gssd downcall to pass that name to the kernel in some format that allow us to retrieve it in the SETCLIENTID call.
3) Modify the comparison in check_gss_callback_principal()
_________________________________
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
--
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
