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. 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. 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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
