On Wed, Mar 23, 2016 at 04:37:43PM +1100, a.fed...@earsdown.com wrote: > Some excellent points, and thank you for being open to having the > conversation - I know you don't have to, and it is appreciated. > > > Profiles which are allowed for a host principal (representing > > physical or virtual machines) are not necessarily the same > > profiles that should be used for service principals. This is > > why CA ACLs must be executed against the issuee principal. > > > Certmonger uses the host credential (from the host keytab) to make > all requests on behalf of all service principals of a given > machine, right? > That's correct.
> So if that machine is compromised then so too are > all keys/certificates issued to that machine. If I think a machine > is more likely to become compromised, I'd want to lock down the > Certificate Profiles available to that whole machine. > Protecting keys is a separate issue from the the CA being able to answer the question "can I issue certs to principal P using profile X?". > Even if I > end up using different profiles for different services on the same > machine, I'm still forced to trust certmonger to use the right > profile for each request. > CA ACLs are stored and evaluated on the IPA server. If Certmonger uses the "wrong profile for a request", the worst that will happen is CA ACL enforcement will deny the request. I do not see how any special trust resides in Certmonger in this scenario. > So, even with future sub-CAs (this excites me btw), I'm just not > sure I understand the security benefit of evaluating CA ACLs > against the subject/issuee of the request, when (as you say) > directory ACIs are already doing this. > Directory ACIs govern which principals can request a certificate on behalf of a subject principal. CA ACLs govern which profile(s) are valid for such a request. These are quite different things, and both are important. (I'm glad you're excited about sub-CA support; I am too!) > Lets look at this from another angle. Suppose I obtain a service > keytab for my unprivileged web application (say > HTTP/myapp01.example.com), which is needed to authenticate web > clients via kerberos/gssapi. The app also needs x509 certificates > for TLS, which is handled by certmonger. Given the current > approach of CA ACLs, it would be possible for my unprivileged > web-app (if it were to become compromised) to use its service > keytab to request certificates from IPA directly, which is > undesirable, but I'd have no way of stopping it. > The same is true for rogue user or host credentials. The scope is even bigger for compromised host credentials, since a host principal can request certificates both for itself and for any services it manages. > I'm even more curious about how I'd explain and justify this > behaviour to clients. It's confusing, you know? > I am open to any ideas about how to explain this more clearly. The best approach I can think of is to explain that CA ACLs are about answering, "what kinds of certificate can the CA issue to subject principal 'P'?", and emphasising that that is a very different question from, "who can request a certificate on behalf of subject principal 'P'?". Thanks, Fraser > Cheers > > > On 23 Mar 2016, at 09:48, Fraser Tweedale <ftwee...@redhat.com> > > wrote: > > > >> On Tue, Mar 22, 2016 at 10:57:37PM +1100, earsdown wrote: Hi > >> Fraser, Martin and Alexander, > >> > >> Thanks for looking into this! For what it's worth, I think for > >> this particular use case, I'm leaning more towards Alexander > >> when he said: > >> > >>> I don't think you need to group services this way. For > >>> managing services, and this means being able to issue > >>> certificates/keytabs for them, we have hosts. By default a > >>> host that a service belongs to is capable to modify > >>> userCertificate attribute of the service already, so I would > >>> expect it to be able to issue certificates with subject > >>> principal corresponding to the service. > >> > >>> If CAACL would follow the same logic by allowing hosts that > >>> manage services to issue certificates with subject principals > >>> corresponding to these services, that should be enough > >>> because, after all, these host objects already have write > >>> permissions and can upload whatever certificates they like to > >>> the service objects. -- / Alexander Bokovoy > >> > >> Personally, I was very surprised when I discovered that, even > >> though a host principal may manage a service principal, it is > >> currently unable to request a certificate for that service > >> principal if the service principal doesn't have specific access > >> to the certificate profile, even though the host principal may > >> have access to the same certificate profile. In my mind the CA > >> ACL should be evaluated against the identity of the requestor, > >> not the issuee. As long as the requestor is allowed to request > >> on behalf of the issuee (achieved via the managedby attribute), > >> then it should work. Now, if I used the credentials of the > >> service principal directly (say, with a service keytab) to make > >> the request (supposing the service principal wasn't listed in > >> the CA ACL), then denying the request would be the expected > >> behaviour (imo of course). > >> > >> Okay, so even though Alexander's suggestion might be more > >> intuitive, implementing service groups might be more feasible > >> from a technical standpoint, and I'm fairly sure this use case > >> would also be solved by implementing service groups. But, it > >> would be painful without automember regexp rules, so please > >> don't forget this :D > >> > >> Cheers! > > The CA ACLs solve a different part of the authorisation puzzle > > for certificates: what profiles (or, in the future, (sub-)CAs) > > may be used to issue certs to a given subject is a different > > question from which entities can request certificates on behalf > > of the subject. Profiles which are allowed for a host principal > > (representing physical or virtual machines) are not necessarily > > the same profiles that should be used for service principals. > > This is why CA ACLs must be executed against the issuee > > principal. > > > > It is best to implement service groups then support them in CA > > ACLs. > > > > Final note: directory ACIs allow hosts to request certificates > > for services they manage. The overall authorisation for cert > > issuance depends on *both* the directory ACIs and CA ACLs. > > > > Cheers, Fraser > > > >>> On 2016-03-22 20:50, Fraser Tweedale wrote: > >>>> On Tue, Mar 22, 2016 at 09:59:58AM +0100, Martin Kosek wrote: > >>>>> On 03/22/2016 05:55 AM, Fraser Tweedale wrote: On Fri, Mar > >>>>> 18, 2016 at 08:12:44PM +1100, earsdown wrote: > >>>> ... > >>>>> To my fellow FreeIPA developers: are service groups a > >>>>> sensible RFE? Is there a reason why they have not been > >>>>> implemented? > >>>> > >>>> It *is* sensible RFE and it was actually already filed! > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/5277 > >>>> > >>>> Please feel free to add yourself to CC to receive updates or > >>>> even help us with implementation. > >>>> > >>>> Thanks, Martin > >>> Good to know... I've added myself to Cc and also filed an RFE > >>> for enhancing CA ACLs with service groups once #5277 is > >>> implemented: https://fedorahosted.org/freeipa/ticket/5753 > >>> > >>> Cheers, Fraser > >> > >> -- Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users Go to > >> http://freeipa.org for more info on the project > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
