[Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Nathaniel McCallum]

On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:
> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:
> 
> > The background of this email is this bug:
> > https://fedorahosted.org/freeipa/ticket/4456
> > 
> > Attached are two patches which solve this issue for admin users (not
> > very helpful, I know). They depend on this fix in 389:
> > https://fedorahosted.org/389/ticket/47920
> > 
> > There are two outstanding issues:
> > 
> > 1. 389 does not send the post read control for normal users. The
> > operation itself succeeds, but no control is sent.
> > 
> > The relevant sections from the log are attached. 389 is denying access
> > to the following attributes (* = valid, ! = invalid):
> > ! objectClass
> > ! ipatokenOTPalgorithm
> > ! ipatokenOTPdigits
> > * ipatokenOTPkey
> > * ipatokenHOTPcounter
> > ! ipatokenOwner
> > ! managedBy
> > ! ipatokenUniqueID
> Hello Nathaniel,
> 
>         The post read control needs access to the modified entry to
>         return it.
>         This access is granted at the condition, the binddn can access
>         attributes.

Agreed and understood.

>         My understanding is that the target entry is
>         ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".

Correct.

>         The only ACI I found that match this target is:
>         aci: (targetfilter = "(objectClass=ipaToken)")
>         (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled 
>          || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner")
>         (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)

Correct.

>         Do you know if the target entry has 'ipatokenOwner' or
>         'managedBy' with the binddn value ?

Yes, both. So why is access to objectClass (et cetera) being denied?

> > The ACIs allowing access to most of these attributes are here:
> > https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
> > 
> > Note that I am able to query the entry just fine (including all the
> > above invalidly restricted attributes). Hence, I know the ACIs are
> > working just fine.
> > 
> > Part of the strange thing is that in the post read control request, I
> > haven't indicated that I want *any* attributes returned (i.e. I want
> > just the DN). So I'm not sure why it is querying all the attributes. I
> > would suspect that the proper behavior would be to only check the ACIs
> > on attributes that will actually be returned.
>         It may not querying all attributes, but just search the first
>         one it can read.
>         As it finds none of them you get the message for all
>         attributes.

Right, but why iterate through all possible attributes? It should only
iterate through the attributes requested. Whether the user can read a
non-requested attribute or not is irrelevant because the attribute was
not requested.