[Freeipa-devel] Sudo Schema Bug

[Dmitri Pal]

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/