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 condition.
>
> 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 access 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 
>
> http://osdir.com/ml/freeipa-users/2013-03/msg00218.html
>
> where geographically separate Organization units may share the same
> directory 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:
https://fedorahosted.org/freeipa/ticket/217
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
tickets?

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

Thanks
Dmitri

>
> Thanks
> Chandan
>
>
> On Monday, April 15, 2013, Dmitri Pal wrote:
>
>     On 04/15/2013 11:11 AM, Chandan Kumar wrote:
>>
>>     I think controlling Visibility of tabs would be the best option,
>>     if possible, based on Roles as mentioned by Rob. As long as other
>>     entries are not visible in UI, even though they have read only
>>     access with command line, should be enough.
>>
>
>     It would not be a security feature though. Just a convenience
>     because the same admin would be able to bind directly to ldap and
>     run a search. This is why we did not go this route. Yes we can
>     hide panels but it would not mean that the user can't easily get
>     that info. So is there really a value in hiding? So far we did not
>     see any this is why we did not do it, but may be you have some
>     arguments that might convince us that we are wrong. Can you please
>     share these arguments with us? 
>
>>
>>     On Monday, April 15, 2013, Alexander Bokovoy wrote:
>>
>>         On Mon, 15 Apr 2013, Petr Spacek wrote:
>>
>>             On 15.4.2013 15:39, Rob Crittenden wrote:
>>
>>                 There is no easy way to do this. We start with
>>                 granting all authenticated
>>                 users read access to the tree with the exception of
>>                 certain attributes (like
>>                 passwords).
>>
>>                 You'd have to start by removing that, then one by one
>>                 granting read access to
>>                 the various containers based on, well, something.
>>
>>
>>             Would it be possible to create a new role to allow
>>             current 'read-all access' and add this role to all users
>>             by default?
>>
>>             It could be much simpler to change the behaviour with
>>             this role, or not? :-)
>>
>>         It would affect service accounts (include host/fqdn@REALM)
>>         since roles
>>         cannot be applied to them, if I remember correctly. We would
>>         need to
>>         make an exclusive ACI that allows all services to gain read
>>         only access...
>>
>>         -- 
>>         / Alexander Bokovoy
>>
>>         _______________________________________________
>>         Freeipa-users mailing list
>>         Freeipa-users@redhat.com
>>         https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>>     -- 
>>
>>     --
>>     http://about.me/chandank
>>
>>
>>
>>     _______________________________________________
>>     Freeipa-users mailing list
>>     Freeipa-users@redhat.com
>>     https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>     -- 
>     Thank you,
>     Dmitri Pal
>
>     Sr. Engineering Manager for IdM portfolio
>     Red Hat Inc.
>
>
>     -------------------------------
>     Looking to carve out IT costs?
>     www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>
> -- 
>
> --
> http://about.me/chandank
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to