Bug 1472080

Summary:	Adding a deny command to a SUDO Rule with cmdcategory=ALL
Product:	Red Hat Enterprise Linux 7	Reporter:	alka <alkamuralimolu>
Component:	ipa	Assignee:	IPA Maintainers <ipa-maint>
Status:	CLOSED DUPLICATE	QA Contact:	ipa-qe <ipa-qe>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	pbrezina, pvoborni, rcritten, tscherf
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-28 17:14:30 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ***