[Freeipa-devel] Sudo Schema Bug

[JR Aquino]

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

> 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