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 ?
I'd rather not. This would allow a rogue admin to create a cert for
www.google.com. Sure, they could also create a host for that but forcing
them to add more entries increases the chances of them getting caught
doing it.
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...
Right. I think I mentioned yesterday that there is currently no special
permission for issuing SAN certs (at least partly because we don't
actually do it). Adding a rule for this should be fairly straightforward
and I think should be part of any effort to enable SAN certs.
Doing the ACI will require a bit of work since currently there is a 1-1
relationship between a command and an ACI right now (via
self.check_access()). It shouldn't be too much work to be able to pass
in another ACI to check though.
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.
Yup. If the host can't manage all the hosts in the SAN then renewal will
be rejected.
rob
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
