On Thu, Sep 30, 2010 at 12:06:01AM -0400, Dmitri Pal wrote: > 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?
I have done some test with: dn: cn=rule2,ou=sudoers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole sudoHost: ALL sudoCommand: !/usr/bin/less sudoUser: sbose cn: rule2 dn: cn=rule3,ou=sudoers,dc=my-domain,dc=com objectClass: top objectClass: sudoRole sudoHost: ALL sudoCommand: /usr/bin/less sudoUser: sbose cn: rule3 and also had a look at the source code. I can confirm that sudo stops processing the rules on the first match, no different if the command is allowed or denied. I think this behaviour is a contradiction to 'paranoid behavior'. I think that instead of 'If there are conflicting command rules on an entry, the negative takes precedence.' the "expected" (at least that's what I had expected) behavior is better described by "If there are conflicting command rules on an entry OR ON DIFFERENT MATCHING ENTRIES, the negative takes precedence." I would say this is a bug in sudo and should be fixed. Maybe we can tweak the plugins of the IPA server in a way that the deny rules are always send first (and hope that the client libraries do not change the order of the entries :-). bye, Sumit > > 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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
