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

[Simo Sorce]

On Thu, 09 Oct 2014 16:33:20 +0200
Ludwig Krispenz <lkrispen at redhat.com> 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 ?
> >>>
> >>>> 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

Btw we could add userattr = creatorsName#SELFDN" to the read ACI so that
ipatokenOwner/managedby are not strictly needed for post-read ?
Does it make sense to do ?

Simo.

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