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

Does anyone have experience with this behavior and can confirm the


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

Freeipa-devel mailing list

Reply via email to