> 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 

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 

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~


Freeipa-devel mailing list

Reply via email to