On Mon, Nov 12, 2018 at 6:28 PM François Cami via FreeIPA-devel <[email protected]> wrote: > > Hi, > > While investigating why non-admin users having access to a shared > vault got an error that stemmed from them not being able to find the > KRA server to query (*), I found out that by changing the ldapsearch > query normal users could, in fact, get the list of KRA servers. > > (*) https://pagure.io/freeipa/issue/7691 > > E.g. the query built from select_any_master(ldap2, service='CA') does > not return any server when run by a non-admin user: > ############## > # ldapsearch -Y GSSAPI -b > cn=masters,cn=ipa,cn=etc,dc=laptop,dc=example,dc=org > '(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=KRA))' > (...) > ############## > > but removing (ipaConfigString=enabledService) from the query works: > ############## > # ldapsearch -Y GSSAPI -b > cn=masters,cn=ipa,cn=etc,dc=laptop,dc=example,dc=org > '(&(objectClass=ipaConfigObject)(cn=KRA))' > # KRA, idm0.laptop.example.org, masters, ipa, etc, laptop.example.org > dn: cn=KRA,cn=idm0.laptop.example.org,cn=masters,cn=ipa,cn=etc,dc=laptop,dc=ex > ample,dc=org > objectClass: nsContainer > objectClass: ipaConfigObject > objectClass: top > cn: KRA > ############## > > So it looks like once we're past logging an exception when we can't > find a KRA master ( https://github.com/freeipa/freeipa/pull/2553 ), we > have to decide what to do: > * should users be able to see more data in LDAP by default - it looks > like by using ldapsearch they already can find the information they > need anyway - so allow all users to read status of services
After the ping on IRC I gave it bit more thought I'd actually prefer to allow reading of ipaconfig string attr to all authenticated users as I don't think we are revealing any new information and it would make logic simpler and would support possible RFE of standby replica. Some thinking behind it, maybe I have missed something: If a service is present is visible by the presence of the container, e.g. KRA(as pointed out by Francois) - this is done via permission "Read access to masters" bind to all. For values which are stored in ipaConfigString: * enabledService - IPA doesn't support uninstallation, so except for interim state in install this will be mostly present in each service container and can be mostly read from SRV records + it's the point of all this. * startOrder - this information is not interesting and all servers should have the same value * dnssecVersion 1 - I think it can be inferred from DNS * caRenewalMaster - I don't know exactly how this attr is being consumed by a consumer but we also announce all CA servers and it is clear that it is one of them. Also readable by all IPA managed hosts (as any ipaConfigString in masters tree). * kdcProxyEnabled - enabled by default * pkinitEnabled - is obtainable via another way > OR > * add "System: Read Status of Services on IPA Servers" only to users > which should be able to use Vault (as originally suggested by Petr) > OR > * or update select_any_master()'s search logic so that if the first > query fails, we retry without (ipaConfigString=enabledService) > > Essentially we are revisiting https://pagure.io/freeipa/issue/3566 > (thanks Florence for pointing that out!). > > Input please? > > Cheers > François > _______________________________________________ > FreeIPA-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat _______________________________________________ FreeIPA-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
