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

[Simo Sorce]

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 ?
> >
> >> 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 ?
Then fixing the read-related issue is all we need ?

Simo.


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