lkml.org 
[lkml]   [2000]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.048 / U:0.936 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site