[Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens

[Simo Sorce]

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