On 01/09/2014 03:37 PM, Simo Sorce wrote: > On Thu, 2014-01-09 at 15:27 +0100, Martin Kosek wrote: >> On 01/09/2014 03:12 PM, Simo Sorce wrote: >>> On Thu, 2014-01-09 at 09:04 -0500, Simo Sorce wrote: >>>> On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote: >>>>> On 01/09/2014 12:26 AM, Simo Sorce wrote: >>>>>> On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patch fixes <https://fedorahosted.org/freeipa/ticket/3977>. >>>>>> >>>>>> See the additional comments on 3977, I think this patch should be NACKed >>>>>> with extreme prejudice if it allows setting arbitrary subjectAltNames. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> It does not allow them - SANs are being authorized by using the managedBy >>>>> attribute on the SAN-ed host/service (i.e. >>>>> host-add-managedby/service-add-host >>>>> commands). >>>> >>>> This means that in order to add a subjectAltName you have to register a >>>> Host with that name ? That is not really convenient, but if it works at >>>> least it properly constrains potential hijacking. >> >> Right. The host does not need to even be enrolled to make this work. But it >> is >> still better to make it this way that to allow hosts to request SANs. >> >>>> >>>>> But you are right that the authorization part should not be taken lightly >>>>> and >>>>> should be verified before we allow SANs in default profile. I added a >>>>> comment >>>>> in the Trac as well. >>>> >>>> Yes we definitely need a test to make 100% sure this cannot be worked >>>> around, the security consequences would be disastrous. >> >> +1 >> >>>> Also maybe we should allow admins to bypass the need to have an actual >>>> object to represent the alt name ? >> >> cert requests issued by admin can bypass this check, it is only applied to >> principals starting with "host/", i.e. for example to certs renewed by >> certmonger. >> >> Other requests are authorized differently. cert-request is a VirtualCommand >> and >> people are authorized by checking if they have a write access to the >> appropriate virtual operation LDAP entry, living in cn=virtual >> operations,cn=etc,SUFFIX... Which is by default only the admins group members >> which have the god-like special ACI we discussed yesterday. Rob is that >> correct? You also participated in the VirtualCommand coding... > > The situation sounds sub-optimal, I would think that giving managedby to > a 'junior-admin' user would allow him to also fetch certs but only for > the machines they manage.
I sense some confusion here. You do not give managedby to a junior admin. You set managedby to a host or service. Example: ipa host-add lowsecure.example.com ipa host-add highsecure.example.com ipa host-add-managedby highsecure.example.com --hosts lowsecure.example.com Then host/lowsecure.example.com@REALM can request cert with SAN highsecure.example.com. > > Is the Virtual Permission an all or nothing thing ? or can it be scoped > to group of machines ? If the latter, fine, if not, not so much. Not really. But this pain is shared also in the standard permissions. "Modify hosts" permission also means all or nothing. > Although, if the junior-admin can gain root on the host, he can still > get certs using the host/ key so maybe that is not fundamental, but it > would need clear documentation on how to allow a less privileged admin > to perform these functions. > >>>> We will need this type of functionality if we want to allow admins to >>>> create wildcard certificates anyway, which is another important use case >>>> for hosting/cloud-like services. >>> >>> >>> I was also thinking admins may want to allow a lower privileged admin to >>> manage a host, but not allow them to add a special subjectaltname to >>> random other hosts he manages. In this case again we need the ability >>> for an admin to be able to provide the cert to the host. Also then a >>> special case arises on automatic renew from certmonger, all names need >>> to be checked against the old certificate being renewed, so >>> authorization in that case would have to be based on the previous cert >>> names and not on managedby, right ? >>> If not automatic renewal would fail ? >> >> Hmm, the renewal would fail in this case. admin would have to request new >> certificate manually in this case (when mangedby attribute is not set >> properly). Previous certificate is not checked by the cert-request >> authorization code. > > I think the renewal problem is more important. Failing renewals cripples > one of the most important features of using FreeIPA as your CA for > enrolled hosts. > > Simo. > I am still not sure if there is not a confusion about the managedby attribute. If you have an admin of lowsecure.example.com + have the managedby attributes on other hosts correctly, local admin/certmonger on lowsecure.example.com can still happily request or renew cert with the approved SANs. Martin _______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel