Bug 1472079 - Adding a deny command to a SUDO Rule with cmdcategory=ALL
Adding a deny command to a SUDO Rule with cmdcategory=ALL
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.5-Alt
x86_64 Linux
unspecified Severity urgent
: rc
: ---
Assigned To: IPA Maintainers
ipa-qe
:
: 1472080 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-18 00:21 EDT by alka
Modified: 2017-07-28 13:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-26 08:57:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1113919 None None None 2017-07-18 00:21 EDT

  None (edit)
Description alka 2017-07-18 00:21:38 EDT
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 12:04:43 EDT
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-23 21:30:05 EDT
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 03:39:37 EDT
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 03:47:40 EDT
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 04:32:37 EDT
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 04:32:46 EDT
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 04:57:53 EDT
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 05:20:32 EDT
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 04:32:53 EDT
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 04:54:23 EDT
Thanks for the update. It worked. 

Really appreciate your explanation.
Comment 12 Petr Vobornik 2017-07-28 13:14:30 EDT
*** 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.