Bug#702448: nfs-common: UID's do not get properly mapped

2013-03-07 Thread J. Bruce Fields
I've created users test1 and test2 in /etc/passwd, but with
swapped UID's

There's a common (and understable) mistake here: many people think that
NFSv4 never requires uid's and gid's to agree between hosts.  This is
not true.

NFSv4, when used with traditional auth_sys authentication, requires
names and ID's to agree between client and server.  The behavior you
describe is as expected.

The issue is that while the NFSv4 protocol itself uses names, it's the
RPC protocol (which NFSv4 runs on top of) which carries the information
about who is performing a given RPC.

How exactly it identifies the user depends on the security flavor.  In
the auth_sys case, it uses numeric ID's. 

For example, in this case, when you create a file, the owner of the new
file will the one who performed the create.  The server determines this
from the uid sent in the rpc header.  However, when you ls -l the
file, the information about who owns the file is returned as a name in
the body of the NFSv4 reply.

The clearest way to see what's going on is to rerun your test cases
while watching the traffic in wireshark, and look at both the rpc
headers and the bodies of the requests.

If you wish to get away from numeric id's on the wire, you need to
switch to using NFSv4 with kerberos instead of auth_sys.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#702448: nfs-common: UID's do not get properly mapped

2013-03-06 Thread jtg
Package: nfs-common
Version: 1:1.2.6-3
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainers,

I've recetly set up an NFSv4 server and I found that ID mapping does 
always work as expected, allowing a user to read files they should not 
have access to (and preventing them to access files they should have
access to). To demonstrate, I have set up a test NFS client and server 
pair, both running wheezy. I've created users test1 and test2 in
/etc/passwd, but with swapped UID's: 

SERVER

test1:x:5000:5000::/home/test1:/bin/bash
test2:x:5001:5001::/home/test2:/bin/bash 


CLIENT

test2:x:5000:5000::/home/test2:/bin/bash
test1:x:5001:5001::/home/test1:/bin/bash 


On the server, I have /srv/nfs exported; the output of exportfs -a is:

/srv/nfsworld


To demonstrate the problem, I've crafted a script, which does the following:
* creates a file on the client as user test1 (a);
* created two files on the server, one as user test1 (b), one as user 
  test2 (c);
* runs ls -l on the files, both on the server and the client, to check 
  the ownerships/permissions reported;
* tries to read the files, both as user test1 and test2, both on the 
  server and the client.

What I've found is that
* the file created on the client by user1 (a) shows up owned by user2 
  both on the server and the client -- BUG
* the files created on the server (b and c) appear as expected both on
  the client and the server -- OK
* on the client, user1
- can open the file created by user1 on the client (a) -- OK
- cannot open the file created by user1 on the server (b) -- BUG
- can open the file created by user2 on the server (c) -- SECURITY
* on the client, user2
- cannot open the file created by user1 on client (a) -- OK
- can open the file created by user1 on the server (b) -- SECURITY
- cannot open the file created by user2 on the server (c) -- BUG
* on the server, user1
-  cannot open the file created by user1 on client (a) -- BUG
-  can open the file created by user1 on the server (b) -- OK
-  cannot open the file created by user2 on the server (c) -- OK
* on the server, user2
-  can open the file created by user1 on client (a) -- SECURITY
-  cannot open the file created by user1 on the server (b) -- OK
-  cannot open the file created by user2 on the server (c) -- OK

The transscript and the debug output of rpc.idmapd on both the server 
and the client is attached.

While my understanding of ID mapping is limited, I found it strange 
that according to the debug log, nfs4_name_to_uid doesn't get called on
the client for user1 when creating the file.

The transcript is the following:
(NB: the script started on the client, and before it started, nfs-common
was stopped on both client and server, there were no nfs mounts on the 
client, and the test directory was empty)


# date
Wed Mar  6 17:15:57 CET 2013

# SRV=192.168.56.102

# /etc/init.d/nfs-common start
Starting NFS common utilities: statd idmapd.
rpc.idmapd: libnfsidmap: using domain: localdomain
rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN' 
rpc.idmapd: libnfsidmap: loaded plugin 
/lib/i386-linux-gnu/libnfsidmap/nsswitch.so for method nsswitch

# ssh $SRV /etc/init.d/nfs-common start
Starting NFS common utilities: statd idmapd.
rpc.idmapd: libnfsidmap: using domain: localdomain
rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN' 
rpc.idmapd: libnfsidmap: loaded plugin 
/lib/i386-linux-gnu/libnfsidmap/nsswitch.so for method nsswitch

# mount $SRV:/ /mnt; mount -t nfs,nfs4
192.168.56.102:/ on /mnt type nfs4 
(rw,relatime,vers=4,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.56.101,minorversion=0,local_lock=none,addr=192.168.56.102)

# sudo -u test1 sh -c touch /mnt/srv/nfs/test/a; chmod 600 /mnt/srv/nfs/test/a
# ssh $SRV sudo -u test1 touch /srv/nfs/test/b; chmod 600 /srv/nfs/test/b
# ssh $SRV sudo -u test2 touch /srv/nfs/test/c; chmod 600 /srv/nfs/test/c

# sleep 3; date
Wed Mar  6 17:16:01 CET 2013

# ls --full-time /mnt/srv/nfs/test
total 0
-rw--- 1 test2 test2 0 2013-03-06 17:15:58.0 +0100 a
-rw--- 1 test1 test1 0 2013-03-06 17:15:58.0 +0100 b
-rw--- 1 test2 test2 0 2013-03-06 17:15:58.0 +0100 c
# ssh $SRV ls --full-time /srv/nfs/test 
total 0
-rw--- 1 test2 test2 0 2013-03-06 17:15:58.0 +0100 a
-rw--- 1 test1 test1 0 2013-03-06 17:15:58.0 +0100 b
-rw--- 1 test2 test2 0 2013-03-06 17:15:58.0 +0100 c

# sudo -u test1 cat /mnt/srv/nfs/test/*
cat: /mnt/srv/nfs/test/b: Permission denied
# sudo -u test2 cat /mnt/srv/nfs/test/*
cat: /mnt/srv/nfs/test/a: Permission denied
cat: /mnt/srv/nfs/test/c: Permission denied
# ssh $SRV sudo -u test1 cat