On Sun, Mar 21, 2021 at 08:06:46PM -0400, James Ralston wrote: > On Sun, Mar 21, 2021 at 4:24 PM Spike White <[email protected]> wrote: > > > If we limit our KRB5 encryption algorithms to only strong cyphers > > (AES128 and AES256), would that thwart the above SSSD attack? > > No. > > The fundamental issue is this: if an attacker has compromised a Linux > host, then the attacker has access to any Kerberos credential on that > host, both ticket-granting tickets (TGTs) and service tickets. > > This is true regardless of how/where the Kerberos credential is > cached: in a plain file (the FILE: or DIR: cache types), usually in > /tmp; in the kernel keyring (the KEYRING: cache type); or in KCM (the > KCM: cache type). > > Obviously, for an attacker, some cache types are easier to extract > than others (e.g., FILE:), but if it’s on the host, the attacker has > it. (If the credential is encrypted, then the key to decrypt it is > also on the host.) > > There’s actually another cache method that isn’t well-known: if the > host accesses an NFSv4 server using RPCSEC_GSS (Kerberos) > authentication, the Linux NFSv4 kernel client code will stash the > user’s NFSv4 service ticket for the NFSv4 server in the kernel, in > order to minimize upcalls to userland to acquire the service ticket. > This means that once a user on the NFSv4 client accesses files on the > NFSv4 server, until the cached service ticket in the kernel expires, > anyone with root on the NFSv4 client can access that user’s files on > the NFSv4 server simply by using su/sudo/runas to change to the user’s > uid. This is true even if the user ran kdestroy before logging off, > because kdestroy won’t remove the credential from the Linux NFSv4 > kernel client code credential cache. (Other than rebooting the host, > or waiting for it to expire, I know of no way to remove it.) > > > Also, our KRB5 tickets expire every 10 hrs. > > Ah, but do you enable renewable tickets? Because if you do, if an > attacker acquires the TGT, then until the renewal expiration is > reached, the attacker can simply keep renewing the ticket. > > All of this notwithstanding, using Kerberos authentication is still > better than using password authentication, where an attacker who > compromises a host can collect passwords from any users who provide > them (e.g., by using ssh with password or keyboard-interactive > authentication to get onto the host; by running kinit on the > compromised host). And Kerberos credentials tend to expire a lot > quicker than actual passwords do.
Hi, I agree with the above, if an attacker can become root on your client you are lost. I guess it would be similar if you have Administrator rights on a Window client. bye, Sumit > _______________________________________________ > 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] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ 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] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
