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

[Ludwig Krispenz]

On 10/09/2014 05:51 PM, Nathaniel McCallum wrote:
> On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote:
>> On 10/09/2014 04:27 PM, Simo Sorce wrote:
>>> On Thu, 09 Oct 2014 16:06:06 +0200
>>> Ludwig Krispenz <lkrispen at redhat.com> wrote:
>>>
>>>> On 10/09/2014 03:13 PM, Simo Sorce wrote:
>>>>> On Wed, 08 Oct 2014 17:46:01 -0400
>>>>> Nathaniel McCallum <npmccallum at redhat.com> 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
>>>>>>
>>>>>> 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.
>>>>> Can you show an example ldif ?
>>>>> I wonder if you are setting the owner ?
> This is the ldif I used:
> dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com
> changetype: add
> objectClass: top
> objectClass: ipaToken
> objectClass: ipaTokenHOTP
> ipatokenUniqueID: autogenerate
> ipatokenOTPalgorithm: sha1
> ipatokenOTPdigits: 6
> ipatokenOTPkey: 00000000
> ipatokenHOTPcounter: 0
> ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com
> managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com
>
>>>>>> 2. The second patch (0002) modifies the ACI for normal user token
>>>>>> addition from this:
>>>>>>
>>>>>> aci: (target =
>>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter =
>>>>>> "(objectClass=ipaToken)")(version 3.0; acl "Users can create
>>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN"
>>>>>> and userattr = "managedBy#SELFDN";)
>>>>>>
>>>>>> To this:
>>>>>>
>>>>>> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
>>>>>> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
>>>>>> "Users can create self-managed tokens"; allow (add) userattr =
>>>>>> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
>>>>>>
>>>>>> The idea is to allow users to create tokens which will be expanded
>>>>>> by the UUID plugin. Unfortunately, after the UUID is expanded, the
>>>>>> ACIs are checked. Since the expanded UUID no longer matches the
>>>>>> ACI, the addition is denied. Is this truly the correct behavior? I
>>>>>> would think that the ACIs would be checked before the UUID plugin,
>>>>>> not after.
>>>>> I would expect the same, can someone on the DS team comment ?
>>>> acis are always applied before the entry is sent to the client. the
>>>> control is added when the result is sent and for the postop control
>>>> it gets the POST_OP entry and checks read access to teh entry
>>> So you think the whole add was denied because the post-read couldn't
>>> read back the entry ?
>> as far as I understood Nathaniel, the add succeeded, only the control
>> was not returned
>>> Then fixing the read-related issue is all we need ?
>> you need an aci allowing to read the postop entry
> No. Issue #2 is unrelated to issue #1. In issue #2, the add itself
> fails.
is this because of the change from tokenuiqieid=* to 
tokenuniqueid=autogenerate in the aci, why not stick to*
>