OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6900
Full headers

From: daniel@pluta.biz
Subject: dnattr acl statement: users can produce dangling entries
Compose comment
Download message
State:
0 replies:
6 followups: 1 2 3 4 5 6

Major security issue: yes  no

Notes:

Notification:


Date: Sun, 10 Apr 2011 17:37:53 +0000
From: daniel@pluta.biz
To: openldap-its@OpenLDAP.org
Subject: dnattr acl statement: users can produce dangling entries
Full_Name: Daniel Pluta
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110410.patch
Submission from: (NULL) (2001:4ca0:0:fe11::1)


Hi,

I'm not quite sure whether the below described scenario can be successfully
avoided eg. using current slapd in combination with some kind of tricky ACL
configuration statements (if so, any advice is strongly appreciated).

Nevertheless, attached below you'll find a small patch that implements a
slightly enhanced (aka more restictive!) dnattr acl processing in case of
ACL_WDEL operations: In case the currently authenticated user tries to delete
his bindDN from the attribute referenced by the dnattr= acl statement, access is
denied.


Example scenario based on the following (nearly) minimal standard ACL
configuration:

access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
        by users =w
        by * none

access to dn.onelevel="ou=groups,dc=foo,dc=bar"
        by dnattr=owner write
        by * none

access to dn.subtree="dc=foo,dc=bar"
        by users read
        by * none

... at first a user (user1) successfully creates (add) a new group entry,
where/because user1's DN is contained within the entry's owner attribute:

OPTS="-Z -D 'uid=user1,ou=users,dc=foo,dc=bar' -w 'user1'"
cat <<EOF | ldapadd ${OPTS}
dn: cn=test,ou=groups,dc=foo,dc=bar
objectClass: groupOfNames
objectClass: top
cn: test
member: cn=otheruser,ou=users,dc=foo,dc=bar
description: test group entry
owner: uid=user1,ou=users,dc=foo,dc=bar

EOF

Then, user1 (by mistake but) successfully modifies the just before created and
personaly owned entry, deleting his DN from the owner attribute:

cat <<EOF | ldapmodify ${OPTS}
dn: cn=test,ou=groups,dc=foo,dc=bar
changetype: modify
delete: owner
owner: uid=user1,ou=users,dc=foo,dc=bar

EOF

As a sideeffect from this second operation user1 has no chance to revert his
mistake because he has lost the previous assigned access rights to access this
entry by write. In fact nobody else (other than the rootdn) has a chance to
correct/delete the dangline group entry.

Another disabdvantage of the current implementation is the possibility to move
currently managed/owned entries (e.g. users or groups) to other owners/managers
without their notice/interaction.

The attached patch only interact in case of value delete operations. Thus, based
on the patch other owners/managers can be added/deleted as usual (except the DN
of the modifyer himself). Added owners/managers can take solely responsibility
of an entry by deleting all other owners/managers.

I would be very happy in case this patch or at least the based idea could find a
way into slapd's code. I don't mind whether this feature is implemented as an
extension of current dnattr processing (backward compatibility?) or as an
additional configuration option, e.g. "strictdnattr=..." (update
documentation?). Also I'm not sure whether set acl statements should or need to
be extended into this direction, too...

Thank you very much and best regards
Daniel

Followup 1

Download message
Date: Tue, 12 Apr 2011 02:03:34 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
A small but important bugfix for my patch, that also honors access "to 
all values", can be found here:

ftp://ftp.openldap.org/incoming/Daniel-Pluta-20110412.patch



Followup 2

Download message
Date: Sat, 16 Apr 2011 00:12:19 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
Hi, it's me again,

with another small but also very important bugfix for the previous two 
versions of my patch. This patch does not change the correct (as 
documented by the project) behaviour of "dnattr=... selfwrite". It can 
be found here:

ftp://ftp.openldap.org/incoming/Daniel-Pluta-110415.patch


FYI and the log: Next to some simple always reproducible 
test-shellscripts (ldapmodify add/delete distinct values) I have been 
also using Apache Directory Studio to test and workout the intended 
behavior of my ACLs, which is the root cause for these two updates: I've 
not been aware of the difference between "to value" and "to all values", 
yet and all my testcases (ldif changetype modify) only have been using 
"to value" operations.

I've used following ACL to test this second patch of my original patch:

access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
         by users read
         by * none

access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description
         by users read
         by * none break

access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member
         by dnattr=member selfwrite
         by * none

Based on these ACL each user that is a member of a group entry seems to 
be just the only member of these group (from the user's point of view, 
in case the user accesses the group's member attribute by read). When 
using Apache Directoy Studio to delete this only/single/last group 
member ("right click --> delete value") this results in a "to all value" 
operation, instead of a "to value memberDN" operation.

=> acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr 
"member" requested
=> acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0)

It seems to me that this appears to be a bug in ADS, where the client 
(ADS) tries to be more inteligent/comfortable/strict than needed. OTOH 
based on this strange behaviour I've learned something "new" (and quite 
important to me in regard to acl design and testcases during testing). 
Sorry for these kind of SPAM and the circumstances. Hopefully that's the 
last bugfix for that patch.



Followup 3

Download message
Date: Fri, 22 Apr 2011 02:29:31 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
Once again an update of this patch:

One more step further dnattr's documented behaviour:
Now the DN in dnattr is additionally allowed to remove the whole entry.

The update can be found here:
ftp://ftp.openldap.org/incoming/Daniel-Pluta-110422.patch

I'm not quite satisfied with my code and its internal processing. It's 
more some kind of a prototype. Probably you guys do have the knowlege to 
"convert" it into a better and slapd-like design...

Thanks a lot!



Followup 4

Download message
Date: Sun, 24 Apr 2011 22:38:04 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
Hopefully nobody else than me has wasted his/her time reviewing my 
previously submitted patches related to this ITS. They are completely wrong!

Here you'll find a rewritten version from scratch which should work as 
expected or at least can be taken as a basis for further reviewing:

ftp://ftp.openldap.org/incoming/Daniel-Pluta-110424-2.patch



Followup 5

Download message
Date: Fri, 14 Oct 2011 16:50:45 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: Howard Chu <hyc@symas.com>
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
Hi Howard,

as we've discussed during LDAPCon2011's get-together the following idea 
is currently not supported in slapd.

For demonstration purposes I've introduced a <dnattrstyle> that only 
supports one style-descriptor called ".strict". It restricts 
"dnattr=..." ACL statements the way that self is not allowed to remove 
her own DN from dnattr.

I've tested the patch with the following simple sample ACLs:

to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
   by users write
to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,@groupOfNames
   by dnattr.strict=owner write
   by users read

According these two ACLs a group's owner is allowed to write the whole 
object (not only add, but also delete, aka in sum "write"). 
Nevertheless, because of the ".strict" the owner is not able to delete 
his own DN from the owner attribute.

You can find an updated version of my patch here:
ftp://ftp.openldap.org/incoming/Daniel-Pluta-111014.patch

As it is still intended for demonstration purposes, the patch is highly 
probable suboptimal regarding its implementation, in particular 
regarding the chosen place within slapd's code.

Instead of the <dnattrstyle> probably a new "<access>" called e.g. 
"writeToSelfButSelfNoDelete" or similar should be introduced instead. 
Unfortunately, I don't know how to code this correctly without 
changing/breaking the whole acl-engine and introducing various "funny" 
side-effects.

Best regards
Daniel
P.S. Furthermore, and although I've no related scenario in mind, it 
perhaps could make sense to generalize this kind of behaviour also into 
direction to "writeToSelfButSelfNoAdd" etc. I'm not sure whether this 
would make sense, too.



Followup 6

Download message
Date: Tue, 07 Aug 2012 16:17:52 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: openldap-its@openldap.org
Subject: Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
This ITS can be closed.

See ITS#7347 instead, currently located 
http://www.openldap.org/its/index.cgi/Incoming?id=7347;selectid=7347#followup2


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org