[SSSD-users] Re: Offline caching of group names and memberships?
On (26/09/19 08:45), Simo Sorce wrote: >On Wed, 2019-09-25 at 17:29 +0200, Lukas Slebodnik wrote: >> On (25/09/19 09:05), Simo Sorce wrote: >> > On Wed, 2019-09-25 at 11:07 +0200, Lukas Slebodnik wrote: >> > > On (24/09/19 13:46), Simo Sorce wrote: >> > > > On Tue, 2019-09-24 at 17:58 +0200, Lukas Slebodnik wrote: >> > > > > On (24/09/19 09:26), Simo Sorce wrote: >> > > > > > On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: >> > > > > > > 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 >
[SSSD-users] Re: Offline caching of group names and memberships?
On Wed, 2019-09-25 at 17:29 +0200, Lukas Slebodnik wrote: > On (25/09/19 09:05), Simo Sorce wrote: > > On Wed, 2019-09-25 at 11:07 +0200, Lukas Slebodnik wrote: > > > On (24/09/19 13:46), Simo Sorce wrote: > > > > On Tue, 2019-09-24 at 17:58 +0200, Lukas Slebodnik wrote: > > > > > On (24/09/19 09:26), Simo Sorce wrote: > > > > > > On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: > > > > > > > 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 > > > > >
[SSSD-users] Re: Offline caching of group names and memberships?
On Wed, Sep 25, 2019 at 06:25:06PM -0500, Spike White wrote: > Yes, true statement. > > We also do not own AD -- only the Linux builds. The AD admins insist on > camel-case for group names and user names. > > Yes, AD and Windows are case-insensitive. But Linux and Kerberos are not. > > I know these logins by default are translated into lower-case names (which > is what we desire anyway). I forget which sssd setting does this > auto-lower-casing. case_sensitive = true|false|preserving false is the default for AD in the sense that everything is lowercased and names match in case-insensitive manner. true is the default for generic LDAP, names are returned in the original case and must be matched in the original case preserving is a little in between in the sense that the original case is returned but you can match on any case. > > BTW, that would be a cool RFE for pam_sss.so to return cache entries if > sssd service down or wedged. I imagine it'd be a flag on the auth > pam_sss.so line that you're add to enable this. Do you think it is needed over the case_sensitive option? ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Offline caching of group names and memberships?
Yes, true statement. We also do not own AD -- only the Linux builds. The AD admins insist on camel-case for group names and user names. Yes, AD and Windows are case-insensitive. But Linux and Kerberos are not. I know these logins by default are translated into lower-case names (which is what we desire anyway). I forget which sssd setting does this auto-lower-casing. BTW, that would be a cool RFE for pam_sss.so to return cache entries if sssd service down or wedged. I imagine it'd be a flag on the auth pam_sss.so line that you're add to enable this. Spike On Wed, Sep 25, 2019 at 10:29 AM Lukas Slebodnik wrote: > On (25/09/19 09:05), Simo Sorce wrote: > >On Wed, 2019-09-25 at 11:07 +0200, Lukas Slebodnik wrote: > >> On (24/09/19 13:46), Simo Sorce wrote: > >> > On Tue, 2019-09-24 at 17:58 +0200, Lukas Slebodnik wrote: > >> > > On (24/09/19 09:26), Simo Sorce wrote: > >> > > > On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: > >> > > > > 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 > >> > > > > >
[SSSD-users] Re: Offline caching of group names and memberships?
On (25/09/19 09:05), Simo Sorce wrote: >On Wed, 2019-09-25 at 11:07 +0200, Lukas Slebodnik wrote: >> On (24/09/19 13:46), Simo Sorce wrote: >> > On Tue, 2019-09-24 at 17:58 +0200, Lukas Slebodnik wrote: >> > > On (24/09/19 09:26), Simo Sorce wrote: >> > > > On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: >> > > > > 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. >> > > > >> > > > We build tools for admins, not for platonic perfections though... >> >
[SSSD-users] Re: Offline caching of group names and memberships?
On Wed, 2019-09-25 at 09:05 -0400, Simo Sorce wrote: > On Wed, 2019-09-25 at 11:07 +0200, Lukas Slebodnik wrote: > > > > Could you file an upstream issue? > > Ok. https://pagure.io/SSSD/sssd/issue/4087 HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Offline caching of group names and memberships?
On Wed, 2019-09-25 at 11:07 +0200, Lukas Slebodnik wrote: > On (24/09/19 13:46), Simo Sorce wrote: > > On Tue, 2019-09-24 at 17:58 +0200, Lukas Slebodnik wrote: > > > On (24/09/19 09:26), Simo Sorce wrote: > > > > On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: > > > > > 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. > > > > > > > > We build tools for admins, not for platonic perfections though... > > > > > > > > > > I thought there was assumption that sssd will never handle root > > > because it is a prerequisite to run sssd itself. (chicken an
[SSSD-users] Re: Offline caching of group names and memberships?
On (24/09/19 13:46), Simo Sorce wrote: >On Tue, 2019-09-24 at 17:58 +0200, Lukas Slebodnik wrote: >> On (24/09/19 09:26), Simo Sorce wrote: >> > On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: >> > > 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. >> > >> > We build tools for admins, not for platonic perfections though... >> > >> >> I thought there was assumption that sssd will never handle root >> because it is a prerequisite to run sssd itself. (chicken and egg problem) >> And the issue with sudo and group membership is almost like that. > >SSSD could handle root just fine, we chose not to because SSSD >initially was for network identities. > >Now that we have support for the files provider though, it is possible >SSSD focus can shift toward playing with root accounts too. > >> > > >> > > > So I think that regardless of how sssd can end up in a state where it >> > > > is not runnin
[SSSD-users] Re: Offline caching of group names and memberships?
On Tue, 2019-09-24 at 17:58 +0200, Lukas Slebodnik wrote: > On (24/09/19 09:26), Simo Sorce wrote: > > On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: > > > 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. > > > > We build tools for admins, not for platonic perfections though... > > > > I thought there was assumption that sssd will never handle root > because it is a prerequisite to run sssd itself. (chicken and egg problem) > And the issue with sudo and group membership is almost like that. SSSD could handle root just fine, we chose not to because SSSD initially was for network identities. Now that we have support for the files provider though, it is possible SSSD focus can shift toward playing with root accounts too. > > > > > > > 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
[SSSD-users] Re: Offline caching of group names and memberships?
On (24/09/19 09:26), Simo Sorce wrote: >On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: >> 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. > >We build tools for admins, not for platonic perfections though... > I thought there was assumption that sssd will never handle root because it is a prerequisite to run sssd itself. (chicken and egg problem) And the issue with sudo and group membership is almost like that. >> >> > 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. > >Yes but for this case probably sudo rules are hardcoded in the sudoers >file. > OK that would be reasonable. But would be good to get info from reporter :-) >> 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. > >The issue is in not using t
[SSSD-users] Re: Offline caching of group names and memberships?
On Tue, 2019-09-24 at 10:56 +0200, Lukas Slebodnik wrote: > 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. We build tools for admins, not for platonic perfections though... > > > 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. Yes but for this case probably sudo rules are hardcoded in the sudoers file. > 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. The issue is in not using the fast cache when there is no reason not to. > But it would be good to get details from Spike about "someone shuts down sssd" Or some other system issue breaks it. For example a bad upgrade that breaks some library sssd depends on or other issues like that. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
[SSSD-users] Re: Offline caching of group names and memberships?
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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Offline caching of group names and memberships?
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. 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. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Offline caching of group names and memberships?
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? LS ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Offline caching of group names and memberships?
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. > 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. > (We have other AD integration products that have this “offline caching” > feature that can enabled or disabled.) SSSD has it too, I guess it is just a matter of tuning and/or "fixing" the behavior when the daemon is unresponsive. HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.org
