[Bug 966734] Re: nfs4 allows writes by incorrect users

[Toby Corkindale]

In case it isn't clear about how this affects security, consider this case:
In a small environment without LDAP, NIS, etc, it's not unusual for the users to be created manually, and sometimes out of order, so their uids don't match between servers.

NFS Server: Has users alice (uid 1001), bob (uid 1002), craig (uid 1003)
NFS Client 1: Has users alice (uid 1001), bob (uid 1002), craig (uid 1003)
NFS Client 2: Has users alice (uid 1001), bob (uid 1003), craig (uid 1002)

Let's say each user's home directory is mounted from the server to the clients with nfs. A pretty normal situation.
On client machine #1, it would be working as expected.
On client machine #2, a sysadmin looking at the mounts would see that they were owned by the expected users.
ie. /home/alice is owned by alice, /home/bob is owned by bob, and /home/craig is owned by craig.

drwxr-x--- 2 alice users 4096 Mar 28 14:43 alice
drwxr-x--- 2 bob users 4096 Mar 30 10:43 bob
drwxr-x--- 2 craig users 4096 Mar 29 12:21 craig

However because the NFS id mapping is bugged, on client #2 with the non-matched UIDs, it will allow bob to execute something like this:
cat /home/craig/top_secret_document
echo "pwned" > /home/craig/.bashrc

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/966734

Title:
  nfs4 allows writes by incorrect users

Status in “nfs-utils” package in Ubuntu:
  New

Bug description:
  I've observed this bug on Ubuntu Precise (beta) and Oneiric, and also on Debian Squeeze and Debian Testing.
  (Kernel versions 2.6.32, 3.0.0 and 3.2.0)
  I've found numerous forum posts around the internet from confused users, but no solutions.

  The bug in question involves using nfs v4 with the idmapd, with users with the same username but differing uids across the client and server. The idmapping appears to have worked, until you try to write to the directories, at which point it skips the idmapping.
  This is a security issue as it will allow users to access files owned by other users unexpectedly.

  When listing files or directories on the client, the directories show
  up as owned by your local user, however attempting to write will
  result in a Permission Denied error. If you go back to the server and
  chown the directory to be owned by the uid used on the client, then
  the client will see the directory as owned by the incorrect user --
  but WILL be able to write to it!

  The log files for idmapd on both client and server appear to indicate
  that things are working correctly. eg:

  Server's syslog: rpc.idmapd[777]: Server : (user) id "2012" -> name "postie at localdomain"
  Client's syslog: rpc.idmapd[870]: Client 0: (user) name "postie at localdomain" -> id "2014"

  Running commands on the client:
  $ getent passwd postie
  postie:x:2014:2014::/home/postie:/bin/bash
  $ cd /srv/test
  $ ls -l
  drwxr-xr-x 2 postie root 4096 Mar 28 11:48 postie
  $ ls -ln
  drwxr-xr-x 2 2014 0 4096 Mar 28 11:48 postie
  $ touch postie/foo
  touch: cannot touch `postie/foo': Permission denied

  
  To prove that the mount *is* mounted read-write, I'll change the ownership of the directory on the server to uid 2014, rather than the postie user there (who has uid 2012).

  Now I run some commands on the client again:
  $ ls -l
  drwxr-xr-x 2 nobody root 4096 Mar 28 11:48 postie
  $ ls -ln
  drwxr-xr-x 2 65534 0 4096 Mar 28 11:48 postie
  $ touch postie/foo
  # It succeeds!

  
  Any thoughts on this, or if there's a better place to report this bug?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/966734/+subscriptions