[Freeipa-devel] Sudo Schema Bug

[Dmitri Pal]

JR Aquino wrote:
> I believe we have made an oversight in the way that sudo processes 'deny' or negations via ldap...
>
> Currently our IPA sudo Schema has ipasudorule objects set to contain an attribute: accessRuleType
>
> Unfortunately, sudo does not have a means to do a 'deny' in this way...
>
> For a command, user, or host to be 'denied' it must be proceeded with an exclamation point: !
>
> Due to the RFC, LDAP will return entries in an arbitrary order, as such sudo will do first match on the "!" negations.  However, this is only true within the same Rule, I.E. if a user belongs to multiple groups, one which allows the command, and separate one which negates the command, sudo can and will pass or fail depending on which object ldap returns back for the search results.
>
> It occurs to me that we have 2 ways to proceed.
>
> 0) I suggest we remove the attribute: accessRuleType from ipasudorule.
>
> 1) Add the attribute: accessRuleType to ipasudocmdgrp.
>     -This has the benefit of not having to duplicate new ipasudocmd's only to prepend a "!" in front of them since an ipasudorule can contain multiple ipasudocmdgrp's.
>     I.E. /usr/bin/less can be added to an 'allow' command group and remain unchanged, but when also added to a 'deny' command group, the compat layer should prepend the "!" for us.
>
> Please let me know if anyone has any objections or observations.
>   

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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Jr Aquino, GCIH | Information Security Specialist
> Citrix Online | 6500 Hollister Avenue | Goleta, CA 93117
> T:  +1 805.690.3478
> jr.aquino at citrixonline.com<mailto:jr.aquino at citrixonline.com>
> http://www.citrixonline.com<http://www.citrixonline.com/>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/