RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1472080 - Adding a deny command to a SUDO Rule with cmdcategory=ALL
Summary: Adding a deny command to a SUDO Rule with cmdcategory=ALL
Keywords:
Status: CLOSED DUPLICATE of bug 1472079
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-18 04:22 UTC by alka
Modified: 2017-07-28 17:14 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-28 17:14:30 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1113919 0 medium CLOSED Let deny commands be added to sudo rule with cmdcatetory=ALL 2021-02-22 00:41:40 UTC

Description alka 2017-07-18 04:22:34 UTC 
Description of problem:

I need to allow all commands except "sudo su" to my sudo rule within my FreeIPA. I have tried adding a sudo deny command to the to sudo rule with cmdcatetory=ALL. However when I try to add the command like ipa sudorule-add-deny-command sudo_access --sudocmds=/usr/bin/sudo su , it is giving error related to argument.

Further I tried adding a test deny command /usr/bin/vi , it didn't give any error. However the deny command added was not taken into effect. I tried editing the file using "vi" and I was able to do it without any error message being popped up.

Is there any work around to add the deny commands for sudo su to the sudo rule with cmdcategory=ALL. 

Version-Release number of selected component (if applicable):4.4.0
Comment 2 Rob Crittenden 2017-07-19 20:42:27 UTC 
You might try the --order option for the sudo rules to set the deny rule first.

There is currently no way to do "ALL except" IPA and that is generally discouraged in sudo in general. See SECURITY NOTES in the sudoers man page.
Comment 3 alka 2017-07-20 08:36:10 UTC 
Thanks for the reply.

However, I need to deny the sudo su command and allow all other commands under /bin, /usr/bin and /usr/sbin. So do you mean that I may need to manually add those commands within the FreeIPA sudo commands ?

Is there any other means to restrict the sudo su alone and allow all other commands, as manually adding all the other commands is tedious.
Comment 4 Rob Crittenden 2017-07-20 20:04:12 UTC 
As I suggested, the order options may do it for you.

Otherwise yeah, you will need to define what commands can be executed.
Comment 5 alka 2017-07-21 02:56:50 UTC 
Thanks for the update.

I tried creating a sudo rule with order=1 and added the sudo_deny command "/usr/bin/sudo su" and created another rule with order=2 and cmdcategory set to ALL. However the sudo su command is still getting executed and the user enters the root shell.
Comment 6 alka 2017-07-21 08:14:52 UTC 
As a follow-up, both rules cover up the same user and same host. I can see from the sudo-ldap manual that if multiple entries match, then the sudoOrder with highest attribute is chosen.

Please let me know if this is a bug with the sudoOrder option in FreeIPA ?
Comment 7 Rob Crittenden 2017-07-24 18:58:34 UTC 
sudoOrder is evaluated by the client, not the server. If the attribute is there then there is no bug in IPA.

For debugging, you can see how the entry looks in LDAP with:

% kinit someuser
% ldapsearch -Y GSSAPI -b ou=sudoers,dc=example,dc=com

You also mentioned a problem adding commands but didn't include how you tried to do that or what error message(s) you saw.
Comment 8 alka 2017-07-25 02:07:24 UTC 
Initially, I tried adding the command "ipa sudorule-add-deny-command sudo_access --sudocmds=/usr/bin/sudo su", I was getting error related to argument, later I replaced the command with ipa sudorule-add-deny-command sudo_access --sudocmds="/usr/bin/sudo su" and it got added.

However, now my concern is regarding the sudo rules. My FreeIPA Client on Debian is not processing the sudoOrder rules which I have created. It is always processing the cmdcategory=ALL sudo rule, and "sudo su" deny rule is not getting processed.
Comment 9 Petr Vobornik 2017-07-28 17:14:30 UTC 

*** This bug has been marked as a duplicate of bug 1472079 ***
Note You need to log in before you can comment on or make changes to this bug.