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 _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
