Right now sudo calls requires explicit password authentication from user. Imagine the situation: one has a farm of servers and he needs to periodically run a sudo command on all these servers at the same time. The solution that exists now calls for embedding passwords in scripts. The situation becomes even worse if the deployment would prefer to use 2FA for user authentication.
Proposal: allow sudo respect user authentication into the box if central policy allows such integration.
How that would work:
- User authenticates on a client system using 2FA - User gets a TGT with auth indicator that 2FA was conducted - User accesses a system over SSH using GSSAPI - User accesses sudo on the system - Sudo checks kerberos ticket and if the ticket matches its policies it is accepted as an authentication
I see several options with different security properties (but there can be other):
a. Sudo shares the same kerberos key as SSH and just checks that kerberos ticket for that user exists in ticket cache and that it has an auth indicator that matches the policy and lets user run the command if everything is OK. b. Sudo has its own keytab. Then it would require a ticket for itself and that would require either TGT delegation or s4u2proxy.
There is 'ksu' (kerberized su) already which afaik uses your schema a.
Maybe it would be possible to find some common ground between sudo and ksu so that authentication (password vs Kerberos) and authorization (ksu's .k5login and .k5user vs sudoers/plugins) can be reused by the other respective other tool?
AFAIU sudo has authentication and authorization while ksu just does authentication part. This means that if we can turn ksu authentication portion into a plugin and use it in sudo we would be able to accomplish what we need ti accomplish.
ab: support for this was removed from pam_krb5 because of major security problems
We should have a sudo keywords like REQKRB5 (to be use like NOPASSWD is used), that will cause sudo to validate that the user has a TGT and can acquire a ticket for the host service (or a sudo specific service ?). It would be relatively easy to implement with gssapi and a helper to fork off of the sudo binary at invocation.
We need to support the case when TGT is not forwarded to the target system but there is a user's ST for the host.
Metadata Update from @dpal: - Issue assigned to someone - Issue set to the milestone: Future Releases
Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.
Metadata Update from @rcritten: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
This is possible with a recent version of sssd by using the pam_sss_gss_module.
Login to comment on this ticket.