On Fri, 2014-01-10 at 13:29 +0100, Martin Kosek wrote: > 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.
Yes technically it works like this, but if the junior admin has root privs on the host listed in managedby then it is just like you gave managedby to the junior admin. > > > > 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. Right, which is limiting, already, we can start with an all or nothing thing for now, but it must not prevent us extending this functionality so that an admin can be granted permission only for a restricted set of hosts. > > 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. Sure. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
