Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Mon, 2014-02-10 at 15:11 +0200, Alexander Bokovoy wrote:
> On Thu, 06 Feb 2014, Nathaniel McCallum wrote:
> >On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
> >> This patch is independent from my patches 0028-0031 and can be merged in
> >> any order.
> >>
> >> This patch has a bug, but I can't figure it out. We need to set
> >> nsslapd-access-userattr-strict on cn=config to "off". However, during
> >> the rpm installation, I get this error:
> >>
> >> DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting
> >> attributes is not allowed', 'desc': 'Server is unwilling to perform'}
> >> ERROR Update failed: Server is unwilling to perform: Deleting attributes
> >> is not allowed
> >>
> >> I'm not sure what is causing this. Does anyone have any suggestions?
> >
> >Attached is a new revision of this patch. It uses the new SELFDN support
> >present in 389-ds-base 1.3.2.11 that was a result of the previous review
> >of this patch.
> >
> >It currently depends on the HOTP patch (0033-2). However, if we wish to
> >merge this first, this could be easily rebased.
> Could you please rebase it? It would be good to merge it first because
> 0033-2 depends on otp infrastructure patches.
Done.
Nathaniel
>From 3b97eec3a17fec3883520a1cee35fdfa3d529cc9 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum
Date: Thu, 6 Feb 2014 11:27:29 -0500
Subject: [PATCH] Update ACIs to permit users to add/delete their own tokens
---
freeipa.spec.in| 6 +++---
install/share/default-aci.ldif | 1 +
install/updates/40-otp.update | 1 +
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index c28928c1c5c2d20e2dfe6112750c70bfb0b55894..486cd6156be62d4656c181c8739fc5f7e24711cd 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -21,7 +21,7 @@ Source0:freeipa-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%if ! %{ONLY_CLIENT}
-BuildRequires: 389-ds-base-devel >= 1.3.2.10
+BuildRequires: 389-ds-base-devel >= 1.3.2.11
BuildRequires: svrcore-devel
BuildRequires: policycoreutils >= %{POLICYCOREUTILSVER}
BuildRequires: systemd-units
@@ -97,7 +97,7 @@ Group: System Environment/Base
Requires: %{name}-python = %{version}-%{release}
Requires: %{name}-client = %{version}-%{release}
Requires: %{name}-admintools = %{version}-%{release}
-Requires: 389-ds-base >= 1.3.2.10
+Requires: 389-ds-base >= 1.3.2.11
Requires: openldap-clients > 2.4.35-4
%if 0%{?fedora} == 18
Requires: nss >= 3.14.3-2
@@ -153,7 +153,7 @@ Requires: zip
Requires: policycoreutils >= %{POLICYCOREUTILSVER}
Requires: tar
Requires(pre): certmonger >= 0.65
-Requires(pre): 389-ds-base >= 1.3.2.10
+Requires(pre): 389-ds-base >= 1.3.2.11
Requires: fontawesome-fonts
Requires: open-sans-fonts
diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif
index 9af9ab28c72e35f7912795e5280170cc6e1bdd80..b7df72109aacdb5cfba9f190da2935917eccaeaa 100644
--- a/install/share/default-aci.ldif
+++ b/install/share/default-aci.ldif
@@ -103,3 +103,4 @@ add: aci
aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN";)
aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can write basic token info"; allow (write) userattr = "ipatokenOwner#USERDN";)
aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPclockOffset || ipatokenTOTPtimeStep")(version 3.0; acl "Users can add TOTP token secrets"; allow (write, search) userattr = "ipatokenOwner#USERDN";)
+aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "Users can create and delete tokens"; allow (add, delete) userattr = "ipatokenOwner#SELFDN";)
diff --git a/install/updates/40-otp.update b/install/updates/40-otp.update
index 83dfab7c03bfeb121756410d79143c3812146de6..8e1300fb3d38970e106ac03dce4ce3cb776cd7d1 100644
--- a/install/updates/40-otp.update
+++ b/install/updates/40-otp.update
@@ -7,6 +7,7 @@ dn: $SUFFIX
add: aci:'(targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN";)'
add: aci:'(targetfilter = "(objectClass=ipaToken)")(targetattrs = "ipatokenUniqueID || description || ipatokenOwner || ipatoke
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 06 Feb 2014, Nathaniel McCallum wrote:
On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
This patch is independent from my patches 0028-0031 and can be merged in
any order.
This patch has a bug, but I can't figure it out. We need to set
nsslapd-access-userattr-strict on cn=config to "off". However, during
the rpm installation, I get this error:
DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting
attributes is not allowed', 'desc': 'Server is unwilling to perform'}
ERROR Update failed: Server is unwilling to perform: Deleting attributes
is not allowed
I'm not sure what is causing this. Does anyone have any suggestions?
Attached is a new revision of this patch. It uses the new SELFDN support
present in 389-ds-base 1.3.2.11 that was a result of the previous review
of this patch.
It currently depends on the HOTP patch (0033-2). However, if we wish to
merge this first, this could be easily rebased.
Could you please rebase it? It would be good to merge it first because
0033-2 depends on otp infrastructure patches.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
> This patch is independent from my patches 0028-0031 and can be merged in
> any order.
>
> This patch has a bug, but I can't figure it out. We need to set
> nsslapd-access-userattr-strict on cn=config to "off". However, during
> the rpm installation, I get this error:
>
> DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting
> attributes is not allowed', 'desc': 'Server is unwilling to perform'}
> ERROR Update failed: Server is unwilling to perform: Deleting attributes
> is not allowed
>
> I'm not sure what is causing this. Does anyone have any suggestions?
Attached is a new revision of this patch. It uses the new SELFDN support
present in 389-ds-base 1.3.2.11 that was a result of the previous review
of this patch.
It currently depends on the HOTP patch (0033-2). However, if we wish to
merge this first, this could be easily rebased.
>From a235d3949d81d4ddde31e386b4a7fa47df4240a2 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum
Date: Thu, 6 Feb 2014 11:27:29 -0500
Subject: [PATCH] Update ACIs to permit users to add/delete their own tokens
---
freeipa.spec.in| 6 +++---
install/share/default-aci.ldif | 1 +
install/updates/40-otp.update | 1 +
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 628efbfe0a2601557d6e8847798332bf34bc9a79..16378e1313503c2367174304cb7e07a6aee4decd 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -21,7 +21,7 @@ Source0:freeipa-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%if ! %{ONLY_CLIENT}
-BuildRequires: 389-ds-base-devel >= 1.3.2.10
+BuildRequires: 389-ds-base-devel >= 1.3.2.11
BuildRequires: svrcore-devel
BuildRequires: policycoreutils >= %{POLICYCOREUTILSVER}
BuildRequires: systemd-units
@@ -97,7 +97,7 @@ Group: System Environment/Base
Requires: %{name}-python = %{version}-%{release}
Requires: %{name}-client = %{version}-%{release}
Requires: %{name}-admintools = %{version}-%{release}
-Requires: 389-ds-base >= 1.3.2.10
+Requires: 389-ds-base >= 1.3.2.11
Requires: openldap-clients > 2.4.35-4
%if 0%{?fedora} == 18
Requires: nss >= 3.14.3-2
@@ -153,7 +153,7 @@ Requires: zip
Requires: policycoreutils >= %{POLICYCOREUTILSVER}
Requires: tar
Requires(pre): certmonger >= 0.65
-Requires(pre): 389-ds-base >= 1.3.2.10
+Requires(pre): 389-ds-base >= 1.3.2.11
Requires: fontawesome-fonts
Requires: open-sans-fonts
diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif
index 76dd93f4ef2ca5ff6974e6c7ce53f5b7149e55d9..b1c2cbc109dc910cc38c4219a094ffac02a12a57 100644
--- a/install/share/default-aci.ldif
+++ b/install/share/default-aci.ldif
@@ -104,3 +104,4 @@ aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || ipa
aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can write basic token info"; allow (write) userattr = "ipatokenOwner#USERDN";)
aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPclockOffset || ipatokenTOTPtimeStep")(version 3.0; acl "Users can add TOTP token secrets"; allow (write, search) userattr = "ipatokenOwner#USERDN";)
aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenHOTPcounter")(version 3.0; acl "Users can add HOTP token secrets"; allow (write, search) userattr = "ipatokenOwner#USERDN";)
+aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "Users can create and delete tokens"; allow (add, delete) userattr = "ipatokenOwner#SELFDN";)
diff --git a/install/updates/40-otp.update b/install/updates/40-otp.update
index 750d0f8b3134fb4a81f4d35a1743b8c48113a88f..4384c7351f9a7e3eab18aa38b584c7dabcee7cf5 100644
--- a/install/updates/40-otp.update
+++ b/install/updates/40-otp.update
@@ -8,6 +8,7 @@ add: aci:'(targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass |
add: aci:'(targetfilter = "(objectClass=ipaToken)")(targetattrs = "ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can write basic token info"; allow (write) userattr = "ipatokenOwner#USERDN";)'
add: aci:'(targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPclockOffset || ipatokenTOTPtimeStep")(version 3.0; acl "Users can add TOTP token secrets"; allow (write, search) userattr = "ipatokenOwner#USERDN";)'
add: aci:'(targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgo
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Fri, 2014-01-10 at 15:14 -0500, Nathaniel McCallum wrote: > On Thu, 2014-01-09 at 17:37 -0500, Simo Sorce wrote: > > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > > > This patch is independent from my patches 0028-0031 and can be merged in > > > any order. > > > > > > This patch has a bug, but I can't figure it out. We need to set > > > nsslapd-access-userattr-strict on cn=config to "off". > > > > Uhmm what is the effect on ACL evaluation of changing this boolean ? > > I can;t figure out from your commit not from 389ds commit what exactly > > changes and how it impacts the security of the directory. > > > > I ask because I was planning on using userattr to protect some > > operations in the password plugin but was waiting due to bug: > > https://fedorahosted.org/389/ticket/47571 which is beeing resolved. > > > > I want to make sure your change won't change what this ACIs would allow. > > > > Is this option simply allowing the use of add/delete ACIs to be > > specified in conjunction with userattr, so that a user can add an attr > > only if it contains its own DN ? > > > > Will it allow the user to add multiple values to the same attr as long > > as one of the is the userDN ? O will it restrict that case ? > > > > (I know that ipaTokenOwner is a single-value attribute, but the > > mechanism you are enabling here is general, and I want to be sure of > > what the semantics are) > > After testing, it was determined that the 389DS patch #47653 does in > fact permit addition if any of the multi-valued attributes match the > condition. This is definitely problematic. > > After discussion today with nkinder, simo, nhosoi, we agreed to > roll-back patch #47653 and find an alternate approach. This also > invalidates patch freeipa-npmccallum-0032. Simo will follow up this > email with an alternate proposal. Sorry for the delay, my proposal is to add a new keyword to the ACI system: selfattr selfattr is similar to userattr + #userdn, the syntax is simply: (selfattr=attrname) attrname is the name of the attribute that will be tested by the ACI evaluator, and the semantics combined with the various allow flags are the following: allow add: an entry can be added if and only if attrname = userDN where the user DN is the authenticated user DN. Furthermore the only value (is attrname is multivalued) allowed is again userDN allow delete: an entry can be deleted only if attrname has exclusively one value, the DN of the authenticated user For the write,read,search operation I am not sure we really need a special syntax, maybe we should actually disallow the combination. If we allow it we may (or not) want to have the following behavior: allow write: the only value that can be added to or removed from attrname is the authenticated userDN allow read: the entry can be searched but the only value returned for attrname is that of the authenticated userDN if present allow search/compare: the entry can be searched only if attrname contains the authenticated userDN I suspect these 3 behavrios can be obtained with different syntaxes too, for example using targeattr/targetattrfilter, in that case, maybe it is better to just restrict selfattr to be valid with add/delete operations for now. HTH, 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 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 2014-01-09 at 17:37 -0500, Simo Sorce wrote: > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > > This patch is independent from my patches 0028-0031 and can be merged in > > any order. > > > > This patch has a bug, but I can't figure it out. We need to set > > nsslapd-access-userattr-strict on cn=config to "off". > > Uhmm what is the effect on ACL evaluation of changing this boolean ? > I can;t figure out from your commit not from 389ds commit what exactly > changes and how it impacts the security of the directory. > > I ask because I was planning on using userattr to protect some > operations in the password plugin but was waiting due to bug: > https://fedorahosted.org/389/ticket/47571 which is beeing resolved. > > I want to make sure your change won't change what this ACIs would allow. > > Is this option simply allowing the use of add/delete ACIs to be > specified in conjunction with userattr, so that a user can add an attr > only if it contains its own DN ? > > Will it allow the user to add multiple values to the same attr as long > as one of the is the userDN ? O will it restrict that case ? > > (I know that ipaTokenOwner is a single-value attribute, but the > mechanism you are enabling here is general, and I want to be sure of > what the semantics are) After testing, it was determined that the 389DS patch #47653 does in fact permit addition if any of the multi-valued attributes match the condition. This is definitely problematic. After discussion today with nkinder, simo, nhosoi, we agreed to roll-back patch #47653 and find an alternate approach. This also invalidates patch freeipa-npmccallum-0032. Simo will follow up this email with an alternate proposal. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
Hi Simo, Simo Sorce wrote: On Fri, 2014-01-10 at 12:15 -0500, Simo Sorce wrote: This is not what I had in mind, our use cases is something like this: aci: (target=ldap:///dc=bar)(targetattr=*) (version 3.0; acl "userattr test"; allow (add) userattr = "managedby#USERDN";) ldapmodify -D uid=user,dc=bar ... < dn: cn=somobj,dc=bar ... managedby: uid=user,dc=bar Sorry this should have been ldapadd. Simo. Yes, it works. aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr test" ; allow (add,write,delete,read,search,compare) userattr = "description#USERDN";) $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0 -a << EOF dn: uid=Nuser6, o=my.com ... description: uid=nuser0,o=my.com EOF $ ldapsearch... -b "o=my.com" "(uid=nuser6)" description dn: uid=Nuser6,o=my.com description: uid=nuser0,o=my.com # delete uid=nuser6 # attempt to add the entry by other user fails: $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1 -a << EOF dn: uid=Nuser6, o=my.com ... description: uid=nuser0,o=my.com EOF ldap_add: Insufficient access ldap_add: additional info: Insufficient 'add' privilege to the 'userPassword' attribute dn: cn=somobj,dc=bar ... managedby: uid=user,dc=bar This should succeed, however if managedby includes anything but "uid=user,dc=bar" it should fail. Will it allow the user to add multiple values to the same attr as long as one of the is the userDN ? O will it restrict that case ? This is also important, if attrFoo is a multivalued attribute, does this option allow any values to be set as long as one of them is userDN ? Or will it enforce that *only* userDN is add in the add operation ? As long as the type of the attribute is not restricted as DN syntax, it takes any value including DN. I tested with 'description' (e.g., userattr = "description#USERDN") and verified it takes userDN as well as any other values. $ ldapmodify ... -D 'cn=directory manager' -w dn: uid=nuser4,o=my.com changetype: modify add: description description: uid=nuser4,o=my.com $ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4 dn: uid=nuser4,o=my.com changetype: modify add: description description: uid=nuser0,o=my.com modifying entry uid=nuser4,o=my.com $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0 dn: uid=nuser4,o=my.com changetype: modify add: description description: uid=nuser1,o=my.com modifying entry uid=nuser4,o=my.com $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1 dn: uid=nuser4,o=my.com changetype: modify add: description description: value $ ldapsearch ... -D 'cn=directory manager' -w -b "uid=nuser4,o=my.com" description dn: uid=Nuser4,o=my.com description: uid=nuser4,o=my.com description: uid=nuser0,o=my.com description: uid=nuser1,o=my.com description: value If I read this correctly, and I am not 100% sure yet, it seem to me this is exactly the opposite of what IPA needs. Our need is that uid=userX,... can only write its own DN as value or the attributes we are allowing through userattr. You want to allow this $ ldapmodify ... -D 'uid=*userX*,o=my.com' -w userX << EOF dn: uid=userY,o=my.com changetype: modify replace: managedby managedby: uid=*userX*,o=my.com EOF But NOT allow this? $ ldapmodify ... -D 'uid=*userX*,o=my.com' -w userX << EOF dn: uid=userY,o=my.com changetype: modify replace: managedby managedby: uid=*userZ*,o=my.com EOF I don't think we have the control there... --noriko ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Fri, 2014-01-10 at 12:15 -0500, Simo Sorce wrote:
> On Thu, 2014-01-09 at 21:30 -0800, Noriko Hosoi wrote:
> > Simo Sorce wrote:
> > > On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote:
> > >> Simo Sorce wrote:
> > >>> On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
> > This patch is independent from my patches 0028-0031 and can be merged
> > in
> > any order.
> >
> > This patch has a bug, but I can't figure it out. We need to set
> > nsslapd-access-userattr-strict on cn=config to "off".
> > >>> Uhmm what is the effect on ACL evaluation of changing this boolean ?
> > >> Ticket 47653 - Need a way to allow users to create entries assigned
> > >> to themselves
> > >>
> > >> Bug Description: There are cases where users need to be able to
> > >> create, edit and delete
> > >> their own entries. Using an ACI with the
> > >> "userattr" keyword does not
> > >> work with ADD operations(to prevent a security
> > >> hole). This prevents IPA's
> > >> OTP plugin from performing some necessary
> > >> operations.
> > >>
> > >> Fix Description: Added a new config attribute
> > >> "nsslapd-access-userattr-strict". The default
> > >> is "on" or strict. For the IPA case, it would
> > >> need to be set to "off" in
> > >> order to allow the desired behavior.
> > >>
> > >> https://fedorahosted.org/389/ticket/47653
> > >>
> > >> This patch is included in 389-ds-base-1.3.2.10 and newer.
> > > Thank you Noriko, but as I mentioned, I already read through the 389ds
> > > patch and it doesn't help me. Below I have a few more questions, I will
> > > add one that is more clear.
> > >
> > >>> Is this option simply allowing the use of add/delete ACIs to be
> > >>> specified in conjunction with userattr, so that a user can add an attr
> > >>> only if it contains its own DN ?
> > > So the entry in this case does not exist yet, so my question is whether
> > > the (userattr=attrFoo#userDN) part will actually match that attrFoo is
> > > set to contain the DN of the user that is performing the operation ?
> > I uesd this ACI:
> > aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr
> > test"; allow (add,write,delete,read,search,compare) userattr =
> > "description#USERDN";)
> >
> > Please note uid=nuser does not exist yet. Does your question mean by
> > this add? Before coming to the ACL code, bind fails...
> > $ ldapmodify ... -D 'uid=nuser,o=my.com' -w Nuser -a << EOF
> > dn: uid=Nuser, o=my.com
> > objectClass: top
> > [...]
> > uid: Nuser
> > description: uid=nuser,o=my.com
> > userPassword: {CLEAR}Nuser
> > EOF
> > ldap_simple_bind: No such object
> > ldap_simple_bind: matched: o=my.com
>
> This is not what I had in mind, our use cases is something like this:
> aci: (target=ldap:///dc=bar)(targetattr=*) (version 3.0; acl "userattr
> test"; allow (add) userattr = "managedby#USERDN";)
>
> ldapmodify -D uid=user,dc=bar ... < dn: cn=somobj,dc=bar
> ...
> managedby: uid=user,dc=bar
>
>
> This should succeed, however if managedby includes anything but
> "uid=user,dc=bar" it should fail.
>
> > >>> Will it allow the user to add multiple values to the same attr as long
> > >>> as one of the is the userDN ? O will it restrict that case ?
> > > This is also important, if attrFoo is a multivalued attribute, does this
> > > option allow any values to be set as long as one of them is userDN ?
> > > Or will it enforce that *only* userDN is add in the add operation ?
> > As long as the type of the attribute is not restricted as DN syntax, it
> > takes any value including DN. I tested with 'description' (e.g.,
> > userattr = "description#USERDN") and verified it takes userDN as well as
> > any other values.
> >
> > $ ldapmodify ... -D 'cn=directory manager' -w
> > dn: uid=nuser4,o=my.com
> > changetype: modify
> > add: description
> > description: uid=nuser4,o=my.com
> >
> > $ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4
> > dn: uid=nuser4,o=my.com
> > changetype: modify
> > add: description
> > description: uid=nuser0,o=my.com
> >
> > modifying entry uid=nuser4,o=my.com
> >
> > $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0
> > dn: uid=nuser4,o=my.com
> > changetype: modify
> > add: description
> > description: uid=nuser1,o=my.com
> >
> > modifying entry uid=nuser4,o=my.com
> >
> > $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1
> > dn: uid=nuser4,o=my.com
> > changetype: modify
> > add: description
> > description: value
> >
> > $ ldapsearch ... -D 'cn=directory manager' -w -b
> > "uid=nuser4,o=my.com" description
> > dn: uid=Nuser4,o=my.com
> > description: uid=nuser4,o=my.com
> > description: uid=nuser0,o=my.com
> > description: uid=nuser1,o=my.com
> > description: value
>
> If I read this correctly, and I am not 100% sure yet, it seem to me this
> is exactly the opposite of what IPA needs.
>
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 2014-01-09 at 21:30 -0800, Noriko Hosoi wrote:
> Simo Sorce wrote:
> > On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote:
> >> Simo Sorce wrote:
> >>> On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
> This patch is independent from my patches 0028-0031 and can be merged in
> any order.
>
> This patch has a bug, but I can't figure it out. We need to set
> nsslapd-access-userattr-strict on cn=config to "off".
> >>> Uhmm what is the effect on ACL evaluation of changing this boolean ?
> >> Ticket 47653 - Need a way to allow users to create entries assigned
> >> to themselves
> >>
> >> Bug Description: There are cases where users need to be able to
> >> create, edit and delete
> >> their own entries. Using an ACI with the
> >> "userattr" keyword does not
> >> work with ADD operations(to prevent a security
> >> hole). This prevents IPA's
> >> OTP plugin from performing some necessary
> >> operations.
> >>
> >> Fix Description: Added a new config attribute
> >> "nsslapd-access-userattr-strict". The default
> >> is "on" or strict. For the IPA case, it would
> >> need to be set to "off" in
> >> order to allow the desired behavior.
> >>
> >> https://fedorahosted.org/389/ticket/47653
> >>
> >> This patch is included in 389-ds-base-1.3.2.10 and newer.
> > Thank you Noriko, but as I mentioned, I already read through the 389ds
> > patch and it doesn't help me. Below I have a few more questions, I will
> > add one that is more clear.
> >
> >>> Is this option simply allowing the use of add/delete ACIs to be
> >>> specified in conjunction with userattr, so that a user can add an attr
> >>> only if it contains its own DN ?
> > So the entry in this case does not exist yet, so my question is whether
> > the (userattr=attrFoo#userDN) part will actually match that attrFoo is
> > set to contain the DN of the user that is performing the operation ?
> I uesd this ACI:
> aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr
> test"; allow (add,write,delete,read,search,compare) userattr =
> "description#USERDN";)
>
> Please note uid=nuser does not exist yet. Does your question mean by
> this add? Before coming to the ACL code, bind fails...
> $ ldapmodify ... -D 'uid=nuser,o=my.com' -w Nuser -a << EOF
> dn: uid=Nuser, o=my.com
> objectClass: top
> [...]
> uid: Nuser
> description: uid=nuser,o=my.com
> userPassword: {CLEAR}Nuser
> EOF
> ldap_simple_bind: No such object
> ldap_simple_bind: matched: o=my.com
This is not what I had in mind, our use cases is something like this:
aci: (target=ldap:///dc=bar)(targetattr=*) (version 3.0; acl "userattr
test"; allow (add) userattr = "managedby#USERDN";)
ldapmodify -D uid=user,dc=bar ... < >>> Will it allow the user to add multiple values to the same attr as long
> >>> as one of the is the userDN ? O will it restrict that case ?
> > This is also important, if attrFoo is a multivalued attribute, does this
> > option allow any values to be set as long as one of them is userDN ?
> > Or will it enforce that *only* userDN is add in the add operation ?
> As long as the type of the attribute is not restricted as DN syntax, it
> takes any value including DN. I tested with 'description' (e.g.,
> userattr = "description#USERDN") and verified it takes userDN as well as
> any other values.
>
> $ ldapmodify ... -D 'cn=directory manager' -w
> dn: uid=nuser4,o=my.com
> changetype: modify
> add: description
> description: uid=nuser4,o=my.com
>
> $ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4
> dn: uid=nuser4,o=my.com
> changetype: modify
> add: description
> description: uid=nuser0,o=my.com
>
> modifying entry uid=nuser4,o=my.com
>
> $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0
> dn: uid=nuser4,o=my.com
> changetype: modify
> add: description
> description: uid=nuser1,o=my.com
>
> modifying entry uid=nuser4,o=my.com
>
> $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1
> dn: uid=nuser4,o=my.com
> changetype: modify
> add: description
> description: value
>
> $ ldapsearch ... -D 'cn=directory manager' -w -b
> "uid=nuser4,o=my.com" description
> dn: uid=Nuser4,o=my.com
> description: uid=nuser4,o=my.com
> description: uid=nuser0,o=my.com
> description: uid=nuser1,o=my.com
> description: value
If I read this correctly, and I am not 100% sure yet, it seem to me this
is exactly the opposite of what IPA needs.
Our need is that uid=userX,... can only write its own DN as value or the
attributes we are allowing through userattr.
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 0032] Update ACIs to permit users to add/delete their own tokens
Simo Sorce wrote:
On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote:
Simo Sorce wrote:
On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
This patch is independent from my patches 0028-0031 and can be merged in
any order.
This patch has a bug, but I can't figure it out. We need to set
nsslapd-access-userattr-strict on cn=config to "off".
Uhmm what is the effect on ACL evaluation of changing this boolean ?
Ticket 47653 - Need a way to allow users to create entries assigned
to themselves
Bug Description: There are cases where users need to be able to
create, edit and delete
their own entries. Using an ACI with the
"userattr" keyword does not
work with ADD operations(to prevent a security
hole). This prevents IPA's
OTP plugin from performing some necessary operations.
Fix Description: Added a new config attribute
"nsslapd-access-userattr-strict". The default
is "on" or strict. For the IPA case, it would
need to be set to "off" in
order to allow the desired behavior.
https://fedorahosted.org/389/ticket/47653
This patch is included in 389-ds-base-1.3.2.10 and newer.
Thank you Noriko, but as I mentioned, I already read through the 389ds
patch and it doesn't help me. Below I have a few more questions, I will
add one that is more clear.
Is this option simply allowing the use of add/delete ACIs to be
specified in conjunction with userattr, so that a user can add an attr
only if it contains its own DN ?
So the entry in this case does not exist yet, so my question is whether
the (userattr=attrFoo#userDN) part will actually match that attrFoo is
set to contain the DN of the user that is performing the operation ?
I uesd this ACI:
aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr
test"; allow (add,write,delete,read,search,compare) userattr =
"description#USERDN";)
Please note uid=nuser does not exist yet. Does your question mean by
this add? Before coming to the ACL code, bind fails...
$ ldapmodify ... -D 'uid=nuser,o=my.com' -w Nuser -a << EOF
dn: uid=Nuser, o=my.com
objectClass: top
[...]
uid: Nuser
description: uid=nuser,o=my.com
userPassword: {CLEAR}Nuser
EOF
ldap_simple_bind: No such object
ldap_simple_bind: matched: o=my.com
Will it allow the user to add multiple values to the same attr as long
as one of the is the userDN ? O will it restrict that case ?
This is also important, if attrFoo is a multivalued attribute, does this
option allow any values to be set as long as one of them is userDN ?
Or will it enforce that *only* userDN is add in the add operation ?
As long as the type of the attribute is not restricted as DN syntax, it
takes any value including DN. I tested with 'description' (e.g.,
userattr = "description#USERDN") and verified it takes userDN as well as
any other values.
$ ldapmodify ... -D 'cn=directory manager' -w
dn: uid=nuser4,o=my.com
changetype: modify
add: description
description: uid=nuser4,o=my.com
$ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4
dn: uid=nuser4,o=my.com
changetype: modify
add: description
description: uid=nuser0,o=my.com
modifying entry uid=nuser4,o=my.com
$ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0
dn: uid=nuser4,o=my.com
changetype: modify
add: description
description: uid=nuser1,o=my.com
modifying entry uid=nuser4,o=my.com
$ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1
dn: uid=nuser4,o=my.com
changetype: modify
add: description
description: value
$ ldapsearch ... -D 'cn=directory manager' -w -b
"uid=nuser4,o=my.com" description
dn: uid=Nuser4,o=my.com
description: uid=nuser4,o=my.com
description: uid=nuser0,o=my.com
description: uid=nuser1,o=my.com
description: value
--noriko
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote: > Simo Sorce wrote: > > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > >> This patch is independent from my patches 0028-0031 and can be merged in > >> any order. > >> > >> This patch has a bug, but I can't figure it out. We need to set > >> nsslapd-access-userattr-strict on cn=config to "off". > > Uhmm what is the effect on ACL evaluation of changing this boolean ? > Ticket 47653 - Need a way to allow users to create entries assigned > to themselves > > Bug Description: There are cases where users need to be able to > create, edit and delete >their own entries. Using an ACI with the > "userattr" keyword does not >work with ADD operations(to prevent a security > hole). This prevents IPA's >OTP plugin from performing some necessary operations. > > Fix Description: Added a new config attribute > "nsslapd-access-userattr-strict". The default >is "on" or strict. For the IPA case, it would > need to be set to "off" in >order to allow the desired behavior. > > https://fedorahosted.org/389/ticket/47653 > > This patch is included in 389-ds-base-1.3.2.10 and newer. Thank you Noriko, but as I mentioned, I already read through the 389ds patch and it doesn't help me. Below I have a few more questions, I will add one that is more clear. > > Is this option simply allowing the use of add/delete ACIs to be > > specified in conjunction with userattr, so that a user can add an attr > > only if it contains its own DN ? So the entry in this case does not exist yet, so my question is whether the (userattr=attrFoo#userDN) part will actually match that attrFoo is set to contain the DN of the user that is performing the operation ? > > Will it allow the user to add multiple values to the same attr as long > > as one of the is the userDN ? O will it restrict that case ? This is also important, if attrFoo is a multivalued attribute, does this option allow any values to be set as long as one of them is userDN ? Or will it enforce that *only* userDN is add in the add operation ? 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 0032] Update ACIs to permit users to add/delete their own tokens
Simo Sorce wrote: On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: This patch is independent from my patches 0028-0031 and can be merged in any order. This patch has a bug, but I can't figure it out. We need to set nsslapd-access-userattr-strict on cn=config to "off". Uhmm what is the effect on ACL evaluation of changing this boolean ? Ticket 47653 - Need a way to allow users to create entries assigned to themselves Bug Description: There are cases where users need to be able to create, edit and delete their own entries. Using an ACI with the "userattr" keyword does not work with ADD operations(to prevent a security hole). This prevents IPA's OTP plugin from performing some necessary operations. Fix Description: Added a new config attribute "nsslapd-access-userattr-strict". The default is "on" or strict. For the IPA case, it would need to be set to "off" in order to allow the desired behavior. https://fedorahosted.org/389/ticket/47653 This patch is included in 389-ds-base-1.3.2.10 and newer. I can;t figure out from your commit not from 389ds commit what exactly changes and how it impacts the security of the directory. I ask because I was planning on using userattr to protect some operations in the password plugin but was waiting due to bug: https://fedorahosted.org/389/ticket/47571 which is beeing resolved. Thank you for waiting. We are going to add the fix to the next release (1.3.2.11). Thanks! --noriko I want to make sure your change won't change what this ACIs would allow. Is this option simply allowing the use of add/delete ACIs to be specified in conjunction with userattr, so that a user can add an attr only if it contains its own DN ? Will it allow the user to add multiple values to the same attr as long as one of the is the userDN ? O will it restrict that case ? (I know that ipaTokenOwner is a single-value attribute, but the mechanism you are enabling here is general, and I want to be sure of what the semantics are) Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > This patch is independent from my patches 0028-0031 and can be merged in > any order. > > This patch has a bug, but I can't figure it out. We need to set > nsslapd-access-userattr-strict on cn=config to "off". Uhmm what is the effect on ACL evaluation of changing this boolean ? I can;t figure out from your commit not from 389ds commit what exactly changes and how it impacts the security of the directory. I ask because I was planning on using userattr to protect some operations in the password plugin but was waiting due to bug: https://fedorahosted.org/389/ticket/47571 which is beeing resolved. I want to make sure your change won't change what this ACIs would allow. Is this option simply allowing the use of add/delete ACIs to be specified in conjunction with userattr, so that a user can add an attr only if it contains its own DN ? Will it allow the user to add multiple values to the same attr as long as one of the is the userDN ? O will it restrict that case ? (I know that ipaTokenOwner is a single-value attribute, but the mechanism you are enabling here is general, and I want to be sure of what the semantics are) 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 0032] Update ACIs to permit users to add/delete their own tokens
On 01/09/2014 02:32 PM, Nathaniel McCallum wrote:
This patch is independent from my patches 0028-0031 and can be merged in
any order.
This patch has a bug, but I can't figure it out. We need to set
nsslapd-access-userattr-strict on cn=config to "off". However, during
the rpm installation, I get this error:
DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting
attributes is not allowed', 'desc': 'Server is unwilling to perform'}
ERROR Update failed: Server is unwilling to perform: Deleting attributes
is not allowed
I'm not sure what is causing this. Does anyone have any suggestions?
I believe the IPA update mechanism works by doing a modify/del of the
attribute followed by a modify/add. By default, cn=config restricts the
attributes which can be deleted. You can add
nsslapd-access-userattr-strict to this list. Unfortunately, it is
rather painful to do so.
Method one: Don't use the ipa update mechanism to update this
attribute. Instead, just use an ldap modify directly e.g. using ldapmodify:
ldapmodify
dn: cn=config
changetype: modify
replace: nsslapd-access-userattr-strict
nsslapd-access-userattr-strict: off
or in python-ldap:
conn = ldap.connection(my ldap url)
conn.simple_bind_s("cn=directory manager", "password")
mod = [(ldap.MOD_REPLACE, "nsslapd-access-userattr-strict", ['off'])]
conn.modify_s("cn=config", mod)
Method two: allow deletion of nsslapd-access-userattr-strict in order to
use ipa update method
This will unfortunately require the use of something other than the ipa
update method, again.
1) do a search to get the current value in cn=config
nsslapd-allowed-to-delete-attrs - it is a single space delimited list
2) add nsslapd-access-userattr-strict to the list
3) mod/replace the value
Nathaniel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
