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?
- 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?
- 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?
- 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
- 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.