| Summary: | [RFE] Add Kerberos support for sudo | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Striker Leggette <striker> |
| Component: | sudo | Assignee: | Radovan Sroka <rsroka> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.4 | CC: | cww, dapospis, david.sastre, ekeck, mkosek, mthacker, pkis, riehecky, striker |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | Flags: | striker:
needinfo-
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-11-06 11:28:00 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1420851, 1473733 | ||
|
Description
Striker Leggette
2016-10-24 15:56:35 UTC
Renaming the Bugzilla as forking the sudo may not be the best way. The current proposal we have at hand is rather extending sudo itself to support Kerberos as one way of sudo authentication. This is the current user story of a minimal version that is a result of the initial brainstorming: User story: As an Administrator, I am authenticated to a system, I have a Kerberos TGT ticket and I want to run sudo commands without entering my password because it is inconvenient or because I do not want to share my credentials over the network Acceptance Criteria: - Workflow is disabled by default - Workflow can be enabled for any set of users by a local configuration change (/etc/sudoers or related configuration file) - sudo should respect/inspect the ticket that is available and it should not acquire ticket itself (i.e. via kinit). It should rather delegate this to PAM stack. - If the user does not have any Kerberos ticket or has an invalid Kerberos ticket (expired, …) he should be prompted in the same way as it is now (via PAM stack), even if workflow is enabled - Even with passwordless sudo workflow, SUDO should run PAM account step to verify that the account is still valid when running the command (i.e. the user was not disabled or forbidden SUDO access in IdM HBAC) - When workflow is enabled the passwordless behavior should be enabled for a limited time that is less or equal than the time of the TGT ticket that was used to log into the system. Feedback for this story and the plan in general is more than welcome! This feature request and the user story we came with was discussed recently in engineering. Specifically, we discussed the "WHY" part of the user story (use case), i.e. "users do not have to enter the password because it is inconvenient or because they do not want to share the credentials over the network". The main question that came up is - "could this requirement (the why) be satisfied with existing SUDO 'NOPASSWD' keyword" (or "!authenticate" when set in FreeIPA SUDO rule), given that NOPASSWD keyword also lets user enter the SUDO command without entering the password?" Entering password in SUDO authorization is mostly an additional security measure that authorizes that the authenticated user is really present in the terminal and did not just step out from the console. If the authentication is done via Kerberos TGT presence check, this authorization step is skipped for both NOPASSWD way and Kerberos TGT check way (this RFE). In order to continue with this RFE, we would first need to learn more details from the requestors - why the existing NOPASSWD way of skipping password-based authorization is not sufficient and thus what actual business problem will this RFE solve. We do not intend to create a fork of sudo to support Kerberos and feel that there are existing solutions to this issue of varied access to sudo. For example, using the built-in Identity Management capabilities to assign sudo rights to an existing userid in an automated / scheduled manner. Or using Ansible to automate the sudo users lists. This bug is being closed. We can definitely continue the conversation about how to address the workflow being requested. Additionally, if a solution were to be created that relied upon PAM modules, sudo could easily take advantage of that without change. |