[Freeipa-devel] Sudoers schema

[Dmitri Pal]

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 at 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/