On Tue, May 22, 2012 at 10:06:56PM -0400, Edward Z. Yang wrote:
Hello all,
We're interested in using SSSD to replace our current use of
NSS/PAM/NSCD/NSLCD. However, we were curious whether or not
SSSD had implemented some critical security checks to protect
against malicious remote domains.
- What are the semantics of the local domain: that is,
do I have a guarantee that entries in local will never
be affected by the network?
Yes, the local domain is completely isolated and no entry can reference
entries in another domain, local or remote.
The more involved answer is, when the NSS responder process is returning
entries from the local domain, it directly shortcuts to the ldb database
files where local entries are stored and never contacts the Data Provider
process that downloads data from remote domains.
- 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.
[*] Unless the domain name is specifically part of the query. In other
words, if the query would have been 1001@remote, SSSD would only
perform the lookup in the domain called "remote".
- 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
- 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.
- A nice to have feature (though not strictly necessary), is the
ability to pretend that nonlocal users are in some local group.
This may be necessary if remote domains cannot dictate ownership
in local groups.
In general, we would like to avoid trusting the source of the remote
authentication data: local accounts are first class, whereas remote accounts
are merely "nice to have". The remote LDAP server may not be held to as high
security standards as the machine itself, and if we can achieve isolation at
very little cost, we should do so.
The MIT Debathena and Scripts projects would be very interested
in seeing this functionality exist, and if it doesn't, we'd be
interested in contributing this functionality. We consider this
a blocker for moving to SSSD.
Thanks,
Edward