Re: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object
On Thu, Mar 27, 2014 at 01:14:52PM +0100, Tomas Babej wrote:
> Hi,
>
> When cleaning the range_info struct, simple free of the struct
> is not enough, we have to free contents of char pointers in the
> struct as well.
>
> https://fedorahosted.org/freeipa/ticket/4276
[...]
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
> b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
> index
> 0ef33e5869bbcb4f721394ce35e2338095bf5d36..c877a7dc445b31b3de085aa66028d7652df6b9cc
> 100644
> --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
> +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
> @@ -96,6 +96,15 @@ struct domain_info {
> struct domain_info *next;
> };
>
> +static void free_range_info(struct range_info *range) {
> +if (range != NULL) {
> +slapi_ch_free_string(&(range->name));
> +slapi_ch_free_string(&(range->domain_id));
> +slapi_ch_free_string(&(range->forest_root_id));
> +slapi_ch_free_string(&(range->id_range_type));
> +free(range);
> +}
> +}
In master, the range_info is
struct range_info {
char *name;
char *domain_id;
uint32_t base_id;
uint32_t id_range_size;
uint32_t base_rid;
uint32_t secondary_base_rid;
};
-- no forest_root_id and no id_range_type.
So NACK for applying to master. Perhaps there is some dependency
patch?
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 584 migration: fix import of wsgiref.util
https://fedorahosted.org/freeipa/ticket/4293
--
Petr Vobornik
From dc4eaf9d622b4eac9fb3d942b23083bfb903be9a Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Tue, 1 Apr 2014 08:45:08 +0200
Subject: [PATCH] migration: fix import of wsgiref.util
https://fedorahosted.org/freeipa/ticket/4293
---
install/migration/migration.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/install/migration/migration.py b/install/migration/migration.py
index 27e23a59f660c791c12948b4c40406d03b0f0966..acc1ee48dd8744f6abd2d7a59f0d5feb54fc93f9 100644
--- a/install/migration/migration.py
+++ b/install/migration/migration.py
@@ -23,7 +23,7 @@ Password migration script
import cgi
import errno
import glob
-import wsgiref
+from wsgiref.util import request_uri
from ipapython.ipa_log_manager import root_logger
from ipapython.ipautil import get_ipa_basedn
@@ -37,7 +37,7 @@ def wsgi_redirect(start_response, loc):
return []
def get_ui_url(environ):
-full_url = wsgiref.util.request_uri(environ)
+full_url = request_uri(environ)
index = full_url.rfind(environ.get('SCRIPT_NAME',''))
if index == -1:
raise ValueError('Cannot strip the script URL from full URL "%s"' % full_url)
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Read access to container entries
On Mon, 2014-03-31 at 15:39 +0200, Martin Kosek wrote: > On 03/31/2014 02:53 PM, Simo Sorce wrote: > > On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote: > ... > >>> 3) Add a special attribute to mark "public" containers, and add an ACI > >>> with a filter on that. Something like objectClass=ipaPublicContainer > >>> would do. > >> there is one more option > >> 4) add an allow aci for cn=accounts,$S and a deny aci for > >> cn=*,cn=accounts,$S or uid=*,cn=accounts,$S > > > > We want to get rid of deny ACIs if at all possible. > > > >> In general I think we should implement 1), there will be other scenarios > >> where it could be useful. If something is needed imemdiately I would > >> also prefer 3) > > > > I wonder, can we have an objectclass that defines no attributes ? > > Or do we always need to have a MAY at least ? > > This particular objectclass could have just one MUST attribute - cn. Similarly > to what nsContainer has. > > > Anyway I agree that the simplest solution would be to have an > > objectclass to filter on. > > > > But I see 2 options. > > 1. objectClass=ipaPublicContainer > > 2. objectClass=ipaPrivateContainer > > > > The problem with the second is adding a > > (!(objectclass=ipaPrivateContainer)) everywhere ... > > > > I already elaborated on that topic later in this thread, please check it. It > also includes an attached list of container we already have. IMO most of > containers we have will be public, rather than private as LDAP nsContainer's > cn > attribute is semantically not meant to contain secrets we want to hide. > > So instead of adding 61 ipaPublicContainer everywhere I would just allow > reading nsContainers (cn+objectclass) anonymously + have ipaPrivateContainer > available in case we need it (I am not aware of any such case though). Yeah sorry, I replied in order. I agree with your proposal of allowing (objectclass=nsContainer) and a targetfilter that simply excludes the cn=etc subtree. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Review section on NetworkManager
On 03/27/2014 11:27 AM, Jan Pazdziora wrote: > On Wed, Mar 26, 2014 at 05:30:13PM -0600, Gabe Alford wrote: >> All, >> >> Please review this patch for https://fedorahosted.org/freeipa/ticket/4156 >> Added links to documentation on configuring NetworkManager. > > Thank you for the patch. > > ACK. > Thanks to both! Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Read access to container entries
On 03/31/2014 02:53 PM, Simo Sorce wrote: > On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote: ... >>> 3) Add a special attribute to mark "public" containers, and add an ACI >>> with a filter on that. Something like objectClass=ipaPublicContainer >>> would do. >> there is one more option >> 4) add an allow aci for cn=accounts,$S and a deny aci for >> cn=*,cn=accounts,$S or uid=*,cn=accounts,$S > > We want to get rid of deny ACIs if at all possible. > >> In general I think we should implement 1), there will be other scenarios >> where it could be useful. If something is needed imemdiately I would >> also prefer 3) > > I wonder, can we have an objectclass that defines no attributes ? > Or do we always need to have a MAY at least ? This particular objectclass could have just one MUST attribute - cn. Similarly to what nsContainer has. > Anyway I agree that the simplest solution would be to have an > objectclass to filter on. > > But I see 2 options. > 1. objectClass=ipaPublicContainer > 2. objectClass=ipaPrivateContainer > > The problem with the second is adding a > (!(objectclass=ipaPrivateContainer)) everywhere ... > I already elaborated on that topic later in this thread, please check it. It also includes an attached list of container we already have. IMO most of containers we have will be public, rather than private as LDAP nsContainer's cn attribute is semantically not meant to contain secrets we want to hide. So instead of adding 61 ipaPublicContainer everywhere I would just allow reading nsContainers (cn+objectclass) anonymously + have ipaPrivateContainer available in case we need it (I am not aware of any such case though). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP ACI testing
On 03/31/2014 03:23 PM, Rob Crittenden wrote: > Petr Spacek wrote: >> Hello list, >> >> thread "[Freeipa-devel] Read access to container entries" reminds me an >> idea I have in mind for a while: >> >> We could check effective ACIs [1] for interesting objects (Kerberos >> master key, trust objects etc.) and make sure that there is nothing like >> 'read by anonymous' etc. >> >> Method [1] has one important limitation: It checks ACI in given sub-tree >> against one specified DN. >> >> Realization of my idea would be better with a "reverse" approach: >> Specify DN of a single object as "target" and get list of all users with >> non-null access rights for the object in question. (This could be >> refined with filter for specific rights so we can get "list of DNs >> allowed to write to this object" etc.) >> >> >> Does it make sense? >> >> >> >> [1] >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html >> > > Maybe. We've had a long-term need to run the unit tests as various other users > to avoid delegation regressions. We really should have some subset of tests to > do positive and negative testing of each role. We'd probably want to do these > tests directly with the framework. > > Ideally this could be extended to disabling anonymous access, setting minimum > SSF, etc. This could probably be mostly done using GER. > > rob FYI - we have a ticket already open to do something like what Petr says: https://fedorahosted.org/freeipa/ticket/4035 IMO it is a good thing to do. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Read access to container entries
On 03/31/2014 03:23 PM, Martin Kosek wrote: On 03/31/2014 01:52 PM, Ludwig Krispenz wrote: On 03/31/2014 12:32 PM, Martin Kosek wrote: On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: ... In general I think we should implement 1), there will be other scenarios where it could be useful. If something is needed imemdiately I would also prefer 3) We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature is not an option unless it'd be done really fast. how fast does it have to be ? If we just can use the same concept with targetscope=[base,one,sub] implementation should not take too much time, about a week or so, but we need to get it accepted by DS core. As fast as a light :-) A week should be sufficient, though I am not convinced that we are able to release that fast or that rushing ACI related implementation is a good thing to do. :-) and I am no longer sure if it would be the best way to go since there seem to be may containers you want to apply this and with targetscope=base you would hav eto add the aci to any container you want to control Question is if we want to go this way (adding ACI for all containers) or the second way having ACI(s) for all containers in the tree described below. if you don't see any problems giving access to too many containers I think the combination of your suggestion (target != "ldap:///cn=etc,SUFFIX";)(targetfilter= ...) is the best. The question is, do you want to use an existing attribute,value pair for the filter or add something unique to the entries you target. In that case you would have to edit the entries and the filter would be enough Given Petr's findings, I am thinking that solution based on 3) seems like way to go. We would of course only allow objectclass + cn attributes. I am not convinced that objectclass like ipaPublicContainer is the right way to go, does not sound to me as a standard solution and not something that people would assume they need to do when they are adding a custom container. When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results attached) and there were 61 results. Do we really want to update 61 LDAP entries and add a custom ipaPublicContainer objectclass to all? Sounds a little bit hackish to me. Would adding following ACIs work? dn: SUFFIX aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; except cn=etc,SUFFIX how do you want to specify the "except" ? (target != "ldap:///cn=etc,SUFFIX";) dn: cn=etc,SUFFIX aci: allow authenticated read for "(objectclass=nsContainer)" for cn, objectclass As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is something we agreed on during DevConf. With this approach, the only question is what should we do with nsContainer based LDAP entries that contains sensitive information. I wonder - is this a real situation? Are there many nsContainer LDAP entries with sensitive information? Shouldn't we have a rule instead that would recommend using custom (not nsContainer) objectclasses to store sensitive information based on cn? Otherwise it seems to me a an abuse of nsContainer purpose. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP ACI testing
Petr Spacek wrote: Hello list, thread "[Freeipa-devel] Read access to container entries" reminds me an idea I have in mind for a while: We could check effective ACIs [1] for interesting objects (Kerberos master key, trust objects etc.) and make sure that there is nothing like 'read by anonymous' etc. Method [1] has one important limitation: It checks ACI in given sub-tree against one specified DN. Realization of my idea would be better with a "reverse" approach: Specify DN of a single object as "target" and get list of all users with non-null access rights for the object in question. (This could be refined with filter for specific rights so we can get "list of DNs allowed to write to this object" etc.) Does it make sense? [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html Maybe. We've had a long-term need to run the unit tests as various other users to avoid delegation regressions. We really should have some subset of tests to do positive and negative testing of each role. We'd probably want to do these tests directly with the framework. Ideally this could be extended to disabling anonymous access, setting minimum SSF, etc. This could probably be mostly done using GER. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Read access to container entries
On 03/31/2014 01:52 PM, Ludwig Krispenz wrote: > > On 03/31/2014 12:32 PM, Martin Kosek wrote: >> On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: ... >>> In general I think we should implement 1), there will be other scenarios >>> where >>> it could be useful. If something is needed imemdiately I would also prefer >>> 3) >> We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 >> feature >> is not an option unless it'd be done really fast. > how fast does it have to be ? If we just can use the same concept with > targetscope=[base,one,sub] > implementation should not take too much time, about a week or so, but we need > to get it accepted by > DS core. As fast as a light :-) A week should be sufficient, though I am not convinced that we are able to release that fast or that rushing ACI related implementation is a good thing to do. Question is if we want to go this way (adding ACI for all containers) or the second way having ACI(s) for all containers in the tree described below. > >> >> Given Petr's findings, I am thinking that solution based on 3) seems like way >> to go. We would of course only allow objectclass + cn attributes. I am not >> convinced that objectclass like ipaPublicContainer is the right way to go, >> does >> not sound to me as a standard solution and not something that people would >> assume they need to do when they are adding a custom container. >> >> When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results >> attached) and there were 61 results. Do we really want to update 61 LDAP >> entries and add a custom ipaPublicContainer objectclass to all? Sounds a >> little >> bit hackish to me. >> >> Would adding following ACIs work? >> >> dn: SUFFIX >> aci: allow anonymous read for "(objectclass=nsContainer)" for cn, >> objectclass; >> except cn=etc,SUFFIX > how do you want to specify the "except" ? (target != "ldap:///cn=etc,SUFFIX";) >> dn: cn=etc,SUFFIX >> aci: allow authenticated read for "(objectclass=nsContainer)" for cn, >> objectclass >> >> As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is >> something we agreed on during DevConf. >> >> With this approach, the only question is what should we do with nsContainer >> based LDAP entries that contains sensitive information. I wonder - is this a >> real situation? Are there many nsContainer LDAP entries with sensitive >> information? Shouldn't we have a rule instead that would recommend using >> custom >> (not nsContainer) objectclasses to store sensitive information based on cn? >> Otherwise it seems to me a an abuse of nsContainer purpose. >> >> Martin > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP ACI testing
On 03/31/2014 02:59 PM, Petr Spacek wrote: Hello list, thread "[Freeipa-devel] Read access to container entries" reminds me an idea I have in mind for a while: We could check effective ACIs [1] for interesting objects (Kerberos master key, trust objects etc.) and make sure that there is nothing like 'read by anonymous' etc. Method [1] has one important limitation: It checks ACI in given sub-tree against one specified DN. Realization of my idea would be better with a "reverse" approach: Specify DN of a single object as "target" and get list of all users with non-null access rights for the object in question. (This could be refined with filter for specific rights so we can get "list of DNs allowed to write to this object" etc.) Does it make sense? yes, I think it would be a "nice to have" feature, but ... I think it will be quit ecomplex to implement and you could get very large result sets, eg all users. In geteffectiverigths you more or less do the normal aci evaluation for a given bind dn, but in your request you ask for all dns which could match teh bind rules and this could be complicated in case of bind rules depneding on attributes of the entry and the bind rule eg in a userattr rule, so you would have to look at every entyr and check if the userattr matches. In rules with groupdns we need to find all direct or indirect group members and for macro acis the expansion to all dns matchng the macro could also get complicated [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] LDAP ACI testing
Hello list, thread "[Freeipa-devel] Read access to container entries" reminds me an idea I have in mind for a while: We could check effective ACIs [1] for interesting objects (Kerberos master key, trust objects etc.) and make sure that there is nothing like 'read by anonymous' etc. Method [1] has one important limitation: It checks ACI in given sub-tree against one specified DN. Realization of my idea would be better with a "reverse" approach: Specify DN of a single object as "target" and get list of all users with non-null access rights for the object in question. (This could be refined with filter for specific rights so we can get "list of DNs allowed to write to this object" etc.) Does it make sense? [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Read access to container entries
On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote: > Hi Petr, > > we already discussed on IRC, but see some comments below > On 03/28/2014 04:11 PM, Petr Viktorin wrote: > > Hello, > > I'm trying to add ACIs to allow read access to containers, and I need > > some input. > > > > The DS's access control system is not designed to allow access to a > > single entry but not its descendants. The [ACI documentation] suggests > > some ways to work around it. > > > > This doesn't work that well for read access in IPA: > > > > $SUFFIX needs anonymous read access; ipa-client-install looks for > > "info=IPA V2.0" anonymously. > > cn=accounts,$SUFFIX needs read access if it or any of its children are > > to be listed in a GUI > > cn=users,cn=accounts,$SUFFIX needs read access if it or any users are > > to be listed in a GUI > > uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied > > > > It's safe to expose IPA's default containers anonymously; all they > > tell the user is that they're looking an IPA server. > > > > The container entries themselves just have cn and an objectClass of > > cnContainer, so it's impossible to construct a general targetfilter > > that targets them but not any possible descendants. > > > > I see 3 possible solutions: > > 1) File a DS RFE to implement [targetscope]. With that we could have > > ACIs that only target a single entry, so admins could manage read > > access to containers in the usual way (with permissions). > > 2) Add a (objectClass=nsContainer) filter. The problem here is that if > > this is on cn=accounts,$S, it would also affect e.g. > > cn=users,cn=accounts,$S, and other nsContainers under it. For example, > > cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. Re-reading this I am not sure I understand the example, the filter wouldn't apply to masters as they are under cn=etc not cn=accounts I guess you meant that if we set the permission on the root in order to see accounts that we also show masters and other parts of the tree? (like hbac and sudo .. > > 3) Add a special attribute to mark "public" containers, and add an ACI > > with a filter on that. Something like objectClass=ipaPublicContainer > > would do. > there is one more option > 4) add an allow aci for cn=accounts,$S and a deny aci for > cn=*,cn=accounts,$S or uid=*,cn=accounts,$S We want to get rid of deny ACIs if at all possible. > In general I think we should implement 1), there will be other scenarios > where it could be useful. If something is needed imemdiately I would > also prefer 3) I wonder, can we have an objectclass that defines no attributes ? Or do we always need to have a MAY at least ? Anyway I agree that the simplest solution would be to have an objectclass to filter on. But I see 2 options. 1. objectClass=ipaPublicContainer 2. objectClass=ipaPrivateContainer The problem with the second is adding a (!(objectclass=ipaPrivateContainer)) everywhere ... > > > > > > I'm thinking about 3, but I'd like to ask an LDAP expert for opinions. > > > > > > Note that children can be accessible even if the parent isn't. This > > whole container business only affects exploring the DIT with a GUI-ish > > tool. > > > -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Read access to container entries
On 03/31/2014 12:32 PM, Martin Kosek wrote: On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: Hi Petr, we already discussed on IRC, but see some comments below On 03/28/2014 04:11 PM, Petr Viktorin wrote: Hello, I'm trying to add ACIs to allow read access to containers, and I need some input. The DS's access control system is not designed to allow access to a single entry but not its descendants. The [ACI documentation] suggests some ways to work around it. This doesn't work that well for read access in IPA: $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA V2.0" anonymously. cn=accounts,$SUFFIX needs read access if it or any of its children are to be listed in a GUI cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be listed in a GUI uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied It's safe to expose IPA's default containers anonymously; all they tell the user is that they're looking an IPA server. The container entries themselves just have cn and an objectClass of cnContainer, so it's impossible to construct a general targetfilter that targets them but not any possible descendants. I see 3 possible solutions: 1) File a DS RFE to implement [targetscope]. With that we could have ACIs that only target a single entry, so admins could manage read access to containers in the usual way (with permissions). 2) Add a (objectClass=nsContainer) filter. The problem here is that if this is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and other nsContainers under it. For example, cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. 3) Add a special attribute to mark "public" containers, and add an ACI with a filter on that. Something like objectClass=ipaPublicContainer would do. there is one more option 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S or uid=*,cn=accounts,$S In the past, we tried hard to avoid deny acis and I think we should keep it this way. deny ACI is just a hard stop that cannot be overriden by any other ACI. If possible, I would prefer to only add allow ACIs. I agree, in my opinion the access restriction is much clearer if only allow is used In general I think we should implement 1), there will be other scenarios where it could be useful. If something is needed imemdiately I would also prefer 3) We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature is not an option unless it'd be done really fast. how fast does it have to be ? If we just can use the same concept with targetscope=[base,one,sub] implementation should not take too much time, about a week or so, but we need to get it accepted by DS core. Given Petr's findings, I am thinking that solution based on 3) seems like way to go. We would of course only allow objectclass + cn attributes. I am not convinced that objectclass like ipaPublicContainer is the right way to go, does not sound to me as a standard solution and not something that people would assume they need to do when they are adding a custom container. When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results attached) and there were 61 results. Do we really want to update 61 LDAP entries and add a custom ipaPublicContainer objectclass to all? Sounds a little bit hackish to me. Would adding following ACIs work? dn: SUFFIX aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; except cn=etc,SUFFIX how do you want to specify the "except" ? dn: cn=etc,SUFFIX aci: allow authenticated read for "(objectclass=nsContainer)" for cn, objectclass As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is something we agreed on during DevConf. With this approach, the only question is what should we do with nsContainer based LDAP entries that contains sensitive information. I wonder - is this a real situation? Are there many nsContainer LDAP entries with sensitive information? Shouldn't we have a rule instead that would recommend using custom (not nsContainer) objectclasses to store sensitive information based on cn? Otherwise it seems to me a an abuse of nsContainer purpose. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Read access to container entries
On 03/31/2014 12:52 PM, Alexander Bokovoy wrote: > On Mon, 31 Mar 2014, Martin Kosek wrote: >> On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: >>> Hi Petr, >>> >>> we already discussed on IRC, but see some comments below >>> On 03/28/2014 04:11 PM, Petr Viktorin wrote: Hello, I'm trying to add ACIs to allow read access to containers, and I need some input. The DS's access control system is not designed to allow access to a single entry but not its descendants. The [ACI documentation] suggests some ways to work around it. This doesn't work that well for read access in IPA: $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA V2.0" anonymously. cn=accounts,$SUFFIX needs read access if it or any of its children are to be listed in a GUI cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be listed in a GUI uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied It's safe to expose IPA's default containers anonymously; all they tell the user is that they're looking an IPA server. The container entries themselves just have cn and an objectClass of cnContainer, so it's impossible to construct a general targetfilter that targets them but not any possible descendants. I see 3 possible solutions: 1) File a DS RFE to implement [targetscope]. With that we could have ACIs that only target a single entry, so admins could manage read access to containers in the usual way (with permissions). 2) Add a (objectClass=nsContainer) filter. The problem here is that if this is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and other nsContainers under it. For example, cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. 3) Add a special attribute to mark "public" containers, and add an ACI with a filter on that. Something like objectClass=ipaPublicContainer would do. >>> there is one more option >>> 4) add an allow aci for cn=accounts,$S and a deny aci for >>> cn=*,cn=accounts,$S >>> or uid=*,cn=accounts,$S >> >> In the past, we tried hard to avoid deny acis and I think we should keep it >> this way. deny ACI is just a hard stop that cannot be overriden by any other >> ACI. If possible, I would prefer to only add allow ACIs. >> >>> In general I think we should implement 1), there will be other scenarios >>> where >>> it could be useful. If something is needed imemdiately I would also prefer >>> 3) >> >> We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 >> feature >> is not an option unless it'd be done really fast. >> >> Given Petr's findings, I am thinking that solution based on 3) seems like way >> to go. We would of course only allow objectclass + cn attributes. I am not >> convinced that objectclass like ipaPublicContainer is the right way to go, >> does >> not sound to me as a standard solution and not something that people would >> assume they need to do when they are adding a custom container. >> >> When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results >> attached) and there were 61 results. Do we really want to update 61 LDAP >> entries and add a custom ipaPublicContainer objectclass to all? Sounds a >> little >> bit hackish to me. >> >> Would adding following ACIs work? >> >> dn: SUFFIX >> aci: allow anonymous read for "(objectclass=nsContainer)" for cn, >> objectclass; >> except cn=etc,SUFFIX >> >> dn: cn=etc,SUFFIX >> aci: allow authenticated read for "(objectclass=nsContainer)" for cn, >> objectclass >> >> As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is >> something we agreed on during DevConf. >> >> With this approach, the only question is what should we do with nsContainer >> based LDAP entries that contains sensitive information. I wonder - is this a >> real situation? Are there many nsContainer LDAP entries with sensitive >> information? Shouldn't we have a rule instead that would recommend using >> custom >> (not nsContainer) objectclasses to store sensitive information based on cn? >> Otherwise it seems to me a an abuse of nsContainer purpose. > We have trust entries that need absolute protection for any > authenticated read other than from 'trust agents' and 'trust admins' groups. Note that this ACI would only allow access to nsContainer based entries + only to CN + ObjectClass attributes, i.e. not to any keys present in such entry for example. Speaking of Trusts, trust data are in cn=,cn=ad,cn=trusts,SUFFIX and none of the subentries has nsContainer object class. Authenticated user would only see that there is cn=ad,cn=trusts,SUFFIX container but nothing else (he does see that already). > There are also Kerberos entries that should not be accessible (master > keys, etc). Not nsContainer objetclass, not even a cn attribute - we are safe there. OTP to
Re: [Freeipa-devel] Read access to container entries
On Mon, 31 Mar 2014, Martin Kosek wrote: On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: Hi Petr, we already discussed on IRC, but see some comments below On 03/28/2014 04:11 PM, Petr Viktorin wrote: Hello, I'm trying to add ACIs to allow read access to containers, and I need some input. The DS's access control system is not designed to allow access to a single entry but not its descendants. The [ACI documentation] suggests some ways to work around it. This doesn't work that well for read access in IPA: $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA V2.0" anonymously. cn=accounts,$SUFFIX needs read access if it or any of its children are to be listed in a GUI cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be listed in a GUI uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied It's safe to expose IPA's default containers anonymously; all they tell the user is that they're looking an IPA server. The container entries themselves just have cn and an objectClass of cnContainer, so it's impossible to construct a general targetfilter that targets them but not any possible descendants. I see 3 possible solutions: 1) File a DS RFE to implement [targetscope]. With that we could have ACIs that only target a single entry, so admins could manage read access to containers in the usual way (with permissions). 2) Add a (objectClass=nsContainer) filter. The problem here is that if this is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and other nsContainers under it. For example, cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. 3) Add a special attribute to mark "public" containers, and add an ACI with a filter on that. Something like objectClass=ipaPublicContainer would do. there is one more option 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S or uid=*,cn=accounts,$S In the past, we tried hard to avoid deny acis and I think we should keep it this way. deny ACI is just a hard stop that cannot be overriden by any other ACI. If possible, I would prefer to only add allow ACIs. In general I think we should implement 1), there will be other scenarios where it could be useful. If something is needed imemdiately I would also prefer 3) We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature is not an option unless it'd be done really fast. Given Petr's findings, I am thinking that solution based on 3) seems like way to go. We would of course only allow objectclass + cn attributes. I am not convinced that objectclass like ipaPublicContainer is the right way to go, does not sound to me as a standard solution and not something that people would assume they need to do when they are adding a custom container. When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results attached) and there were 61 results. Do we really want to update 61 LDAP entries and add a custom ipaPublicContainer objectclass to all? Sounds a little bit hackish to me. Would adding following ACIs work? dn: SUFFIX aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; except cn=etc,SUFFIX dn: cn=etc,SUFFIX aci: allow authenticated read for "(objectclass=nsContainer)" for cn, objectclass As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is something we agreed on during DevConf. With this approach, the only question is what should we do with nsContainer based LDAP entries that contains sensitive information. I wonder - is this a real situation? Are there many nsContainer LDAP entries with sensitive information? Shouldn't we have a rule instead that would recommend using custom (not nsContainer) objectclasses to store sensitive information based on cn? Otherwise it seems to me a an abuse of nsContainer purpose. We have trust entries that need absolute protection for any authenticated read other than from 'trust agents' and 'trust admins' groups. There are also Kerberos entries that should not be accessible (master keys, etc). OTP tokens should only be visible to the user itself and admins. I'm sure there are others too. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Read access to container entries
On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: > Hi Petr, > > we already discussed on IRC, but see some comments below > On 03/28/2014 04:11 PM, Petr Viktorin wrote: >> Hello, >> I'm trying to add ACIs to allow read access to containers, and I need some >> input. >> >> The DS's access control system is not designed to allow access to a single >> entry but not its descendants. The [ACI documentation] suggests some ways to >> work around it. >> >> This doesn't work that well for read access in IPA: >> >> $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA >> V2.0" anonymously. >> cn=accounts,$SUFFIX needs read access if it or any of its children are to be >> listed in a GUI >> cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be >> listed in a GUI >> uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied >> >> It's safe to expose IPA's default containers anonymously; all they tell the >> user is that they're looking an IPA server. >> >> The container entries themselves just have cn and an objectClass of >> cnContainer, so it's impossible to construct a general targetfilter that >> targets them but not any possible descendants. >> >> I see 3 possible solutions: >> 1) File a DS RFE to implement [targetscope]. With that we could have ACIs >> that only target a single entry, so admins could manage read access to >> containers in the usual way (with permissions). >> 2) Add a (objectClass=nsContainer) filter. The problem here is that if this >> is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and >> other nsContainers under it. For example, >> cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. >> 3) Add a special attribute to mark "public" containers, and add an ACI with a >> filter on that. Something like objectClass=ipaPublicContainer would do. > there is one more option > 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S > or uid=*,cn=accounts,$S In the past, we tried hard to avoid deny acis and I think we should keep it this way. deny ACI is just a hard stop that cannot be overriden by any other ACI. If possible, I would prefer to only add allow ACIs. > In general I think we should implement 1), there will be other scenarios where > it could be useful. If something is needed imemdiately I would also prefer 3) We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature is not an option unless it'd be done really fast. Given Petr's findings, I am thinking that solution based on 3) seems like way to go. We would of course only allow objectclass + cn attributes. I am not convinced that objectclass like ipaPublicContainer is the right way to go, does not sound to me as a standard solution and not something that people would assume they need to do when they are adding a custom container. When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results attached) and there were 61 results. Do we really want to update 61 LDAP entries and add a custom ipaPublicContainer objectclass to all? Sounds a little bit hackish to me. Would adding following ACIs work? dn: SUFFIX aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; except cn=etc,SUFFIX dn: cn=etc,SUFFIX aci: allow authenticated read for "(objectclass=nsContainer)" for cn, objectclass As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is something we agreed on during DevConf. With this approach, the only question is what should we do with nsContainer based LDAP entries that contains sensitive information. I wonder - is this a real situation? Are there many nsContainer LDAP entries with sensitive information? Shouldn't we have a rule instead that would recommend using custom (not nsContainer) objectclasses to store sensitive information based on cn? Otherwise it seems to me a an abuse of nsContainer purpose. Martin dn: cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=users,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=services,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=hostgroups,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=alt,dc=mkosek-fedora20,dc=test dn: cn=ng,cn=alt,dc=mkosek-fedora20,dc=test dn: cn=automount,dc=mkosek-fedora20,dc=test dn: cn=default,cn=automount,dc=mkosek-fedora20,dc=test dn: cn=hbac,dc=mkosek-fedora20,dc=test dn: cn=hbacservices,cn=hbac,dc=mkosek-fedora20,dc=test dn: cn=hbacservicegroups,cn=hbac,dc=mkosek-fedora20,dc=test dn: cn=sudo,dc=mkosek-fedora20,dc=test dn: cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test dn: cn=sudocmdgroups,cn=sudo,dc=mkosek-fedora20,dc=test dn: cn=sudorules,cn=sudo,dc=mkosek-fedora20,dc=test dn: cn=etc,dc=mkosek-fedora20,dc=test dn: cn=sysaccounts,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=replicas,cn=ipa,cn=e
Re: [Freeipa-devel] Read access to container entries
Hi Petr, we already discussed on IRC, but see some comments below On 03/28/2014 04:11 PM, Petr Viktorin wrote: Hello, I'm trying to add ACIs to allow read access to containers, and I need some input. The DS's access control system is not designed to allow access to a single entry but not its descendants. The [ACI documentation] suggests some ways to work around it. This doesn't work that well for read access in IPA: $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA V2.0" anonymously. cn=accounts,$SUFFIX needs read access if it or any of its children are to be listed in a GUI cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be listed in a GUI uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied It's safe to expose IPA's default containers anonymously; all they tell the user is that they're looking an IPA server. The container entries themselves just have cn and an objectClass of cnContainer, so it's impossible to construct a general targetfilter that targets them but not any possible descendants. I see 3 possible solutions: 1) File a DS RFE to implement [targetscope]. With that we could have ACIs that only target a single entry, so admins could manage read access to containers in the usual way (with permissions). 2) Add a (objectClass=nsContainer) filter. The problem here is that if this is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and other nsContainers under it. For example, cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. 3) Add a special attribute to mark "public" containers, and add an ACI with a filter on that. Something like objectClass=ipaPublicContainer would do. there is one more option 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S or uid=*,cn=accounts,$S In general I think we should implement 1), there will be other scenarios where it could be useful. If something is needed imemdiately I would also prefer 3) I'm thinking about 3, but I'd like to ask an LDAP expert for opinions. Note that children can be accessible even if the parent isn't. This whole container business only affects exploring the DIT with a GUI-ish tool. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
