On Wed, 23 May 2012, Jakub Hrozek wrote:
- If the answer to the above is true, how does SSSD resolve conflicts between two domains which have entries that claim the same UID? I understand that the max_id/min_id functionality is intended to address this partially, but does SSSD do any further sanity checks, such as refusing information from remote domains that exist in local domains?I think the multi domain support in SSSD would help your use case. When the SSSD is configured with multiple domains, it queries them in the order they are defined in the config file and the first match is always[*] returned.
So provided that a given UID exists in both local and remote domains, the NSS responder would search the local domain first, if the UID was found there, the remote domain would not be even checked.
Hi Jakub, thanks for your reply.
I think this case is a little more subtle than your answer is referring to; namely, how does SSSD handle a lookup for a username in a remote domain that conflicts with a UID from a local domain? For instance, if an LDAP server replies to a passwd-style query with
cn: geofft uidNumber: 0
it should not result in a passwd entry of "geofft:*:0:..." being returned. While for the specific case of 0 this is handled by min_id, it applies equally well to any local account on the system; if I have a local user account with UID 1000 or 20000 or whatever, I wouldn't want a remote account to be able to use that UID on my local system.
- Additionally, users may come with groups, and it is bad if remote domains can spoof ownership in local groups. Is there anyway to lock this down?The current SSSD version would not resolve local memberships in a remote group, it would only query the same remote domain. See also https://fedorahosted.org/sssd/ticket/1020
Maybe we're not understanding SSSD's model right, but we're curious about (purported) remote memberships in a local group. As above, if a remote user claims in its group list (the return of getgrouplist(3)) to be in a local group like bin or disk or sudo, I wouldn't want that to be respected on my local machine. Again, minimum gids go partway to solving this, but I wouldn't want a remote user who claims to be in gid 1000 or group geofft to be able to access group-readable files I write, etc.
Local memberships in a remote group seem acceptable security-wise; a local system administrator can decide that it's fine for a user account to be in whatever the remote server says a group is. But a remote server should not be able to inject users into local groups.
- It is frequently useful for applications running on the system to be able to identify nonlocal users as opposed to local users; we had a nsswitch module which identified nonlocal users and added them to their own group. Does this functionality exist in SSSD? (It's also convenient to have another group which contains local users.)I can't think of a nice way of doing this short of ID value checks or querying the local database directly.
Is it not possible for the domain lookup to insert an identifier for that domain in the returned group list on getgrouplist(3)/getgroups(3)? If I create two local groups, say, "local_users" and "remote_users", it seems straightforward to add one of those two groups to group lists before returning them to the NSS client.
Thanks,