question about nfs4 with krb5 behavior

question about nfs4 with krb5 behavior

[Roman Shtylman]

I have setup nfs4 with krb5 server and successfully mounted a client. Two 
people can log into the client box and both access their respective shares and 
not each other's. However, when one user (who lets say has root privs) uses 
root to become the second user (using su) then that user can now access the 
info of the user he became.

I was under the impression that this should not be possible as the tickets for 
access should still be tied to the first user they logged in as. Is this true? 
Or do I have an error in my setup?

Process:
Login as user A
(User B logs into the machine from another terminal)
sudo su B (to become user B on the machine)
<can now edit files which belong to B>

If User B does not login before user A becomes user B, user A is not able to 
edit user B's files even after he becomes user B.

Kernel version: 2.6.32-24

any clarification on behavior would be appreciated.

cheers,
~Roman

Re: question about nfs4 with krb5 behavior

[Jeff Layton]

On Mon, 10 Jan 2011 14:55:30 -0500
Roman Shtylman <shtylman@athenacr.com> wrote:

> I have setup nfs4 with krb5 server and successfully mounted a client. Two 
> people can log into the client box and both access their respective shares and 
> not each other's. However, when one user (who lets say has root privs) uses 
> root to become the second user (using su) then that user can now access the 
> info of the user he became.
> 
> I was under the impression that this should not be possible as the tickets for 
> access should still be tied to the first user they logged in as. Is this true? 
> Or do I have an error in my setup?
> 
> Process:
> Login as user A
> (User B logs into the machine from another terminal)
> sudo su B (to become user B on the machine)
> <can now edit files which belong to B>
> 

That's correct, or is at least in accordance with the design. The
credcache is (usually) a file in /tmp. The kernel has to upcall to
userspace for that information. To do that, it passes along the uid of
the owner of the credcache. I think this is governed by the fsuid.

When you "su" to another user, all of the uid's associated with the
process are changed (real, effective, fs and saved). So, the uid passed to
the upcall in this case is B's and not A's.

This could potentially be "fixable" by moving the krb5 credcache into
the per-session keyring and then teach nfs to do keys API upcalls to get
the right blob. Not a trivial project, but it's doable. This is
something that would be nice for CIFS and maybe AFS too.

> If User B does not login before user A becomes user B, user A is not able to 
> edit user B's files even after he becomes user B.
> 

I suspect that that's just a negative cache entry that will eventually
time out.

-- 
Jeff Layton <jlayton@redhat.com>

Re: question about nfs4 with krb5 behavior

[Roman Shtylman]

On Monday, January 10, 2011 03:35:04 pm Jeff Layton wrote:
> On Mon, 10 Jan 2011 14:55:30 -0500
> 
> Roman Shtylman <shtylman@athenacr.com> wrote:
> > I have setup nfs4 with krb5 server and successfully mounted a client. Two
> > people can log into the client box and both access their respective
> > shares and not each other's. However, when one user (who lets say has
> > root privs) uses root to become the second user (using su) then that
> > user can now access the info of the user he became.
> > 
> > I was under the impression that this should not be possible as the
> > tickets for access should still be tied to the first user they logged in
> > as. Is this true? Or do I have an error in my setup?
> > 
> > Process:
> > Login as user A
> > (User B logs into the machine from another terminal)
> > sudo su B (to become user B on the machine)
> > <can now edit files which belong to B>
> 
> That's correct, or is at least in accordance with the design. The
> credcache is (usually) a file in /tmp. The kernel has to upcall to
> userspace for that information. To do that, it passes along the uid of
> the owner of the credcache. I think this is governed by the fsuid.
> 
> When you "su" to another user, all of the uid's associated with the
> process are changed (real, effective, fs and saved). So, the uid passed to
> the upcall in this case is B's and not A's.
> 
> This could potentially be "fixable" by moving the krb5 credcache into
> the per-session keyring and then teach nfs to do keys API upcalls to get
> the right blob. Not a trivial project, but it's doable. This is
> something that would be nice for CIFS and maybe AFS too.

AFS does not have this behavior. 

What is a best practice for handling this situation? Prevent "untrusted" 
machines from connecting to the nfs server? Basically any machine where a 
normal user can become root would be a potential problem?

Thanks for the quick response.

cheers,
~Roman

> 
> > If User B does not login before user A becomes user B, user A is not able
> > to edit user B's files even after he becomes user B.
> 
> I suspect that that's just a negative cache entry that will eventually
> time out.

Re: question about nfs4 with krb5 behavior

[Kevin Coffman]

On Mon, Jan 10, 2011 at 2:55 PM, Roman Shtylman <shtylman@athenacr.com> wrote:
> I have setup nfs4 with krb5 server and successfully mounted a client. Two
> people can log into the client box and both access their respective shares and
> not each other's. However, when one user (who lets say has root privs) uses
> root to become the second user (using su) then that user can now access the
> info of the user he became.
>
> I was under the impression that this should not be possible as the tickets for
> access should still be tied to the first user they logged in as. Is this true?
> Or do I have an error in my setup?
>
> Process:
> Login as user A
> (User B logs into the machine from another terminal)
> sudo su B (to become user B on the machine)
> <can now edit files which belong to B>

User A is now "user B" and has access to the Kerberos credentials
created by user B when they logged in.  Even if user B logged out and
deleted their kerberos credentials before user A did the "sudo su B",
if user B had already accessed NFS, a kernel gss context with the
server would have been created.  That will still be available and
usable when user A becomes user B, until it expires.

> If User B does not login before user A becomes user B, user A is not able to
> edit user B's files even after he becomes user B.

In this case, user B had not previously created Kerberos credentials.

> Kernel version: 2.6.32-24
>
> any clarification on behavior would be appreciated.
>
> cheers,
> ~Roman
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question about nfs4 with krb5 behavior

[Kevin Coffman]

On Mon, Jan 10, 2011 at 3:45 PM, Roman Shtylman <shtylman@athenacr.com> wrote:
>
> On Monday, January 10, 2011 03:35:04 pm Jeff Layton wrote:
>> On Mon, 10 Jan 2011 14:55:30 -0500
>>
>> Roman Shtylman <shtylman@athenacr.com> wrote:
>> > I have setup nfs4 with krb5 server and successfully mounted a client. Two
>> > people can log into the client box and both access their respective
>> > shares and not each other's. However, when one user (who lets say has
>> > root privs) uses root to become the second user (using su) then that
>> > user can now access the info of the user he became.
>> >
>> > I was under the impression that this should not be possible as the
>> > tickets for access should still be tied to the first user they logged in
>> > as. Is this true? Or do I have an error in my setup?
>> >
>> > Process:
>> > Login as user A
>> > (User B logs into the machine from another terminal)
>> > sudo su B (to become user B on the machine)
>> > <can now edit files which belong to B>
>>
>> That's correct, or is at least in accordance with the design. The
>> credcache is (usually) a file in /tmp. The kernel has to upcall to
>> userspace for that information. To do that, it passes along the uid of
>> the owner of the credcache. I think this is governed by the fsuid.
>>
>> When you "su" to another user, all of the uid's associated with the
>> process are changed (real, effective, fs and saved). So, the uid passed to
>> the upcall in this case is B's and not A's.
>>
>> This could potentially be "fixable" by moving the krb5 credcache into
>> the per-session keyring and then teach nfs to do keys API upcalls to get
>> the right blob. Not a trivial project, but it's doable. This is
>> something that would be nice for CIFS and maybe AFS too.
>
> AFS does not have this behavior.
>
> What is a best practice for handling this situation? Prevent "untrusted"
> machines from connecting to the nfs server? Basically any machine where a
> normal user can become root would be a potential problem?
>
> Thanks for the quick response.
>
> cheers,
> ~Roman

AFS uses a Process Authentication Group (PAG) to segregate use of
credentials in the kernel.  As far as I know, this doesn't prevent a
user with root access on the "untrusted" machine from impersonating
another user on the machine.  (They can simply copy any existing
kerberos credentials for use in their PAG.)  I think it does prevent
"accidental" use of the other user's credentials in this kind of
situation.

Re: question about nfs4 with krb5 behavior

[Trond Myklebust]

On Mon, 2011-01-10 at 15:45 -0500, Roman Shtylman wrote: 
> On Monday, January 10, 2011 03:35:04 pm Jeff Layton wrote:
> > On Mon, 10 Jan 2011 14:55:30 -0500
> > 
> > Roman Shtylman <shtylman@athenacr.com> wrote:
> > > I have setup nfs4 with krb5 server and successfully mounted a client. Two
> > > people can log into the client box and both access their respective
> > > shares and not each other's. However, when one user (who lets say has
> > > root privs) uses root to become the second user (using su) then that
> > > user can now access the info of the user he became.
> > > 
> > > I was under the impression that this should not be possible as the
> > > tickets for access should still be tied to the first user they logged in
> > > as. Is this true? Or do I have an error in my setup?
> > > 
> > > Process:
> > > Login as user A
> > > (User B logs into the machine from another terminal)
> > > sudo su B (to become user B on the machine)
> > > <can now edit files which belong to B>
> > 
> > That's correct, or is at least in accordance with the design. The
> > credcache is (usually) a file in /tmp. The kernel has to upcall to
> > userspace for that information. To do that, it passes along the uid of
> > the owner of the credcache. I think this is governed by the fsuid.
> > 
> > When you "su" to another user, all of the uid's associated with the
> > process are changed (real, effective, fs and saved). So, the uid passed to
> > the upcall in this case is B's and not A's.
> > 
> > This could potentially be "fixable" by moving the krb5 credcache into
> > the per-session keyring and then teach nfs to do keys API upcalls to get
> > the right blob. Not a trivial project, but it's doable. This is
> > something that would be nice for CIFS and maybe AFS too.
> 
> AFS does not have this behavior. 
> 
> What is a best practice for handling this situation? Prevent "untrusted" 
> machines from connecting to the nfs server? Basically any machine where a 
> normal user can become root would be a potential problem?

We really should add this question to the NFS FAQ (if it isn't already
there).

Just do not trust _any_ machine where you can't trust the root account.

It really doesn't matter what you do in the matter of fancy solutions;
if the root account is untrusted, it is game over as far as security is
concerned. The root user can read /dev/mem, can load untrusted modules,
can reboot into an untrusted kernel, replace the kerberos libraries with
trojans, hijack ttys, ...

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

RE: question about nfs4 with krb5 behavior

[Daniel.Muntz]

Best practice for AFS is to only allow one user at a time, especially if users can become root.  You'd also want to delete any "persistent" cache when users change and have a mechanism of validating/replacing kernel and apps.

  -Dan

-----Original Message-----
From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Roman Shtylman
Sent: Monday, January 10, 2011 12:45 PM
To: Jeff Layton
Cc: linux-nfs@vger.kernel.org
Subject: Re: question about nfs4 with krb5 behavior


On Monday, January 10, 2011 03:35:04 pm Jeff Layton wrote:
> On Mon, 10 Jan 2011 14:55:30 -0500
> 
> Roman Shtylman <shtylman@athenacr.com> wrote:
> > I have setup nfs4 with krb5 server and successfully mounted a client. Two
> > people can log into the client box and both access their respective
> > shares and not each other's. However, when one user (who lets say has
> > root privs) uses root to become the second user (using su) then that
> > user can now access the info of the user he became.
> > 
> > I was under the impression that this should not be possible as the
> > tickets for access should still be tied to the first user they logged in
> > as. Is this true? Or do I have an error in my setup?
> > 
> > Process:
> > Login as user A
> > (User B logs into the machine from another terminal)
> > sudo su B (to become user B on the machine)
> > <can now edit files which belong to B>
> 
> That's correct, or is at least in accordance with the design. The
> credcache is (usually) a file in /tmp. The kernel has to upcall to
> userspace for that information. To do that, it passes along the uid of
> the owner of the credcache. I think this is governed by the fsuid.
> 
> When you "su" to another user, all of the uid's associated with the
> process are changed (real, effective, fs and saved). So, the uid passed to
> the upcall in this case is B's and not A's.
> 
> This could potentially be "fixable" by moving the krb5 credcache into
> the per-session keyring and then teach nfs to do keys API upcalls to get
> the right blob. Not a trivial project, but it's doable. This is
> something that would be nice for CIFS and maybe AFS too.

AFS does not have this behavior. 

What is a best practice for handling this situation? Prevent "untrusted" 
machines from connecting to the nfs server? Basically any machine where a 
normal user can become root would be a potential problem?

Thanks for the quick response.

cheers,
~Roman

> 
> > If User B does not login before user A becomes user B, user A is not able
> > to edit user B's files even after he becomes user B.
> 
> I suspect that that's just a negative cache entry that will eventually
> time out.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html