[Freeipa-devel] Sudo Schema Bug

Thu Sep 30 09:32:10 UTC 2010

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel