On (23/09/19 18:04), Simo Sorce wrote: >On Mon, 2019-09-23 at 22:53 +0200, Lukas Slebodnik wrote: >> On (23/09/19 15:55), Simo Sorce wrote: >> > On Mon, 2019-09-23 at 14:39 -0500, Spike White wrote: >> > > All, >> > > >> > > Our cybersecurity team doesn’t allow Linux sysadmins to directly log in >> > > as >> > > root. (violates accountability, auditability and traceability). We log >> > > in >> > > with an ADM account, which is then eligible to become root via ‘sudo su >> > > –‘. >> > > >> > > That is, all members of a particular group are allowed to sudo to root. >> > > >> > > This is preferred because with modern sudo versions all sudo sessions are >> > > session-logged. >> > > >> > > Anyway, if I log in with my ADM account and someone shuts down sssd, it >> > > no >> > > longer knows what groups I’m in. That is, the session is still there – >> > > but >> > > it cannot look up the group names. >> > > >> > > [admspike_white@zzzdmsdev06 ~]$ id >> > > >> > > uid=2025431 gid=1002 groups=1002,2284295 >> > > >> > > >> > > >> > > Because the sudo privs are based on group name, it doesn’t allow Linux >> > > sysadmins to become root and thus start sssd. >> > > >> > > >> > > >> > > Is there a way to cache those group names and memberships? Say with >> > > nscd? >> > > So that if sssd is (temporarily) shut down, we can become root and start >> > > up? >> > >> > sssd already caches user and group tables for fast lookup, but those >> > caches are not very big, so if you have very many groups you may need >> > to increase the size. >> > >> > Also these caches have somewhat strict timeouts, I forget if they stop >> > returning anything at all if the timeout is expired. >> > >> > >> >> The behaviour of fast mmap cache is to fall back to daemon in case of >> expired entry. Which is by default just 5 minutes. >> And if sssd is not running then it will not return anything. >> >> > > Obviously, we can go look up the root password for the particular server >> > > – >> > > but that’s a painful portal. It’d be better if we could cache group >> > > names >> > > and memberships, if sssd is temporarily down or offline. >> > >> > Perhaps an RFE to return whatever was in cachi, even if expired, if >> > sssd daemons are unresponsive may be opened, should that be the >> > behavior when caches timed out. >> > >> > >> >> I do not see a reason why sssd should be temporarily down. >> If there is a crash then it should be restarted by systemd. >> If sssd is running but in offline mode then it should return even >> expired entries from the cache. >> >> I would say the biggest problem in the description is >> "someone shuts down sssd". And just somebody with root privileges can do >> that. >> But if sb has root(sudo) access then it can break anything there (even sshd) >> And thus nobody can connect there. What would you do in such situation? > >Not sure what would you do with a rouge admin, but there can definitely >be cases where sssd will refuse to start, for example if an admin fat- >fingers the config file, in that case allowing the fast cache to be >used would save the day. >
`sssctl config-check should help Admin should be careful when touching critical critical services sssd/sshd and be prepared for recovery. It is not a problem of daemons but admins. >So I think that regardless of how sssd can end up in a state where it >is not running it may be useful to allow to return whatever information >we have so that the system is more recoverable, after all the >information there may be stale, but it is not incorrect. > >That said if sudo rules are served via SSSD there may be issues there >too, but that is another story. > sudo rules do not have fast memory cache and thus relying on users and groups from fast memory cache is not enough in case of not-running sssd. IMHO, there still should be a way how to do disaster recovery in case of unresponsive sshd/sssd. I cannot see any issue in sssd itself here. But it would be good to get details from Spike about "someone shuts down sssd" LS _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
