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

[Martin Kosek]

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 at 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