Red Hat Bugzilla – Bug 1472079
Adding a deny command to a SUDO Rule with cmdcategory=ALL
Last modified: 2017-07-28 13:14:30 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
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"
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.
FreeIPA server is just a data store for sudo rules, the rules are then processed by SSSD.
AFAIK, in sudo order higher value wins.
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.
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 ??
There is also a possibility that SSSD has the rules cached so that the change is not effective immediately.
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.
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.
Thanks for the update. It worked.
Really appreciate your explanation.
*** Bug 1472080 has been marked as a duplicate of this bug. ***