[Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile

[Simo Sorce]

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