"Duplicate" UID security risk ?

[Stuart Abramson]

Our UNIX Server LANScape has "duplicate" UIDs on servers in the LAN; i.e. -
o User "smithjc" has UID 1024 on one machine and UID 1302 on another.
o Converesely, UID 1024 is one user on one server, and a different user on a different machine.

Our Security Team is asking:
o Is this a Security Problem?
o How big of a problem?

It seems to me that some factors to consider in a multi-server LANScape are:
o NFS
o remsh / rlogin (ssh)
o ftp

It seems to me that remsh and ftp are fine:
o They don't work by UID, they work by "user name text string". If my User Name is "smithjc" on all servers, with different IDs, he looks up the text string, not the UID.

NFS may pose a risk. The UID in the exported file system that is mounted on Server A may match up with mine by coincidence - and then I have access to those files (UID and GID).

Is that right?

[Pete Randall]

Stuart,

I believe you are correct. We address this problem by keeping the password files in sync on all the servers. In our case I simply rcopy the file from a central server after changes, but then we get into a whole other security discussion about the "r" services.


Pete

[A. Clay Stephenson · Accepted solution]

Your analysis is correct but it goes further. For example, if you bring in a tar or cpio archive from one box to the other then ownerships will change. Of course, that could happen with any archive but you should be aware of it. I will say that this is a situation I never allow to arise by using NIS, NIS+, and/or LDAP to unify the UID's, GID's, services, ... across all the boxes on the network. It's even more essential when you are running the automounter so that a user's home directory might be on a completely different box.

[Christopher Caldwell]

In our environment, mixing up UIDs with usernames is less of a security hole and more of a bad practice.

If you've got lots of mixed users with files that require access restrictions then YMMV.

As a best practice, syncing the UIDs/usernames means you don't have to decide whether or not there are security implications (and things line up nicely among your hosts). But just because you've got mixed UIDs and usernames, doesn't neccessarily imply security hole.

[Stuart Abramson]

Thanks all. We're looking into just how much of UID "inconsistency" we have. And mapping NFS mounts, which seems to be the only "hole" so far.

Depending on how much "inconsistency" we have, we might look into "synching up" the UIDs. If not too many, we'll just leave and plan for "synch" by attrition over time.

[doug hosking]

I pretty much agree with the comments so far. Clay's comments about tar, cpio, etc. are worth considering a bit more. If you have common UIDs, then it's a lot easier to restore backups from a potentially broken machine on another machine, and have the right things happen. Likewise, if you physically exchange disks between machines the right things will tend to happen if the UIDs and GIDs are synchronized. Depending on which specific backup utilities you use, this may be more or less of a problem. As already indicated, NFS is the big risk if UIDs and GIDs are not synchronized.

Please keep in mind that the first 100 UIDs and GIDs are reserved by HP for system accounts like root, adm, bin, lp, uucp, etc. To avoid potentially large security holes, please be sure you do not allocate UIDs or GIDs in this range for user accounts. If you create accounts with tools like useradd, the right things tend to happen by default re the reserved range.

[Stuart Abramson]

...