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

[Ludwig Krispenz]

On 10/09/2014 06:32 PM, 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... 
+1
could you post the full aci logging not only the summary for the access 
to the attributes ?
> 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
>