nfsv4 sec=krb5p and user impersonation

[Cedric Blancher]

On 9 September 2014 23:00, Matt Garman <matthew.garman at gmail.com> wrote:
> I'm trying to understand the nuances of how user authentication works
> with NFSv4 using the sec=krb5p (or presumably any "krb5" sec option).
> In particular, I am concerned about user impersonation.
>
> Here's a situation which hopefully better explains the scenario:
>
> Say there are a bunch of NFSv4 sec=krb5p client Linux servers.  These
> all mount a single share from an NFS server.  That share contains user
> home directories.  All non-root user accounts authenticate via
> Kerberos.  Root authentication is local (/etc/passwd, /etc/shadow).
>
> Case 1: I login as root directly to one of the nfs client servers.  If
> I "su -l" to a user, I still get "permission denied" when I try to see
> his home directory.  (Unless, of course, I then run kinit and type in
> that user's password.)
>
> Case 2: I login first as a user, then "su -l" to root.  At this point,
> I still get "permission denied" when trying to look at any user's home
> directory.  But I can then "su -l <user>", where <user> is *anyone*,
> and I can see their home directory (without knowing their password).
>
> In short, the only difference between Case 1 and Case 2 is that Case 2
> starts off as being logged in as a user, then does su to root; whereas
> Case 1 starts off as root directly.
>
> The only thing I can figure is that in Case 2 a Kerberos ticket is
> created, since I'm logging in as the user.  Since in Case 1, I login
> as root, the authentication is local to that machine, and no Kerberos
> ticket is created.  But in Case 2, it appears that the original user
> ticket somehow becomes "universal", in that, after su'ing to root, I
> can then su to anyone and see his files.
>
> All Kerberos implementations are MIT, native CentOS (RHEL) packages.
> In my case, client systems are CentOS 5.7, using krb5 1.6.1-62.
> Server is CentOS 6.4, using krb5 1.10.3-10.

I think part of the problem is that you are using Linux (SLES, RHEL or
Centos doesn't matter), and the Linux NFS client implementation does
not support negotiation for the authentication in violation of RFC
3530.

So if you want to use Kerberos5 with NFS on SLES or RHEL/Centos you a)
must have proper tickets in your cache and use kswitch before calling
mount and b) you must always specify auth=krb5p or krb5i if you want
Kerberos authentication.

Other NFS implementations just negotiate the authentication required
and try from strongest to weakest authentication method as provided by
the server, and even all realms in a DIR: cache, as RFC 3530 requires

Ced
-- 
Cedric Blancher <cedric.blancher at gmail.com>
Institute Pasteur