> [...]
In the original scenario, the concern was was with shared media having
uid/gid numbers that don't match what's on the system. In that
scenario, this was viewed as a security concern. This is not a
security concern because once someone has physical access to your
unencrypted data, it's no longer your data. That's just an unfortunate
truth. You can give me a HD w/ Windows on it, tell me you set up the
file system permissions to be really super duper secure, but... I'm
just going to walk around the file system as if you gave me higher
than administrator access. Whatever isn't encrypted is now something I
have access to.
For the above scenario, the let's say the data is encrypted. If you're
giving the other party the key so they can open it... it's no longer
your data.
The next scenario I recall from this thread was about the small
business scenario. The typical response to that is obviously
centralized authentication. I know scenarios where that's not possible
or the logistics are absurd. The next best thing is configuration
management utilities. In my personal opinion, if your company is large
enough to have servers, it's large enough that config management is no
longer optional.
If you can go along with that, you can get something like this (salt example):
local_users:
- michael:
uid: 4001
gid: 4001
pwd: <password hash>
keys:
- ssh_key1
- ssh_key2
- timmy:
uid: 4002
gid: 4002
pwd: <pwd_hash>
- freddy:
terminated: True
When tools like sssd take a remote uid/gid and translate that to a
local translated uid/gid, I don't believe that's a security concern so
much as a concern of things breaking if you start getting collisions.
Ya, that's a security concern if sssd generates uid/gid numbers that
collide with numbers that other tools that want to use those
specifically, but I'm convinced this behavior has nothing to do with
security. This behavior only makes collisions unlikely, it does not,
in any way, guarantee that collisions will never happen.
In fact... Story time! One of the first times I started playing with
sssd, I was rolling it out in a mid-size enterprise (~24,000
employees). One a few servers, the uid/gid numbers that sssd came up
with collided with over 80% of the existing local system users. This
was a design issue that needed to be resolved, not something that
needed a band-aid. Because centralized user management already
existed, miscellaneous uid/gid numbers were sent up river to AD and
then every system was migrated to using those numbers. End result...
collisions can't happen because we don't let them.
tl;dr -- Randomizing uid/gid numbers does not improve security, it
just decreases the probability of that security hole being accessible.
Enforcing the same uid/gid everywhere *will* prevent collisions.
Sorry, I got a bit long winded. That's what I get when I write fun
emails on my break. :(
