[Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
thierry bordaz
tbordaz at redhat.com
Thu Oct 9 20:22:13 UTC 2014
On 10/09/2014 06:40 PM, Nathaniel McCallum wrote:
> On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote:
>> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:
>>> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:
>>>> 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.
>>> Agreed and understood.
>>>
>>>> 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".
>>> Correct.
>>>
>>>> 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")
>>>> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)
>>> Correct.
>>>
>>>> Do you know if the target entry has 'ipatokenOwner' or
>>>> 'managedBy' with the binddn value ?
>>> Yes, both. So why is access to objectClass (et cetera) being denied?
>> Good question... I will try to reproduce
> Thanks!
Hello,
I tried to reproduce and it seems to work on *master*.
I am using the attached ldif file.
The test case is to bind as "cn=active
guy,cn=accounts,dc=example,dc=com" and to do a modify on "cn=active
otp,cn=otp,dc=example,dc=com".
The modify updates the 'description' attribute and do a postread
(description, cn).
The write 'description' is allowed by :
dn: cn=otp,dc=example,dc=com
aci: (targetfilter =
"(objectclass=organizationalPerson)")(target = "ldap:///c
n=*,cn=otp,dc=example,dc=com")(targetattr = "objectclass ||
description || se
eAlso")(version 3.0; acl "Active user modify otp entry"; allow
(write) userdn
= "ldap:///cn=active guy,cn=accounts,dc=example,dc=com";)
[09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW
aci(19) " "Active user modify otp entry""
[09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main):
Allow write on entry(cn=active
otp,cn=otp,dc=example,dc=com).attr(description) to cn=active
guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname=
"Active user modify otp entry", acidn="cn=otp,dc=example,dc=com"
The postread is allowed by:
dn: cn=otp,dc=example,dc=com
aci: (targetfilter = "(objectclass=organizationalPerson)")
(targetattr = "obje
ctclass || description || seeAlso || cn")(version 3.0; acl
"Active user can r
ead his entries"; allow (read, search, compare) userattr =
"seeAlso#USERDN";)
[09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW
aci(21) " "Active user can read his entries""
[09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache
[09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main):
Allow read on entry(cn=active
otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active
guy,cn=accounts,dc=example,dc=com: cached allow by aci(21)
The postread works if I use USERDN or SELFDN.
Please let me know the version of 389-ds that you are testing, I
will try on that branch
thanks
thierry
>
>>>>> 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.
>>> Right, but why iterate through all possible attributes? It should only
>>> iterate through the attributes requested. Whether the user can read a
>>> non-requested attribute or not is irrelevant because the attribute was
>>> not requested.
>> I think it is iterating from the attributes in the entry. Searching the
>> first one that the authenticated subject is allowed to read.
> I agree. The question is: why?
>
> Nathaniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141009/7b18b396/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctrl.ldif
Type: text/x-ldif
Size: 6643 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141009/7b18b396/attachment.bin>
More information about the Freeipa-devel
mailing list