Messages in this thread | | | Date | Thu, 6 Jan 2000 20:38:39 -0500 (EST) | From | Chris Wing <> | Subject | Re: [PATCH] 32-bit UID support for 2.3.36 |
| |
Mike:
> I've glanced over the 32 bit UID stuff. I would desparately love > to see this in the kernel for a multitude of reasons, one of which is > security related. (I also have at least one situation where we are > legitimately looking at many times more users than 16 bits would allow.)
The security arguments with the 32-bit UID stuff are kind of iffy. My patches try to fix things up in as secure a manner as possible, but if you have >65535 users on your system, you really need to be running all glibc-based daemons. (and hopefully your programs running as root used uid_t and not unsigned short internally)
> In the past there has been problems with the disparity between > 16 bit UID systems and 32 bit UID systems over NFS. The classical problem > occurs when some clown on a 32 bit system adds a user id of 65536 (or > some other multiple of 2**16) and the 16 bit system fails to recognize > the UID as being zero in the low order bits resulting in root access to > a system that would otherwise not have root access.
NFS = No File Security.
Unfortunately, using NFS opens you up to far more attacks than just this one. If you use NFS for any purpose other than unprivileged, read-only exports, you are in trouble if there is any sort of public access to your network. (public access meaning that an untrusted party can run a sniffer and send packets) That's just the way it is going to be until we are all using Kerberos NFS or NFS over SSL.
> AFAIK, Linux systems are NOT vulnerable to this. The user land NFS > daemon doesn't seem to be, but I don't know about the knfsd. A glance at > it didn't seem to reveal whether it would be or not. It's possible the > check on the !cr_uid check in auth.c will catch this, if it is post > conversion to 16 bits. If so, it will be clean once it's converted to > 32 bit uid's as well. I just want to make sure people are aware of this > gotcha and we don't have any hidden sillyness where someone checks the > low order 16 bits for zero and then breaks on 32bit <-> 32bit mapping once > we dump the 16 bit limitation once and for all.
I've tested the kernel NFS server + Linux 2.2 with my 32-bit UID patches and everything seemed to work fine.
A colleague of mine is using it in a production environment with 32-bit UIDs to share a RAID array between a bunch of hosts, and so far I haven't heard of any problems.
> 16 bit uids in NFS have been a sporatic problem from a security > standpoint and some NFS implimentation have code specifically to spot this. > If any of the Linux NFS code has this, it needs to be backed out when we > go to 32bits or legitimate UIDs which are multiples of 2**16 may get > incorrectly mapped.
The NFS code has been a state of flux for a while. Hopefully, these issues will be looked at as the knfsd updates, etc. get into 2.3.
> I didn't see anything in the 32 bit UID patches that pretained to > NFS. Maybe, hopefully, nothing is required. That would be a GOOD thing. > I just want to make sure. :-) Because I really REALLY would like to > see 32 bit UID's in 2.4 and working correctly! :-)
As would I.
Thanks, Chris Wing wingc@engin.umich.edu
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |