Re: [Freeipa-devel] Sudo Schema Bug/Feature
JR Aquino wrote: On Oct 4, 2010, at 2:02 PM, Rob Crittenden wrote: Dmitri Pal wrote: Dmitri Pal wrote: Dmitri Pal wrote: How do we adjust FreeIPA such that it ensures Deny-IPASudoRules precede any Allow-IPASudoRules ? So it looks like current schema would not fly well with SUDO due to SUDO bug/feature. SUDO will match just any first rule that satisfies the user-hpost-command combination but we can't guarantee that rules come in the same order. So there is a possibility that allow rule will come before deny rule in our case and will be matched. It is unfortunate and should be fixed by SUDO. In a meantime we need to alter the schema to be able to express allowed and not allowed commands in one rule. It will be up to the admin to know the limitations of SUDO based on the documentation we provide and construct the rules in a non contradicting way. We might be able to add some nice checks in future. So here is current schema: objectClasses: (2.16.840.1.113730.3.8.8.TBD NAME 'ipaSudoRule' SUP ipaAssociation STRUCTURAL MUST accessRuleType MAY ( externalUser $ externalHost $ hostMask $ memberCmd $ cmdCategory $ ipaSudoOpt $ ipaSudoRunAs $ ipaSudoRunAsExtUser $ ipaSudoRunAsUserCategory $ ipaSudoRunAsGroup $ ipaSudoRunAsExtGroup $ ipaSudoRunAsGroupCategory ) X-ORIGIN 'IPA v2' ) We will : * Remove accessRuleType * Add memberNotCmd same a memberCmd attributeTypes: (2.16.840.1.113730.3.8.7.TBD NAME 'memberNotCmd' DESC 'Reference to a command or group of the commands that is not allowed.' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) The logic then will be: * If no memberCmd, memberNotCmd or cmdCategory attribute is specified - no command is allowed * If cmdCategory is specified (only value is all) all other attributes are ignored and all commands are allowed * If cmdCategory is not specified * If memberCmd is specified it defines commands or groups of the commands that are allowed * If memberNotCmd is specified it defines commands or groups of the commands that are not allowed Both attributes are allowed at the same time defining allowed and not allowed commands within the same rule. This does not solve the problem fully but at least gets us into the same boat as current SUDO schema. Comments welcome! If there are no objections by end of Friday I will craft a patch over the weekend. Thanks Dmitri I updated the wiki and implemented the change. Patch is attached. Rebased patch attached. ack, pushed to master. JR, can you fix up the sudo plugins to match this new schema? thanks rob Attached is the patch for modifications to sudorule and its test suite to accommodate the schema redesign. We now create allow rules or deny rules and no longer reference accessruletype. ack, pushed to master. The -del tests are still failing but I confirmed that with Pavel's patches these tests pass. Those patches just need a little more work. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug/Feature
On Oct 4, 2010, at 2:02 PM, Rob Crittenden wrote: Dmitri Pal wrote: Dmitri Pal wrote: Dmitri Pal wrote: How do we adjust FreeIPA such that it ensures Deny-IPASudoRules precede any Allow-IPASudoRules ? So it looks like current schema would not fly well with SUDO due to SUDO bug/feature. SUDO will match just any first rule that satisfies the user-hpost-command combination but we can't guarantee that rules come in the same order. So there is a possibility that allow rule will come before deny rule in our case and will be matched. It is unfortunate and should be fixed by SUDO. In a meantime we need to alter the schema to be able to express allowed and not allowed commands in one rule. It will be up to the admin to know the limitations of SUDO based on the documentation we provide and construct the rules in a non contradicting way. We might be able to add some nice checks in future. So here is current schema: objectClasses: (2.16.840.1.113730.3.8.8.TBD NAME 'ipaSudoRule' SUP ipaAssociation STRUCTURAL MUST accessRuleType MAY ( externalUser $ externalHost $ hostMask $ memberCmd $ cmdCategory $ ipaSudoOpt $ ipaSudoRunAs $ ipaSudoRunAsExtUser $ ipaSudoRunAsUserCategory $ ipaSudoRunAsGroup $ ipaSudoRunAsExtGroup $ ipaSudoRunAsGroupCategory ) X-ORIGIN 'IPA v2' ) We will : * Remove accessRuleType * Add memberNotCmd same a memberCmd attributeTypes: (2.16.840.1.113730.3.8.7.TBD NAME 'memberNotCmd' DESC 'Reference to a command or group of the commands that is not allowed.' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) The logic then will be: * If no memberCmd, memberNotCmd or cmdCategory attribute is specified - no command is allowed * If cmdCategory is specified (only value is all) all other attributes are ignored and all commands are allowed * If cmdCategory is not specified * If memberCmd is specified it defines commands or groups of the commands that are allowed * If memberNotCmd is specified it defines commands or groups of the commands that are not allowed Both attributes are allowed at the same time defining allowed and not allowed commands within the same rule. This does not solve the problem fully but at least gets us into the same boat as current SUDO schema. Comments welcome! If there are no objections by end of Friday I will craft a patch over the weekend. Thanks Dmitri I updated the wiki and implemented the change. Patch is attached. Rebased patch attached. ack, pushed to master. JR, can you fix up the sudo plugins to match this new schema? thanks rob Will get right on it. Try to have it done early tomorrow if not by end of day today. -JR ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug/Feature
On Oct 4, 2010, at 2:02 PM, Rob Crittenden wrote: Dmitri Pal wrote: Dmitri Pal wrote: Dmitri Pal wrote: How do we adjust FreeIPA such that it ensures Deny-IPASudoRules precede any Allow-IPASudoRules ? So it looks like current schema would not fly well with SUDO due to SUDO bug/feature. SUDO will match just any first rule that satisfies the user-hpost-command combination but we can't guarantee that rules come in the same order. So there is a possibility that allow rule will come before deny rule in our case and will be matched. It is unfortunate and should be fixed by SUDO. In a meantime we need to alter the schema to be able to express allowed and not allowed commands in one rule. It will be up to the admin to know the limitations of SUDO based on the documentation we provide and construct the rules in a non contradicting way. We might be able to add some nice checks in future. So here is current schema: objectClasses: (2.16.840.1.113730.3.8.8.TBD NAME 'ipaSudoRule' SUP ipaAssociation STRUCTURAL MUST accessRuleType MAY ( externalUser $ externalHost $ hostMask $ memberCmd $ cmdCategory $ ipaSudoOpt $ ipaSudoRunAs $ ipaSudoRunAsExtUser $ ipaSudoRunAsUserCategory $ ipaSudoRunAsGroup $ ipaSudoRunAsExtGroup $ ipaSudoRunAsGroupCategory ) X-ORIGIN 'IPA v2' ) We will : * Remove accessRuleType * Add memberNotCmd same a memberCmd attributeTypes: (2.16.840.1.113730.3.8.7.TBD NAME 'memberNotCmd' DESC 'Reference to a command or group of the commands that is not allowed.' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) The logic then will be: * If no memberCmd, memberNotCmd or cmdCategory attribute is specified - no command is allowed * If cmdCategory is specified (only value is all) all other attributes are ignored and all commands are allowed * If cmdCategory is not specified * If memberCmd is specified it defines commands or groups of the commands that are allowed * If memberNotCmd is specified it defines commands or groups of the commands that are not allowed Both attributes are allowed at the same time defining allowed and not allowed commands within the same rule. This does not solve the problem fully but at least gets us into the same boat as current SUDO schema. Comments welcome! If there are no objections by end of Friday I will craft a patch over the weekend. Thanks Dmitri I updated the wiki and implemented the change. Patch is attached. Rebased patch attached. ack, pushed to master. JR, can you fix up the sudo plugins to match this new schema? thanks rob Attached is the patch for modifications to sudorule and its test suite to accommodate the schema redesign. We now create allow rules or deny rules and no longer reference accessruletype. 0001-sudorule-mods-for-schema-update.patch Description: 0001-sudorule-mods-for-schema-update.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug/Feature
Dmitri Pal wrote: How do we adjust FreeIPA such that it ensures Deny-IPASudoRules precede any Allow-IPASudoRules ? So it looks like current schema would not fly well with SUDO due to SUDO bug/feature. SUDO will match just any first rule that satisfies the user-hpost-command combination but we can't guarantee that rules come in the same order. So there is a possibility that allow rule will come before deny rule in our case and will be matched. It is unfortunate and should be fixed by SUDO. In a meantime we need to alter the schema to be able to express allowed and not allowed commands in one rule. It will be up to the admin to know the limitations of SUDO based on the documentation we provide and construct the rules in a non contradicting way. We might be able to add some nice checks in future. So here is current schema: objectClasses: (2.16.840.1.113730.3.8.8.TBD NAME 'ipaSudoRule' SUP ipaAssociation STRUCTURAL MUST accessRuleType MAY ( externalUser $ externalHost $ hostMask $ memberCmd $ cmdCategory $ ipaSudoOpt $ ipaSudoRunAs $ ipaSudoRunAsExtUser $ ipaSudoRunAsUserCategory $ ipaSudoRunAsGroup $ ipaSudoRunAsExtGroup $ ipaSudoRunAsGroupCategory ) X-ORIGIN 'IPA v2' ) We will : * Remove accessRuleType * Add memberNotCmd same a memberCmd attributeTypes: (2.16.840.1.113730.3.8.7.TBD NAME 'memberNotCmd' DESC 'Reference to a command or group of the commands that is not allowed.' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) The logic then will be: * If no memberCmd, memberNotCmd or cmdCategory attribute is specified - no command is allowed * If cmdCategory is specified (only value is all) all other attributes are ignored and all commands are allowed * If cmdCategory is not specified * If memberCmd is specified it defines commands or groups of the commands that are allowed * If memberNotCmd is specified it defines commands or groups of the commands that are not allowed Both attributes are allowed at the same time defining allowed and not allowed commands within the same rule. This does not solve the problem fully but at least gets us into the same boat as current SUDO schema. Comments welcome! If there are no objections by end of Friday I will craft a patch over the weekend. Thanks Dmitri I updated the wiki and implemented the change. Patch is attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From 099e2660b97e42bba9e72d6b0c12e2975c883fc1 Mon Sep 17 00:00:00 2001 From: Dmitri Pal d...@redhat.com Date: Sun, 3 Oct 2010 13:09:34 -0400 Subject: [PATCH] [SUDO] Allow and deny commands in one rule 1) Added new attribute memberDenyCommand 2) Renamed memberCmd to memberAllowCmd 3) Changed the object class: * removed type * reflected the rename change * added the new attribute 4) Renumbered the attributes (while we still can) for consistency. --- install/share/60sudo.ldif | 30 -- 1 files changed, 16 insertions(+), 14 deletions(-) diff --git a/install/share/60sudo.ldif b/install/share/60sudo.ldif index d8db306f2e24b1d744a85707849fe1162b2c78e1..d7080859be12abd7b1f27a5f9cbeebee44af8969 100644 --- a/install/share/60sudo.ldif +++ b/install/share/60sudo.ldif @@ -6,30 +6,32 @@ dn: cn=schema ## ObjectClasses: 2.16.840.1.113730.3.8.8.x ## ## Attribute to store DN of a SUDO command or a group of SUDO commands -attributetypes: (2.16.840.1.113730.3.8.7.1 NAME 'memberCmd' DESC 'Reference to a command or group of the commands.' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) +attributetypes: (2.16.840.1.113730.3.8.7.1 NAME 'memberAllowCmd' DESC 'Reference to a command or group of the commands that are allowed by the rule.' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) ## Attribute to store command category -attributeTypes: (2.16.840.1.113730.3.8.7.2 NAME 'cmdCategory' DESC 'Additional classification for commands' EQUALITY caseIgnoreMatch ORDERING caseIgnoreMatch SUBSTR
Re: [Freeipa-devel] Sudo Schema Bug
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
Re: [Freeipa-devel] Sudo Schema Bug
Todd was able to confirm this for me... On Sep 29, 2010, at 9:06 PM, Dmitri Pal wrote: 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? Thanks Dmitri On Sep 30, 2010, at 6:28 AM, Todd C. Miller wrote: In message 2ef9f6d2-2a9f-4466-a205-907acfa52...@citrixonline.commailto:2ef9f6d2-2a9f-4466-a205-907acfa52...@citrixonline.com so spake JR Aquino (JR.Aquino): Todd, if you have a moment, could you weigh in on this? We are trying to clarify as to whether Sudo is a first match and stop, or if it will search the whole directory for rules that match and then make a calcu lated decision. When using /etc/sudoers, sudo will use the last match. When using LDAP, sudo will stop on the first matching entry, though it will prefer a negative match within that entry. It would probably be better to evaluate all returned entries instead of stopping at the first match. I've considered adding a weight or ordering attribute to the entries to make it possible to emulate the last match behavior but I'm not sure that is worth doing. A future version of sudo may choose the most exact match instead, which seems safer. - todd ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug/Feature
On Sep 30, 2010, at 6:17 AM, freeipa-devel-requ...@redhat.commailto:freeipa-devel-requ...@redhat.com freeipa-devel-requ...@redhat.commailto: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 :-). 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!) 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. 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. 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.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug/Feature
On Sep 30, 2010, at 6:17 AM, freeipa-devel-requ...@redhat.commailto:freeipa-devel-requ...@redhat.com freeipa-devel-requ...@redhat.commailto: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.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug/Feature
On Sep 30, 2010, at 9:37 AM, Sumit Bose wrote: 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. It is both a bug and a security concern... one that I have personally been challenged with over and over... 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 Are you utilizing standard RFC LDAP, or is their any sorting occurring/enabled? Try deleting your rules, recreating them in a different order, or padding different characters to the CN... In your example, turn on /etc/ldap.conf: sudoers_debug 2, are you being returned your rule that matches your user and host but does not contain your command, then moving on to the preceding rule that does contain all 3? Or are you receiving your permissive rule first, matching, and stopping? I'm setting up a lab right now to demonstrate the flaw but as I recall, it is long standing, and by design... ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug/Feature
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 I retract my previous statement and stand corrected: I have run a test and verified on Redhat Enterprise 5.5 that Sudo is behaving as we believe it should. A command NO MATCH occurs only if sudo parses all results and does not find a match. I am documenting this for my internal team so that we can investigate the systems that have had contrary results as they are likely the result of a definite bug. I apologize for the F.U.D. So then, that just leaves us with: How do we adjust FreeIPA such that it ensures Deny-IPASudoRules precede any Allow-IPASudoRules ? Sudo Debug: --- sudo: ldap_set_option(LDAP_OPT_X_TLS, LDAP_OPT_X_TLS_HARD) sudo: ldap_sasl_bind_s() ok sudo: found:cn=defaults,cn=SUDOers,dc=example,dc=com sudo: ldap sudoOption: 'logfile=/var/log/sudolog' sudo: ldap sudoOption: 'ignore_dot' sudo: ldap search '(|(sudoUser=testuser)(sudoUser=%testuser)(sudoUser=%UGRP-Test1)(sudoUser=ALL))' sudo: found:cn=ROLE-jumpers_RO,cn=SUDOers,dc=example,dc=com sudo: ldap sudoHost 'jump2.example.com' ... not sudo: ldap sudoHost 'jump1.example.com' ... MATCH! sudo: found:cn=ROLE-jr-test,cn=SUDOers,dc=example,dc=com sudo: ldap sudoHost 'jump2.example.com' ... not sudo: ldap sudoHost 'jump1.example.com' ... MATCH! sudo: found:cn=ROLE-jr-test2,cn=SUDOers,dc=example,dc=com sudo: ldap sudoHost 'jump2.example.com' ... not sudo: ldap sudoHost 'jump1.example.com' ... MATCH! sudo: ldap sudoCommand 'ALL' ... MATCH! sudo: Command allowed sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(0)=0x02 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug/Feature
How do we adjust FreeIPA such that it ensures Deny-IPASudoRules precede any Allow-IPASudoRules ? So it looks like current schema would not fly well with SUDO due to SUDO bug/feature. SUDO will match just any first rule that satisfies the user-hpost-command combination but we can't guarantee that rules come in the same order. So there is a possibility that allow rule will come before deny rule in our case and will be matched. It is unfortunate and should be fixed by SUDO. In a meantime we need to alter the schema to be able to express allowed and not allowed commands in one rule. It will be up to the admin to know the limitations of SUDO based on the documentation we provide and construct the rules in a non contradicting way. We might be able to add some nice checks in future. So here is current schema: objectClasses: (2.16.840.1.113730.3.8.8.TBD NAME 'ipaSudoRule' SUP ipaAssociation STRUCTURAL MUST accessRuleType MAY ( externalUser $ externalHost $ hostMask $ memberCmd $ cmdCategory $ ipaSudoOpt $ ipaSudoRunAs $ ipaSudoRunAsExtUser $ ipaSudoRunAsUserCategory $ ipaSudoRunAsGroup $ ipaSudoRunAsExtGroup $ ipaSudoRunAsGroupCategory ) X-ORIGIN 'IPA v2' ) We will : * Remove accessRuleType * Add memberNotCmd same a memberCmd attributeTypes: (2.16.840.1.113730.3.8.7.TBD NAME 'memberNotCmd' DESC 'Reference to a command or group of the commands that is not allowed.' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) The logic then will be: * If no memberCmd, memberNotCmd or cmdCategory attribute is specified - no command is allowed * If cmdCategory is specified (only value is all) all other attributes are ignored and all commands are allowed * If cmdCategory is not specified * If memberCmd is specified it defines commands or groups of the commands that are allowed * If memberNotCmd is specified it defines commands or groups of the commands that are not allowed Both attributes are allowed at the same time defining allowed and not allowed commands within the same rule. This does not solve the problem fully but at least gets us into the same boat as current SUDO schema. Comments welcome! If there are no objections by end of Friday I will craft a patch over the weekend. Thanks Dmitri ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug
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.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://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
Re: [Freeipa-devel] Sudo Schema Bug
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudo Schema Bug
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? 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
