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

[thierry bordaz]

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
>
>>> 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.

thanks
thierry