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.aqu...@citrixonline.com<mailto:jr.aqu...@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/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
