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

[Simo Sorce]

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 ?

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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York