Bug 1388167 - [RFE] Add Kerberos support for sudo
Summary: [RFE] Add Kerberos support for sudo
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sudo
Version: 7.4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Radovan Sroka
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1420851 1473733
TreeView+ depends on / blocked
 
Reported: 2016-10-24 15:56 UTC by Striker Leggette
Modified: 2021-12-10 14:46 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-06 11:28:00 UTC
Target Upstream Version:
striker: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FedoraHosted FreeIPA 5111 0 None None None Never

Description Striker Leggette 2016-10-24 15:56:35 UTC
[+] Description of problem:
 - Request to fork 'sudo' to new name 'ksudo' which has Kerberos support.

Comment 5 Martin Kosek 2017-08-16 10:58:47 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!

Comment 7 Martin Kosek 2017-09-12 14:19:14 UTC
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.

Comment 15 Mark Thacker 2018-11-06 11:28:00 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.