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
