On 04/16/2013 03:38 AM, Martin Kosek wrote:
> On 04/16/2013 03:16 AM, Dmitri Pal wrote:
>> On 04/15/2013 07:42 PM, Chandan Kumar wrote:
>>> I agree it won't be a security feature nor you are doing wrong by not adding
>>> it. However, it might come as nice to have feature. Let me explain you my
>>> We host web application where lot of DNS entries (Public and Internal) are
>>> created for different kind of requests and features. Now we already have a
>>> separate DNS server, Separate Manual Linux User/Access Control management by
>>> puppet. Linux users ACL have no relationship with the web application user
>>> (which is internal to the web app).
>>> So FreeIPA can help me to centralize the Linux user-management as well as
>>> (Public and Internal) DNS. However, the problem is : traditionally the
>>> levels were different for DNS users (support guys) and user management
>>> (sysadmins). Now bring both system together even the Host based access
>>> control, sudoers rule everything becomes visible to non-sysadmin group.
>>> You are right that every user could query all entries from command line and
>>> hence it won't help to secure the system, but not having it on GUI may help
>>> to avoid "obvious" visibility of the whole directory.
>>> I believe similar GUI "views" could be applied for discussion
>>> where geographically separate Organization units may share the same
>>> with limited visibility on other branches.
>>> Having said that, I am not sure how feasible/logical my view is owing to my
>>> limited knowledge in 389 directory server and IPA.
>> I think you are talking about this:
>> and somewhat about this https://fedorahosted.org/freeipa/ticket/1313
>> Would you mind adding the details of your use case to one of those two
>> Alternatively we can start another ticket.
>> However I think we should have some kind of a complete solution that covers
>> LDAP, UI and CLI consistently.
>> Doing it right would be a huge task IMO.
>> For LDAP we would probably have to implement some kind of "smart" proxy that
>> would reply only to the requests that user are entitled to. Same with CLI and
>> UI. But the point is that one configuration should be respected by all three
>> the same time. For example if you are not allowed to manage sudo the sudo
>> commands should not return any data as well as LDAP searches and there should
>> be no panel in the UI.
>> I am really reluctant to fix just UI because we would end up different
>> components of the system behaving differently and it would be hard to evolve
>> them and maintain.
> I think there were some related discussions about this. I agree that this a
> bigger effort, but I do think that a proxy is needed. We should be able to
> achieve that goal by being able to disable global ACI allowing read access to
> all entries and attributes unless those explicitly blacklisted.
> I think we are talking about this ticket:
Actually no. I see it on a much broader scale than in this ticket.
I am thinking about blacklisting components like: sudo, hbac, selinux,
DNS, hosts, users, services etc.
Have a way to completely hide those areas from the user.
It would get pretty complex right away as the dependencies are hierarchical.
> If there is a solid use case for this ticket (and it seems it is), we can
> increase its priority. In order to be able to manage such access also for
> system accounts (like sudo for example when SSSD is not used), we may want to
> also add API to manage such accounts and control their access too:
And I do not think it is about system accounts. It is about different
flavors of the admin accounts.
It is another dimension of the access control - ability to scope the
actual data that gets exposed to someone.
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list