Re: [Freeipa-devel] Sudoers schema
Dmitri Pal wrote: Hello, It occurred to me that we can have a compromise. We can have two ways and let the admins to decide which model to follow. So the schema will look like this: The sudo rule entry will have a string attribute to put a command verbatim as it is designed now and an attribute that contains a DN of a group of the commands (or points to commands individually). It seems though that instead of having separate objects for a command with just one attribute (the command itself) and then have an group of commands object with pointer to individual commands we can have just a command group object with a multi value attribute for commands entered verbatim. This way we probably even do not need to have two attributes as I proposed above. A creative solution but I'd almost rather go with the complex way than this. If you wanted to change a command-line you'd have to manually go through all the groups and change them one at a time. I'm not 100% opposed to the command and group-of-commands interface I just wonder if in the typical case it isn't overkill. For those with thousands of sudo rules it may make a lot of sense. My initial objection was it seemed to be over-engineered, a Bentley when a Pinto would do :-) Sorry for designing on the fly. So options are: 1) Leave as designed - does not provide a good role management (Nack) 2) Revert to original - too complex and limiting (Nack) 3) Have a hybrid of 1) 2) represented by two attributes 4) Make the rule reference an object named command group. The command group object will have a mv attribute with the commands IMO the last one is the simple compromise that addresses both concerns. Let me tell you how this would work on the command line. We'd likely have 3 plugins (I'm not married to these names, they are just illustrative): - sudo_cmds: CRUD for managing the individual commands - sudo_group: CRUD for grouping sudo_cmds into groups of commands - sudo_rules: CRUD for managing the rules themselves, the core of which assigning sudo_groups and/or sudo_cmds to it. I gather that a sudo command would use the memberOf plugin to be a member of a sudo group, right? Could that be skipped? It does help us know what groups use a given command but we can run a query to find that if necessary. That might alleviate Simo's concern that memberOf isn't free. The other problem with multi-value commands is we don't yet have a nice way on the command-line to manage them. You'd want to be able to do things like delete the 3rd of these 5 or modify the 7th one to this, etc. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudoers schema
On Thu, Aug 19, 2010 at 02:47:33PM -0400, Rob Crittenden wrote: Dmitri Pal wrote: Hello, It occurred to me that we can have a compromise. We can have two ways and let the admins to decide which model to follow. So the schema will look like this: The sudo rule entry will have a string attribute to put a command verbatim as it is designed now and an attribute that contains a DN of a group of the commands (or points to commands individually). It seems though that instead of having separate objects for a command with just one attribute (the command itself) and then have an group of commands object with pointer to individual commands we can have just a command group object with a multi value attribute for commands entered verbatim. This way we probably even do not need to have two attributes as I proposed above. A creative solution but I'd almost rather go with the complex way than this. If you wanted to change a command-line you'd have to manually go through all the groups and change them one at a time. I'm not 100% opposed to the command and group-of-commands interface I just wonder if in the typical case it isn't overkill. For those with thousands of sudo rules it may make a lot of sense. My initial objection was it seemed to be over-engineered, a Bentley when a Pinto would do :-) Sorry for designing on the fly. So options are: 1) Leave as designed - does not provide a good role management (Nack) 2) Revert to original - too complex and limiting (Nack) 3) Have a hybrid of 1) 2) represented by two attributes 4) Make the rule reference an object named command group. The command group object will have a mv attribute with the commands IMO the last one is the simple compromise that addresses both concerns. Let me tell you how this would work on the command line. We'd likely have 3 plugins (I'm not married to these names, they are just illustrative): - sudo_cmds: CRUD for managing the individual commands - sudo_group: CRUD for grouping sudo_cmds into groups of commands - sudo_rules: CRUD for managing the rules themselves, the core of which assigning sudo_groups and/or sudo_cmds to it. +1 if we want to have groups we should use this design, because this is the way other objects like hosts or services are handled in IPA. I gather that a sudo command would use the memberOf plugin to be a member of a sudo group, right? Could that be skipped? It does help us know what groups use a given command but we can run a query to find that if necessary. That might alleviate Simo's concern that memberOf isn't free. As Jakub mentioned earlier sudo creates search filters based on the user and his group memberships. So I think the memberOf plugin is not needed. bye, Sumit The other problem with multi-value commands is we don't yet have a nice way on the command-line to manage them. You'd want to be able to do things like delete the 3rd of these 5 or modify the 7th one to this, etc. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudoers schema
Hello, It occurred to me that we can have a compromise. We can have two ways and let the admins to decide which model to follow. So the schema will look like this: The sudo rule entry will have a string attribute to put a command verbatim as it is designed now and an attribute that contains a DN of a group of the commands (or points to commands individually). It seems though that instead of having separate objects for a command with just one attribute (the command itself) and then have an group of commands object with pointer to individual commands we can have just a command group object with a multi value attribute for commands entered verbatim. This way we probably even do not need to have two attributes as I proposed above. Sorry for designing on the fly. So options are: 1) Leave as designed - does not provide a good role management (Nack) 2) Revert to original - too complex and limiting (Nack) 3) Have a hybrid of 1) 2) represented by two attributes 4) Make the rule reference an object named command group. The command group object will have a mv attribute with the commands IMO the last one is the simple compromise that addresses both concerns. Thanks Dmitri ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudoers schema
JR Aquino wrote: That was the original design, however I was told that this is not something people will be interested in. Thanks for you data point but to change it we probably need couple more data points and comments. I would be very interested as to why there was resistance or a thought that people would not be interested in an design that scales. I welcome them to post the solutions that they have found in granularly managing several hundred users access to thousands of servers with mixed access rights spread out into dozens of security access roles in LDAP/Kerberos/Sudo (not to mention automated service accounts that need to login to systems and perform various tasks). With regard to administration I can possibly see that someone would feel that creating an entire group for a hand full of sudoCommands is a waste, however, with a full enterprise running across many servers containing users that are managing their own pieces of software in systems administered by separate groups... Having to enter 20-30 commands for each sudo Role tends not to scale favorably for the administrator having to enter them. With regard to PCI-DSS auditing, we have found that when an auditor asks which users have X set of commands against Y servers, it is significantly easier to say which group of commands is aligned with which groups of users against which servers in the fleet. Vs... Having to perform a search in ldap for the particular strings that match the full path of the binary(s) that you are trying to account for. I am open to alternative technical solutions that can solve the management of massive sets of systems though, so if the alternative is viable I'd love to hear it! I completely agree with you but the main opponent of the idea is on vacation now. It will be unfair to revert in his absence without a majority. Can someone else express his opinion on the matter? ~hostMask~ I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. This will really be a relieve not to support it for now. Agreed, while Todd gave us a lot of flexibility by coding it to support subnets, even after working for an ISP that managed fortune 100 companies, I have yet to see anyone setup systems via subnet in such a way that you could segregate privilege escalation wisely. Sold! ~Using memberUser as slight of hand over netgroups~ It's my understanding that the sudo source does a getent netgroup style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... The problem is that it is reverse. Since for IPA the host groups are primary concepts and the netgroup is something we want to phase out the logic is the following: * Hosts are grouped into the host groups. * A netgroup is a shallow container around the host group. In our model host group can be a member of the netgroup not vice versa. But this is not related to the question at hand. The question regarding memberUser is that the sudo spec allows using a netgroup to refer to a set of users. This is really a atavism to use netgroups to reference a set of users instead of a direct user group. The question is: can we assume it to be an atavism and not support it. I updated the page so this point is more clear. Right, being that the netgroups can be setup to contain a dynamic object such as a hostgroup, you can continue adding and removing objects from the hostgroup and have the effects take place in the netgroup... in this way sudo can point to these netgroups as an interim means of bridging the gap until A: sudo can utilize sssd, and/or B: sudo adapts a more modern view of ldap management. I see the confusion... no, I am afraid Todd and his ilk are currently not motivated to allow for the use of anything but netgroups to define your hosts in this way. I have had long drawn out mailing list discussions with that crowd and I have come to the conclusion that I will eventually need to write the patch and submit it for the coup de grace against netgroups and sudo. We will cross this bridge when time
Re: [Freeipa-devel] Sudoers schema
Dmitri Pal wrote: JR Aquino wrote: That was the original design, however I was told that this is not something people will be interested in. Thanks for you data point but to change it we probably need couple more data points and comments. I would be very interested as to why there was resistance or a thought that people would not be interested in an design that scales. I welcome them to post the solutions that they have found in granularly managing several hundred users access to thousands of servers with mixed access rights spread out into dozens of security access roles in LDAP/Kerberos/Sudo (not to mention automated service accounts that need to login to systems and perform various tasks). With regard to administration I can possibly see that someone would feel that creating an entire group for a hand full of sudoCommands is a waste, however, with a full enterprise running across many servers containing users that are managing their own pieces of software in systems administered by separate groups... Having to enter 20-30 commands for each sudo Role tends not to scale favorably for the administrator having to enter them. With regard to PCI-DSS auditing, we have found that when an auditor asks which users have X set of commands against Y servers, it is significantly easier to say which group of commands is aligned with which groups of users against which servers in the fleet. Vs... Having to perform a search in ldap for the particular strings that match the full path of the binary(s) that you are trying to account for. I am open to alternative technical solutions that can solve the management of massive sets of systems though, so if the alternative is viable I'd love to hear it! I completely agree with you but the main opponent of the idea is on vacation now. It will be unfair to revert in his absence without a majority. Can someone else express his opinion on the matter? One was performance, memberOf isn't free. The second was complexity. Lets say you define command R and assign it to command groups A, B and C. The admin of group B needs to tweak the command a bit so he modifies R. This could have a negative impact on command groups A and C. So for simplicity he may make a command T instead. And the admins of groups A and C, having seem the problem of R changing make their own new commands as well. So now 3 (or 4) commands all do more or less the same thing. So the argument goes that for security and simplicity the admins will create their own rules every time they create an sudo rule (except perhaps in the initial config). rob ~hostMask~ I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. This will really be a relieve not to support it for now. Agreed, while Todd gave us a lot of flexibility by coding it to support subnets, even after working for an ISP that managed fortune 100 companies, I have yet to see anyone setup systems via subnet in such a way that you could segregate privilege escalation wisely. Sold! ~Using memberUser as slight of hand over netgroups~ It's my understanding that the sudo source does a getent netgroup style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... The problem is that it is reverse. Since for IPA the host groups are primary concepts and the netgroup is something we want to phase out the logic is the following: * Hosts are grouped into the host groups. * A netgroup is a shallow container around the host group. In our model host group can be a member of the netgroup not vice versa. But this is not related to the question at hand. The question regarding memberUser is that the sudo spec allows using a netgroup to refer to a set of users. This is really a atavism to use netgroups to reference a set of users instead of a direct user group. The question is: can we assume it to be an atavism and not support it. I updated the page so this point is more clear. Right, being that the netgroups can be setup to contain a dynamic object such as a hostgroup, you can continue adding and removing objects from the hostgroup and have the effects take
Re: [Freeipa-devel] Sudoers schema
One was performance, memberOf isn't free. The second was complexity. Lets say you define command R and assign it to command groups A, B and C. The admin of group B needs to tweak the command a bit so he modifies R. This could have a negative impact on command groups A and C. So for simplicity he may make a command T instead. And the admins of groups A and C, having seem the problem of R changing make their own new commands as well. So now 3 (or 4) commands all do more or less the same thing. So the argument goes that for security and simplicity the admins will create their own rules every time they create an sudo rule (except perhaps in the initial config). rob I understand the scenario presented, but that depiction doesn't sound like ROLE based authorization... That sounds more like administrative group based authorization... Privilege escalation configuration is serious business and I would hope that a responsible centralized entity inside an organization is managing these rules... I.E. Web-Developers may need to have sudo less, sudo grep, sudo netstat, sudo top and perhaps Application-Developers need sudo less, sudo netstat, sudo top, AND sudo custom_app.py... You wouldn't create 1 flat rule and assign it to both groups... you would create multiple groups and stack them as necessary. So perhaps web-dev's get sudo_rule_read_tools, and the app-devs get BOTH sudo_rule_read_tools AND sudo_rule_cust_apps. Roles should clearly define what rights users have within the infrastructure... if they need to be 'tweaked' to accommodate others, then we are talking about a completely different organizational role, one that should be documented and separate from similar roles. If the cost of memberO if too expensive perhaps we should be writing native sudoRole Objects and utilizing just the netgroup translation if compat and native ipa is too costly for sudoers to exist in a new format. We have an opportunity here to innovate and create something really new for the community rather than just gluing pieces of existing technology together. As it stands, it sounds like the Role Base Authorization as it applies to 'can I login' and 'can I run tcpdump' are being thought of as 2 disparately separate concepts/objects in the directory when in reality there are very much components of the larger idea of RBAC/HBAC... Lets continue down the rabbit hole, it feels important to get this stuff right! ~Measure twice, cut once~ -Jr ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudoers schema
JR Aquino wrote: One was performance, memberOf isn't free. The second was complexity. Lets say you define command R and assign it to command groups A, B and C. The admin of group B needs to tweak the command a bit so he modifies R. This could have a negative impact on command groups A and C. So for simplicity he may make a command T instead. And the admins of groups A and C, having seem the problem of R changing make their own new commands as well. So now 3 (or 4) commands all do more or less the same thing. So the argument goes that for security and simplicity the admins will create their own rules every time they create an sudo rule (except perhaps in the initial config). rob I understand the scenario presented, but that depiction doesn't sound like ROLE based authorization... That sounds more like administrative group based authorization... Privilege escalation configuration is serious business and I would hope that a responsible centralized entity inside an organization is managing these rules... I.E. Web-Developers may need to have sudo less, sudo grep, sudo netstat, sudo top and perhaps Application-Developers need sudo less, sudo netstat, sudo top, AND sudo custom_app.py... You wouldn't create 1 flat rule and assign it to both groups... you would create multiple groups and stack them as necessary. So perhaps web-dev's get sudo_rule_read_tools, and the app-devs get BOTH sudo_rule_read_tools AND sudo_rule_cust_apps. Roles should clearly define what rights users have within the infrastructure... if they need to be 'tweaked' to accommodate others, then we are talking about a completely different organizational role, one that should be documented and separate from similar roles. If the cost of memberO if too expensive perhaps we should be writing native sudoRole Objects and utilizing just the netgroup translation if compat and native ipa is too costly for sudoers to exist in a new format. We have an opportunity here to innovate and create something really new for the community rather than just gluing pieces of existing technology together. As it stands, it sounds like the Role Base Authorization as it applies to 'can I login' and 'can I run tcpdump' are being thought of as 2 disparately separate concepts/objects in the directory when in reality there are very much components of the larger idea of RBAC/HBAC... Lets continue down the rabbit hole, it feels important to get this stuff right! ~Measure twice, cut once~ That was my vision too this is why I suggested the grouping of the commands in the first place. I actually agree will all your points since they were mine also. But I am not sure how to proceed with this. I am leaving for vacation for couple weeks on Tuesday I will try to update the page with the alternative suggestion and schema but final decision will probably be done when everybody is back. -Jr ___ 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/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Sudoers schema
JR Aquino wrote: ~ipaSudoComand~ I'd like to know what the group thinks about the possibility of using ipaSudoComand as a DN to an object containing sudoCommand attributes, rather than just being a static attribute itself. I believe this is already being done/suggested in a similar manor with memberUser and memberHost. We found here at Citrix Online that the Role's tend to reuse all 3 elements pretty heavily: userGroups, hostGroups, and commandGroups. For PCI-DSS reasons, it tends to make it a lot easier to say: These groups of users have login rights to these groups of hosts, and are permitted to sudo these groups of commands. Rather then having to search for individual attribute entries in the role objects themselves. That was the original design, however I was told that this is not something people will be interested in. Thanks for you data point but to change it we probably need couple more data points and comments. ~hostMask~ I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. This will really be a relieve not to support it for now. ~Using memberUser as slight of hand over netgroups~ It's my understanding that the sudo source does a getent netgroup style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... The problem is that it is reverse. Since for IPA the host groups are primary concepts and the netgroup is something we want to phase out the logic is the following: * Hosts are grouped into the host groups. * A netgroup is a shallow container around the host group. In our model host group can be a member of the netgroup not vice versa. But this is not related to the question at hand. The question regarding memberUser is that the sudo spec allows using a netgroup to refer to a set of users. This is really a atavism to use netgroups to reference a set of users instead of a direct user group. The question is: can we assume it to be an atavism and not support it. I updated the page so this point is more clear. ~users by uid and gid~ If by uid/gid he means numerical representation, Yes this is number vs. string question. then I say, I wouldn't worry about it. Fully spelled out alpha Username / Group entries seem sane. Good! ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 6500 Hollister Avenue | Goleta, CA 93117 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Thank you for the comment. I think the only missing point is about negating the whole rule instead of per command. Do you agree that it would be more manageable as proposed? -- 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] Sudoers schema
That was the original design, however I was told that this is not something people will be interested in. Thanks for you data point but to change it we probably need couple more data points and comments. I would be very interested as to why there was resistance or a thought that people would not be interested in an design that scales. I welcome them to post the solutions that they have found in granularly managing several hundred users access to thousands of servers with mixed access rights spread out into dozens of security access roles in LDAP/Kerberos/Sudo (not to mention automated service accounts that need to login to systems and perform various tasks). With regard to administration I can possibly see that someone would feel that creating an entire group for a hand full of sudoCommands is a waste, however, with a full enterprise running across many servers containing users that are managing their own pieces of software in systems administered by separate groups... Having to enter 20-30 commands for each sudo Role tends not to scale favorably for the administrator having to enter them. With regard to PCI-DSS auditing, we have found that when an auditor asks which users have X set of commands against Y servers, it is significantly easier to say which group of commands is aligned with which groups of users against which servers in the fleet. Vs... Having to perform a search in ldap for the particular strings that match the full path of the binary(s) that you are trying to account for. I am open to alternative technical solutions that can solve the management of massive sets of systems though, so if the alternative is viable I'd love to hear it! ~hostMask~ I feel inclined to agree with Dmitri regarding a deferral on the hostMask attribute for resource sake. I tend to see the data center design to stick closer to hostname utilization, rather than subnets... I.E. people tend to put a mixed bag of servers in the same subnet, but they tend to make sure that like servers have similar hostnames or sane hostnames that can have a floating IP address in the case of clusering, or high-availability, etc, etc. That is just my observation. Feel free to correct me if I am grossly out of spec for the rest of the industry. This will really be a relieve not to support it for now. Agreed, while Todd gave us a lot of flexibility by coding it to support subnets, even after working for an ISP that managed fortune 100 companies, I have yet to see anyone setup systems via subnet in such a way that you could segregate privilege escalation wisely. ~Using memberUser as slight of hand over netgroups~ It's my understanding that the sudo source does a getent netgroup style of lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary to utilize the compat function to share the hostgroups with sudo... The overall goal, again, being to eliminate duplication of info: prod-servers hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the same manually duplicated servers as prod-servers netgroup... The problem is that it is reverse. Since for IPA the host groups are primary concepts and the netgroup is something we want to phase out the logic is the following: * Hosts are grouped into the host groups. * A netgroup is a shallow container around the host group. In our model host group can be a member of the netgroup not vice versa. But this is not related to the question at hand. The question regarding memberUser is that the sudo spec allows using a netgroup to refer to a set of users. This is really a atavism to use netgroups to reference a set of users instead of a direct user group. The question is: can we assume it to be an atavism and not support it. I updated the page so this point is more clear. Right, being that the netgroups can be setup to contain a dynamic object such as a hostgroup, you can continue adding and removing objects from the hostgroup and have the effects take place in the netgroup... in this way sudo can point to these netgroups as an interim means of bridging the gap until A: sudo can utilize sssd, and/or B: sudo adapts a more modern view of ldap management. I see the confusion... no, I am afraid Todd and his ilk are currently not motivated to allow for the use of anything but netgroups to define your hosts in this way. I have had long drawn out mailing list discussions with that crowd and I have come to the conclusion that I will eventually need to write the patch and submit it for the coup de grace against netgroups and sudo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
