JR Aquino wrote: > I have encountered and troubleshot several instances recently where a user > was present in more than 1 sudo rule. One that permitted the user, the host, > and commands, and another that permited the user, and host, but no commands. > > It was discovered that: > * Sudo is a stop on first match... > * When sudo encounters a rule that matches the user and host it will stop > even if it does not match the command that was executed. We saw this to be > the case even if there were other more permissive sudo rules matching the > user and host. > > If FreeIPA keeps the current schema, a sudorule marked as a "deny", would > only randomly be enforced over more permissive rules matching host and user. > > Sudo will only return a 'negation command' ahead of a permissive command > /within the same rule/. > > It is a subtle and frustrating bug/feature to have to encounter and identify. > > We could ask Todd Miller to confirm. > > From the Sudo Ldap Man Page: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -Differences between LDAP and non-LDAP sudoers- > > There are some subtle differences in the way sudoers is handled once in LDAP. > Probably the biggest is that according to the RFC, LDAP ordering is arbitrary > and you cannot expect that Attributes and Entries are returned in any > specific order. If there are conflicting command rules on /an entry/, the > negative takes precedence. This is called paranoid behavior (not necessarily > the most specific match). > > dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com > objectClass: sudoRole > objectClass: top > cn: role1 > sudoUser: johnny > sudoHost: ALL > sudoCommand: ALL > sudoCommand: !/bin/sh > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Jr Aquino | Information Security Specialist > Citrix Online Division > >
I was aware of this writeup however I did not read it as there is a problem when there are multiple rules with negation. It actually nowhere says how SUDO handles multiple rules if they are mutually exclusive. Even in the current schema there is a problem when you have two rules and they contradict each other according to RFC this is a valid situation and thus should be handled correctly by SUDO. Do not take me wrong, I am willing to adjust the schema but if the SUDO utility can't handle contradicting rules even with the existing schema this is a very serious bug that we either should fix in SUDO or have a workaround. If you are right above that it does not look at other rules before making a decision and makes just based on one rule we can add the attribute(s) as you or I suggested but this generally limits the flexibility of the solution. Does anyone have experience with this behavior and can confirm the limitation? Thanks Dmitri >> May be I misunderstood how things work but my assumption was that SUDO >> will inspect multiple rules not just a rule returned by LDAP. Is this >> not the case? If it is the case then you are right that current schema >> is different and requires different grouping of the commands than with >> the standard schema but end result will be same. Let me try to >> illustrate it on example: >> >> Standard schema: >> Rule 1 has command A and !B >> Rule 2 has command C and !D >> >> In the new schema >> Rule X will have A & C >> Rule Y will be negative and have C & D >> >> Of cause Rules 1/2 and X/Y can't apply to the same user groups as the >> current rules . The thought was that other set of groups will >> potentially used by the records in the new schema. >> The new schema directs people to think in better "abstraction" terms : >> These users on these hosts can do something. >> or >> These users on these hosts can't do something. >> >> It is a much cleaner and more intuitive administrative model than what >> standard SUDO schema offers. >> But if it is a wrong assumption and really does not add a value we >> should definitely reconsider. >> >> If proposed approach is really "wrong" then I would rather remove the >> accessRuleType and add another attribute memberNotCmd similar to >> memberCmd that will point to groups or individual commands that need to >> be prohibited. And then support additional value of cmdCategory equal >> "none" that will imply that all sudo commands are prohibited. However I >> would argue that this is and overhead that "none" can be accomplished by >> totally disabling SUDO via HBAC. I would also argue that memberNotCmd & >> memberCmd in one rule are equivalent to two rules using same users/hosts >> but one for allowed commands and another for prohibited commands. >> >> So back to the example the assumption currently is that the SUDO will >> run through all the rules and match negative commands and then will do >> positive commands. In case of existing schema the prohibited commands >> will be scattered across multiple entries while in case of new schema >> they will be grouped in entries. Does this really matter for the SUDO >> usility how they are grouped and in what order they come? Based on the >> RFC it should not matter so I really do not see an issue other than >> forcing people to change rule definitions to do things in a more >> intuitive way. >> >> Please correct me if I am wrong. >> >> Thanks >> Dmitri >> -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
