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

[thierry bordaz]

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

    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")
    (version3.0;  acl"Users/managers can read basic token info";  allow(read,  search,  compare)  userattr=  "ipatokenOwner#USERDN"  or userattr=  "managedBy#USERDN";)|


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


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

    thanks
    thierry

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141009/d83c1e9e/attachment.htm>