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,
--
Geoffrey Thomas
geofft(a)mit.edu