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

[Nathaniel McCallum]

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.

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 --------------
A non-text attachment was scrubbed...
Name: 0002-Use-UUID-plugin-to-generate-ipaTokenUniqueIDs.patch
Type: text/x-patch
Size: 10997 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141008/f0ce40d0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-post-read-control-to-get-new-DN-after-add.patch
Type: text/x-patch
Size: 2447 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141008/f0ce40d0/attachment-0001.bin>
-------------- next part --------------
[08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(objectClass) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"
[08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPalgorithm) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"
[08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPdigits) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"
[08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPkey) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"
[08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenHOTPcounter) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"
[08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOwner) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"
[08/Oct/2014:16:54:40 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"
[08/Oct/2014:16:54:40 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenUniqueID) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"