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