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

[Nathaniel McCallum]

On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote:
> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:
> > 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?
> Good question... I will  try to reproduce

Thanks!

> >>> 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.
> I think it is iterating from the attributes in the entry. Searching the 
> first one that the authenticated subject is allowed to read.

I agree. The question is: why?

Nathaniel