[Freeipa-devel] Sudoers schema

Wed Aug 4 15:09:28 UTC 2010

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 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 comes. We have some thoughts and
> considerations.
> 
> 
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>>
>>   
> 
> 