[9068] in athena10
Re: [SSSD] Securing remote domains
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Wed May 23 03:53:03 2012
Date: Wed, 23 May 2012 03:52:58 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Development of the System Security Services Daemon <sssd-devel@lists.fedorahosted.org>
cc: debathena@MIT.EDU, scripts-team@MIT.EDU
In-Reply-To: <20120523063655.GA15654@hendrix.redhat.com>
Message-ID: <alpine.DEB.2.00.1205230336480.910@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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@mit.edu
