On Sep 30, 2010, at 9:37 AM, Sumit Bose wrote: > I agree, I only made the suggestion about the IPA server, because I > think that this "feature" is a bug in the current sudo code base, an > annoying bug at best and a serious security issue at worst.
It is both a bug and a security concern... one that I have personally been challenged with over and over... > yes, but it is also confusing if the permission to execute a command is > arbitrarily granted or denied. Maybe I'm a bit paranoid here, but I > think if a user cannot run a command he will complain and if he should > really be allowed to run it the rule can be fixed. If he can run a > command he is not allowed to use, he will not complain and only an > extensive audit might help to detect it. So I think a 'deny' rule always > win no matter where it can be found in the tree. > >> >> 2) Generally speaking, it may be in our best interest to encourage users NOT >> to duplicate (users/hosts) in multiple sudoRule objects in the database with >> mixed access rights... Sudo has an implicit Deny by default. While it may >> be possible to force FreeIPA to return 'deny' rules ahead of permissive >> ones, if a there are a pair of rules that contain the same users and hosts, >> but have different commands present, a match will STILL occur, and a deny >> will STILL randomly take place. > > btw. I cannot reproduce your issue where a command is denied where only > user and host is matching, can you give an example where this is > happening? Thanks Are you utilizing standard RFC LDAP, or is their any sorting occurring/enabled? Try deleting your rules, recreating them in a different order, or padding different characters to the CN... In your example, turn on /etc/ldap.conf: sudoers_debug 2, are you being returned your rule that matches your user and host but does not contain your command, then moving on to the preceding rule that does contain all 3? Or are you receiving your permissive rule first, matching, and stopping? I'm setting up a lab right now to demonstrate the flaw but as I recall, it is long standing, and by design... _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
