> On Sep 30, 2010, at 6:17 AM, 
> <freeipa-devel-requ...@redhat.com<mailto:freeipa-devel-requ...@redhat.com>> 
> <freeipa-devel-requ...@redhat.com<mailto:freeipa-devel-requ...@redhat.com>> 
> wrote:
> 
> 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 :-).
> 

On Thu, Sep 30, 2010 at 07:44:08AM -0700, JR Aquino wrote:
> While I agree that it is a subtle and frustrating bug/feature, I think that 
> it is important to consider a few things...
> 
> 0) We do not maintain sudo, and it benefits the community if we maintain 
> solutions that accommodate the current sudo code base in the interim until 
> Todd commits features that we pioneer... (Get rid of NisNetgroups Todd!)

I agree, I only made the suggestion about the IPA server, because I
think that this "feature" is a bug in the current sudo code base, an
annoying bug at best and a serious security issue at worst.

> 
> 1) Administratively, it may be confusing to find out that someone is being 
> prohibited by a contradictory 'deny' object somewhere in the directory rather 
> than contained in the same rule that their permissive rules are defined.

yes, but it is also confusing if the permission to execute a command is
arbitrarily granted or denied. Maybe I'm a bit paranoid here, but I
think if a user cannot run a command he will complain and if he should
really be allowed to run it the rule can be fixed. If he can run a
command he is not allowed to use, he will not complain and only an
extensive audit might help to detect it. So I think a 'deny' rule always
win no matter where it can be found in the tree.

> 
> 2) Generally speaking, it may be in our best interest to encourage users NOT 
> to duplicate (users/hosts) in multiple sudoRule objects in the database with 
> mixed access rights... Sudo has an implicit Deny by default.  While it may be 
> possible to force FreeIPA to return 'deny' rules ahead of permissive ones, if 
> a there are a pair of rules that contain the same users and hosts, but have 
> different commands present, a match will STILL occur, and a deny will STILL 
> randomly take place.

btw. I cannot reproduce your issue where a command is denied where only
user and host is matching, can you give an example where this is
happening? Thanks

bye,
Sumit

> 
> I foresee the need of the community to use FreeIPA with clients that do not 
> have SSSD present and that are using sudo provided via their distribution.
> 
> We should anticipate how the original Sudo responds, otherwise we risk 
> designing a system that is only functional if our user base subscribes to ALL 
> of our software components.
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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/>
> 

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to