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] [PATCH] 451 fix i18n test
On 05/27/2010 10:29 AM, Pavel Zuna wrote: On 05/21/2010 11:35 PM, Rob Crittenden wrote: Fix this test to work from source tree root It would work if you ran the test from its location in tests/test_ipalib but this isn't the most common method. If you want to run it individually you can do: $ ./make-test tests/test_ipalib/test_text.py rob Maybe I'm doing something wrong, but I'm still getting this one error: == ERROR: Test gettext translation -- Traceback (most recent call last): File /usr/lib/python2.6/site-packages/nose/case.py, line 183, in runTest self.test(*self.arg) File /root/freeipa/tests/test_ipalib/test_text.py, line 89, in test_gettext msgid = get_msgid(test_file) File /root/freeipa/tests/test_ipalib/test_text.py, line 43, in get_msgid f = open(po_file) IOError: [Errno 2] No such file or directory: 'install/po/test.po' Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services
On 07/30/2010 04:02 PM, Adam Young wrote: On 07/22/2010 02:25 PM, Rob Crittenden wrote: Make sure that the host behind new host and service records is actually a resolvable DNS A record. There is a --force flag if you know what you are doing (or just feel like charging ahead anyway). We use a lot of made-up names in the self-tests, had to add the force flag to all of them. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I can't get this patch to apply: [ayo...@ayoung freeipa]$ git apply ~/Documents/IPA/freeipa-490-dns.patch error: patch failed: ipalib/util.py:28 error: ipalib/util.py: patch does not apply I've tried it both with and without patch 484 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel OK, disregard that, I was able to apply it on top of 484, build and deploy. I'd give it an ACK except that I can't figure out how to work around service-add where the service is not yet resolvable. I understand that this is not desired, but I'm fairly certain that not being able to do this will mess up someone. ipa service-add-host --force --hosts=web.example.com HTTP/web.example.com Usage: ipa [global-options] service-add-host PRINCIPAL ipa: error: no such option: --force ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 492 fix env plugin
On 07/26/2010 06:00 PM, Rob Crittenden wrote: The env plugin was displaying just the number of entries in the environment, not the values. Add an --all flag to print those, on by default. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK ___ 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] [PATCH] 493 skip lang test if not built
On 07/26/2010 06:01 PM, Rob Crittenden wrote: The i18n tests were failing if the language wasn't built. Skip it in this case and inform the user what to run to get the test to execute. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Can't quite ACK yet. While this change does what it says, If I do: pushd install/po/ make test_lang And then re-run the test, I get the same test skipped: Test gettext translation ... SKIP: Test language not available, run make test_lang in install/po ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 490 add DNS lookup to new hosts/services
Adam Young wrote: On 07/30/2010 04:02 PM, Adam Young wrote: On 07/22/2010 02:25 PM, Rob Crittenden wrote: Make sure that the host behind new host and service records is actually a resolvable DNS A record. There is a --force flag if you know what you are doing (or just feel like charging ahead anyway). We use a lot of made-up names in the self-tests, had to add the force flag to all of them. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I can't get this patch to apply: [ayo...@ayoung freeipa]$ git apply ~/Documents/IPA/freeipa-490-dns.patch error: patch failed: ipalib/util.py:28 error: ipalib/util.py: patch does not apply I've tried it both with and without patch 484 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel OK, disregard that, I was able to apply it on top of 484, build and deploy. I'd give it an ACK except that I can't figure out how to work around service-add where the service is not yet resolvable. I understand that this is not desired, but I'm fairly certain that not being able to do this will mess up someone. ipa service-add-host --force --hosts=web.example.com HTTP/web.example.com Usage: ipa [global-options] service-add-host PRINCIPAL ipa: error: no such option: --force The --force should be an option. And if it does not resolve but internal DNS is used then there should be an option to add it to the DNS. So I guess the logic should be: 1) No options and the host resolves - success 2) No options and the host does not resolve - failure 3) --force is specified and the host resolves - success (force is ignored) 4) --force is specified and the host does not resolve - host is added as is 5) --dns is specified but we do not use internal DNS - failure invalid parameter 6) --dns is specified and we use internal DNS and the host resolves - host is added to the hosts and host is not added to dns since it is already there 7) --dns is specified and we use internal DNS and the host does not resolve - host is added to the hosts and to dns NACK for now. ___ 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
