NFS security

[Ray Loyzaga]

>>From: shankar at hpclscu.HP.COM (Shankar Unni)
>
>> removing files from a r-w directory etc).  The speaker was not
>> overly clear about what the hole was, but he smugly assured me that
>> he could do much as he pleased if I were to allow him NFS access from
>> a machine on which he was root.  Is this a problem with NFS, or
>> with the HP or Apollo versions of NFS?
>
>Normally, root on a machine (say, A) which NFS-mounts file systems from
>another machine (say, B) gets the uid -2 on machine B. He (/she/it) thus
>cannot do much damage on B.

I don't understand the meaning of much damage?? If you use NFS and
only have unix style uid mapping, then a user who is root on his
workstation (a very simple act on some really high-volume workstations)
can su to any other uid and tamper with files owned by that user
on any filesystem that he has been allowed to remote mount.
This means that any non-root owned file can be removed, looked at
or modified. I tend to call that a lot of damage!

>
>However, there is a configurable option to let root on A get a uid of 0
>(or anything other than -2) on B. Then of course you're playing with
>fire...

Well what happens if on SunOS 3.5 you do as root on your
workstation on a remote fs
mknod ~mydir/mem c 3 0

yup, you end up with a nobody owned copy of /dev/mem.
So whats to stop you from using the adb and fixing the remote
unix so that nobody = 0?? or that setreuid always works??
It has been done here by one of our pgrads.
This form of protection just means that it takes 30 seconds longer
to crack an NFS system, I doubt that it is worth the effort.
We just admit that it is insecure, curse a little, and make sure
that only "good guys" have physical access to the workstations.