1472079 – Adding a deny command to a SUDO Rule with cmdcategory=ALL

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 1472079 - 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 NOTABUG
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	ipa
Sub Component:
Version:	7.5-Alt
Hardware:	x86_64
OS:	Linux
Priority:	unspecified
Severity:	urgent
Target Milestone:	rc
Target Release:	---
Assignee:	IPA Maintainers
QA Contact:	ipa-qe
Docs Contact:
URL:
Whiteboard:
Duplicates (1):	1472080 (view as bug list)
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2017-07-18 04:21 UTC by alka
Modified:	2017-07-28 17:14 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-07-26 12:57:30 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
Error message for the command (71.41 KB, image/png) 2017-07-18 04:21 UTC, alka	no flags	Details
View All

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:21:38 UTC

Created attachment 1300225 [details]
Error message for the command

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 Petr Vobornik 2017-07-21 16:04:43 UTC

Seems like wrong CLI syntax. In general, IPA CLI expects one value without space. So in `--sudocmds=/usr/bin/sudo su` the argument for --sudocmds is /usr/bin/sudo and 'su' is unknown param/option. 

There it needs to be surrounded by quotes. E.g. --sudocmds="/usr/bin/sudo su"

Comment 3 alka 2017-07-24 01:30:05 UTC

Thanks for the reply.

The rule is getting added. However I need to deny the command "/usr/bin/sudo su" alone and allow all the commands (under /bin and /sbin). I came to know that with cmdcategory=ALL, we cannot add/set a deny rule alone.

So I tried the option for sudoOrder. I have created a rule with deny rules first with order=1 , followed by second sudo rule with order=2, which has cmdcategory set to "ALL".

However, the order doesn't work and the sudo su is still getting executed without taking the order which I have added.

Is this a bug with FreeIPA? Can you please provide me a solution to deny the sudo su alone and allow all other commands. I have even tried manually adding the commands under /bin and /sbin to the commands, however due to limitation in the number of commands that can be added, I cannot proceed with it.

Please provide me with a solution to go for it.

Comment 4 Petr Vobornik 2017-07-24 07:39:37 UTC

FreeIPA server is just a data store for sudo rules, the rules are then processed by SSSD.

AFAIK, in sudo order higher value wins.

Comment 5 alka 2017-07-24 07:47:40 UTC

However, the rule is not getting processed by SSSD. I have even tried clearing the SSSD cache and restarting the service there after. However it is not getting processed.

Comment 6 alka 2017-07-24 08:32:37 UTC

As a follow-up, I have set the sudoOrder for deny rule to 2 and sudoOrder for cmdcategory=ALL to 1.

Still its not working.. Is the sudoOrder applicable to RHEL systems alone ??

Comment 7 alka 2017-07-24 08:32:46 UTC

As a follow-up, I have set the sudoOrder for deny rule to 2 and sudoOrder for cmdcategory=ALL to 1.

Still its not working.. Is the sudoOrder applicable to RHEL systems alone ??

Comment 8 Petr Vobornik 2017-07-24 08:57:53 UTC

There is also a possibility that SSSD has the rules cached so that the change is not effective immediately.

Comment 9 alka 2017-07-24 09:20:32 UTC

No good. Tried deleting all the files under /var/lib/sss/db/ and restarted SSSD. However the result is still the same.

Is the sudoRule inverted for Non-RHEL Systems. I have seen a similar issue in one of the bugs within RedHat Bugzilla.

Comment 10 Pavel Březina 2017-07-25 08:32:53 UTC

You can't really use allow ALL and deny together in one rule, since you can't ensure the order of these values in LDAP. I.e. it may end up either deny su:allow ALL, or allow ALL:deny su which is will make the deny command ineffective. So is correct to split it to two separate rules and order them with sudo order.

Additionaly, sudo command "/usr/bin/sudo su" is equivalent to executing sudo as:
sudo /usr/bin/sudo su

...which is not what you want. Try to deny only "su" instead of "sudo su".

From sudo manual page:
>  If multiple entries match, the entry with the highest sudoOrder attribute is chosen. This corresponds to the “last match” behavior of the sudoers file. If the sudoOrder attribute is not present, a value of 0 is assumed. 

Thus you need to make sure that sudo order of deny su is higher then sudo order of allow ALL.

Comment 11 alka 2017-07-26 08:54:23 UTC

Thanks for the update. It worked. 

Really appreciate your explanation.

Comment 12 Petr Vobornik 2017-07-28 17:14:30 UTC

*** Bug 1472080 has been marked as a duplicate of this bug. ***

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