Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
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). 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. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Objectclasses for target filters in default permissions
Hello, When I'm done with [#4074], the type permissions will use a target filter, e.g.: ipa permission-add \ 'Modify Account Expiration' \ --attr=krbPrincipalExpiration \ --type=user --perm=write should result in this ACI at cn=users,...: (targetattr = krbPrincipalExpiration) (targetfilter = (objectclass=ipauser)) (version 3.0; acl permission:Modify Account Expiration; allow (write) groupdn = ldap:///cn=Modify Account Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com;) The probjem is matching the user type with the ipauser objectclass. I've looked, but I don't think we have such canonical objectclasses defined anywhere in the code. There is object_class and possible_objectclasses for each object type in the plugins, but these aren't adequate: user has posixaccount; some have multiple objectclasses listed (even `top` in one case). (Of course it's not a problem to add multiple classes to the filter, it just seems superfluous.) I'd like to add a new attribute to LDAPObject that lists the objectclass(es) for permission filters. This would also mean the list of allowed `type`s for permissions can be pulled from the plugins, rather than being hardcoded in the aci/permission plugin. Here's a list of proposed classes, and the existing lists for reference: user: proposed for filter: ipauser object_class: posixaccount possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser, ipatokenradiusproxyuser group: proposed for filter: ipausergroup object_class: ipausergroup possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup host: proposed for filter: ipahost object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice possible_objectclasses: (none) service: proposed for filter: ipaservice object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject, ipaservice, pkiuser possible_objectclasses: ipakrbprincipal hostgroup: proposed for filter: ipahostgroup object_class: ipaobject, ipahostgroup possible_objectclasses: (none) netgroup: proposed for filter: ipanisnetgroup object_class: ipaobject, ipaassociation, ipanisnetgroup possible_objectclasses: (none) dnsrecord: proposed for filter: idnsrecord object_class: top, idnsrecord possible_objectclasses: (none) [#4074]: https://fedorahosted.org/freeipa/ticket/4074 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Objectclasses for target filters in default permissions
On 01/09/2014 01:15 PM, Petr Viktorin wrote: Hello, When I'm done with [#4074], the type permissions will use a target filter, e.g.: ipa permission-add \ 'Modify Account Expiration' \ --attr=krbPrincipalExpiration \ --type=user --perm=write should result in this ACI at cn=users,...: (targetattr = krbPrincipalExpiration) (targetfilter = (objectclass=ipauser)) (version 3.0; acl permission:Modify Account Expiration; allow (write) groupdn = ldap:///cn=Modify Account Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com;) The probjem is matching the user type with the ipauser objectclass. I've looked, but I don't think we have such canonical objectclasses defined anywhere in the code. There is object_class and possible_objectclasses for each object type in the plugins, but these aren't adequate: user has posixaccount; some have multiple objectclasses listed (even `top` in one case). (Of course it's not a problem to add multiple classes to the filter, it just seems superfluous.) I'd like to add a new attribute to LDAPObject that lists the objectclass(es) for permission filters. This would also mean the list of allowed `type`s for permissions can be pulled from the plugins, rather than being hardcoded in the aci/permission plugin. Sounds like a good idea. Here's a list of proposed classes, and the existing lists for reference: user: proposed for filter: ipauser object_class: posixaccount possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser, ipatokenradiusproxyuser Not sure about this one. ipauser is only given to the new users, after ipausers was introduced, right? In this case, posixaccount may be a better choice. group: proposed for filter: ipausergroup object_class: ipausergroup possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup host: proposed for filter: ipahost object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice possible_objectclasses: (none) service: proposed for filter: ipaservice object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject, ipaservice, pkiuser possible_objectclasses: ipakrbprincipal hostgroup: proposed for filter: ipahostgroup object_class: ipaobject, ipahostgroup possible_objectclasses: (none) netgroup: proposed for filter: ipanisnetgroup object_class: ipaobject, ipaassociation, ipanisnetgroup possible_objectclasses: (none) dnsrecord: proposed for filter: idnsrecord object_class: top, idnsrecord possible_objectclasses: (none) Looks good to me. You also missed some other non-account object like SUDO or HBAC, but it should be easy there as they usually have a ipa* canonical base objectclass, i.e. ipahbacrule, ipahbacservice, ipahbacservicegroup, ipaselinuxusermap, ipasudocmd, ipasudocmdgrp, ipasudorule, ipaNTTrustedDomain. Just the pwpolicy object do now have our own objectclass, but I think we could work with costemplate and krbpwdpolicy objectclasses. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Objectclasses for target filters in default permissions
On 01/09/2014 02:02 PM, Martin Kosek wrote: On 01/09/2014 01:15 PM, Petr Viktorin wrote: Hello, When I'm done with [#4074], the type permissions will use a target filter, e.g.: ipa permission-add \ 'Modify Account Expiration' \ --attr=krbPrincipalExpiration \ --type=user --perm=write should result in this ACI at cn=users,...: (targetattr = krbPrincipalExpiration) (targetfilter = (objectclass=ipauser)) (version 3.0; acl permission:Modify Account Expiration; allow (write) groupdn = ldap:///cn=Modify Account Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com;) The probjem is matching the user type with the ipauser objectclass. I've looked, but I don't think we have such canonical objectclasses defined anywhere in the code. There is object_class and possible_objectclasses for each object type in the plugins, but these aren't adequate: user has posixaccount; some have multiple objectclasses listed (even `top` in one case). (Of course it's not a problem to add multiple classes to the filter, it just seems superfluous.) I'd like to add a new attribute to LDAPObject that lists the objectclass(es) for permission filters. This would also mean the list of allowed `type`s for permissions can be pulled from the plugins, rather than being hardcoded in the aci/permission plugin. Sounds like a good idea. Here's a list of proposed classes, and the existing lists for reference: user: proposed for filter: ipauser object_class: posixaccount possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser, ipatokenradiusproxyuser Not sure about this one. ipauser is only given to the new users, after ipausers was introduced, right? In this case, posixaccount may be a better choice. OK group: proposed for filter: ipausergroup object_class: ipausergroup possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup host: proposed for filter: ipahost object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice possible_objectclasses: (none) service: proposed for filter: ipaservice object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject, ipaservice, pkiuser possible_objectclasses: ipakrbprincipal hostgroup: proposed for filter: ipahostgroup object_class: ipaobject, ipahostgroup possible_objectclasses: (none) netgroup: proposed for filter: ipanisnetgroup object_class: ipaobject, ipaassociation, ipanisnetgroup possible_objectclasses: (none) dnsrecord: proposed for filter: idnsrecord object_class: top, idnsrecord possible_objectclasses: (none) Looks good to me. You also missed some other non-account object like SUDO or HBAC, but it should be easy there as they usually have a ipa* canonical base objectclass, i.e. ipahbacrule, ipahbacservice, ipahbacservicegroup, ipaselinuxusermap, ipasudocmd, ipasudocmdgrp, ipasudorule, ipaNTTrustedDomain. Well, I've only listed what is allowed in permissions' --type option now. We can add others as we design read permissions for them. Just the pwpolicy object do now have our own objectclass, but I think we could work with costemplate and krbpwdpolicy objectclasses. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
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. 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. Also maybe we should allow admins to bypass the need to have an actual object to represent the alt name ? 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. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Objectclasses for target filters in default permissions
On Thu, 2014-01-09 at 13:15 +0100, Petr Viktorin wrote: Hello, When I'm done with [#4074], the type permissions will use a target filter, e.g.: ipa permission-add \ 'Modify Account Expiration' \ --attr=krbPrincipalExpiration \ --type=user --perm=write should result in this ACI at cn=users,...: (targetattr = krbPrincipalExpiration) (targetfilter = (objectclass=ipauser)) (version 3.0; acl permission:Modify Account Expiration; allow (write) groupdn = ldap:///cn=Modify Account Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com;) The probjem is matching the user type with the ipauser objectclass. I've looked, but I don't think we have such canonical objectclasses defined anywhere in the code. There is object_class and possible_objectclasses for each object type in the plugins, but these aren't adequate: user has posixaccount; some have multiple objectclasses listed (even `top` in one case). (Of course it's not a problem to add multiple classes to the filter, it just seems superfluous.) I'd like to add a new attribute to LDAPObject that lists the objectclass(es) for permission filters. This would also mean the list of allowed `type`s for permissions can be pulled from the plugins, rather than being hardcoded in the aci/permission plugin. Sounds reasonable, I trust the objetclass can be manually changed anyway if an admin needs to do so ? Simo. Here's a list of proposed classes, and the existing lists for reference: user: proposed for filter: ipauser object_class: posixaccount possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser, ipatokenradiusproxyuser group: proposed for filter: ipausergroup object_class: ipausergroup possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup host: proposed for filter: ipahost object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice possible_objectclasses: (none) service: proposed for filter: ipaservice object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject, ipaservice, pkiuser possible_objectclasses: ipakrbprincipal hostgroup: proposed for filter: ipahostgroup object_class: ipaobject, ipahostgroup possible_objectclasses: (none) netgroup: proposed for filter: ipanisnetgroup object_class: ipaobject, ipaassociation, ipanisnetgroup possible_objectclasses: (none) dnsrecord: proposed for filter: idnsrecord object_class: top, idnsrecord possible_objectclasses: (none) [#4074]: https://fedorahosted.org/freeipa/ticket/4074 -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
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. 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. Also maybe we should allow admins to bypass the need to have an actual object to represent the alt name ? 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 ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Objectclasses for target filters in default permissions
On 01/09/2014 03:07 PM, Simo Sorce wrote: On Thu, 2014-01-09 at 13:15 +0100, Petr Viktorin wrote: Hello, When I'm done with [#4074], the type permissions will use a target filter, e.g.: ipa permission-add \ 'Modify Account Expiration' \ --attr=krbPrincipalExpiration \ --type=user --perm=write should result in this ACI at cn=users,...: (targetattr = krbPrincipalExpiration) (targetfilter = (objectclass=ipauser)) (version 3.0; acl permission:Modify Account Expiration; allow (write) groupdn = ldap:///cn=Modify Account Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com;) The probjem is matching the user type with the ipauser objectclass. I've looked, but I don't think we have such canonical objectclasses defined anywhere in the code. There is object_class and possible_objectclasses for each object type in the plugins, but these aren't adequate: user has posixaccount; some have multiple objectclasses listed (even `top` in one case). (Of course it's not a problem to add multiple classes to the filter, it just seems superfluous.) I'd like to add a new attribute to LDAPObject that lists the objectclass(es) for permission filters. This would also mean the list of allowed `type`s for permissions can be pulled from the plugins, rather than being hardcoded in the aci/permission plugin. Sounds reasonable, I trust the objetclass can be manually changed anyway if an admin needs to do so ? Simo. Yes, `type` is just a convenience shortcut to set the location + filter, which can be manipulated individually. Removing the objectclass filter would make the permission no longer show up as that `type`. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Objectclasses for target filters in default permissions
On Thu, 2014-01-09 at 15:14 +0100, Petr Viktorin wrote: On 01/09/2014 03:07 PM, Simo Sorce wrote: On Thu, 2014-01-09 at 13:15 +0100, Petr Viktorin wrote: Hello, When I'm done with [#4074], the type permissions will use a target filter, e.g.: ipa permission-add \ 'Modify Account Expiration' \ --attr=krbPrincipalExpiration \ --type=user --perm=write should result in this ACI at cn=users,...: (targetattr = krbPrincipalExpiration) (targetfilter = (objectclass=ipauser)) (version 3.0; acl permission:Modify Account Expiration; allow (write) groupdn = ldap:///cn=Modify Account Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com;) The probjem is matching the user type with the ipauser objectclass. I've looked, but I don't think we have such canonical objectclasses defined anywhere in the code. There is object_class and possible_objectclasses for each object type in the plugins, but these aren't adequate: user has posixaccount; some have multiple objectclasses listed (even `top` in one case). (Of course it's not a problem to add multiple classes to the filter, it just seems superfluous.) I'd like to add a new attribute to LDAPObject that lists the objectclass(es) for permission filters. This would also mean the list of allowed `type`s for permissions can be pulled from the plugins, rather than being hardcoded in the aci/permission plugin. Sounds reasonable, I trust the objetclass can be manually changed anyway if an admin needs to do so ? Simo. Yes, `type` is just a convenience shortcut to set the location + filter, which can be manipulated individually. Removing the objectclass filter would make the permission no longer show up as that `type`. The question I think was more nuanced. Will we allow the creation of custom permissions for UI/CLI ? In that case will the admin be able to just provide a custom objectclass name ? I guess the answer is yes, but just checking. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Objectclasses for target filters in default permissions
On 01/09/2014 03:20 PM, Simo Sorce wrote: On Thu, 2014-01-09 at 15:14 +0100, Petr Viktorin wrote: On 01/09/2014 03:07 PM, Simo Sorce wrote: On Thu, 2014-01-09 at 13:15 +0100, Petr Viktorin wrote: Hello, When I'm done with [#4074], the type permissions will use a target filter, e.g.: ipa permission-add \ 'Modify Account Expiration' \ --attr=krbPrincipalExpiration \ --type=user --perm=write should result in this ACI at cn=users,...: (targetattr = krbPrincipalExpiration) (targetfilter = (objectclass=ipauser)) (version 3.0; acl permission:Modify Account Expiration; allow (write) groupdn = ldap:///cn=Modify Account Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com;) The probjem is matching the user type with the ipauser objectclass. I've looked, but I don't think we have such canonical objectclasses defined anywhere in the code. There is object_class and possible_objectclasses for each object type in the plugins, but these aren't adequate: user has posixaccount; some have multiple objectclasses listed (even `top` in one case). (Of course it's not a problem to add multiple classes to the filter, it just seems superfluous.) I'd like to add a new attribute to LDAPObject that lists the objectclass(es) for permission filters. This would also mean the list of allowed `type`s for permissions can be pulled from the plugins, rather than being hardcoded in the aci/permission plugin. Sounds reasonable, I trust the objetclass can be manually changed anyway if an admin needs to do so ? Simo. Yes, `type` is just a convenience shortcut to set the location + filter, which can be manipulated individually. Removing the objectclass filter would make the permission no longer show up as that `type`. Ah I forgot to mention this, sorry: For the default permissions (the ones that come with IPA), the admin won't be able to change the target at all. But any custom ones can be changed. The question I think was more nuanced. Will we allow the creation of custom permissions for UI/CLI ? In that case will the admin be able to just provide a custom objectclass name ? I guess the answer is yes, but just checking. Yes. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
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... 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. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
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 Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter
Hi,
Adds a parameter that represents a DateTime format using datetime.datetime
object from python's native datetime library.
In the CLI, accepts one of the following formats:
Accepts subset of values defined by ISO 8601:
%Y-%m-%dT%H:%M:%S
%Y-%m-%dT%H:%M
'%Y%m%dT%H:%M:%S'
'%Y%m%dT%H:%M'
Also accepts LDAP Generalized time in the following format:
'%Y%m%d%H%M%SZ'
As a simplification, it does not deal with timezone info and ISO 8601
values with timezone info (+-hhmm) are rejected. Values are expected
to be in the UTC timezone.
Values are saved to LDAP as LDAP Generalized time values in the format
'%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To avoid
confusion, in addition to subset of ISO 8601 values, the LDAP generalized
time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as this
is the
format user will see on the output).
Part of: https://fedorahosted.org/freeipa/ticket/3306
From 26a57febd0a1b920cb0857f3a12912bb69c82d90 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 9 Jan 2014 11:14:56 +0100
Subject: [PATCH 137/140] ipalib: Add DateTime parameter
Adds a parameter that represents a DateTime format using datetime.datetime
object from python's native datetime library.
In the CLI, accepts one of the following formats:
Accepts subset of values defined by ISO 8601:
%Y-%m-%dT%H:%M:%S
%Y-%m-%dT%H:%M
'%Y%m%dT%H:%M:%S'
'%Y%m%dT%H:%M'
Also accepts LDAP Generalized time without in the following format:
'%Y%m%d%H%M%SZ'
As a simplification, it does not deal with timezone info and ISO 8601
values with timezone info (+-hhmm) are rejected. Values are expected
to be in the UTC timezone.
Values are saved to LDAP as LDAP Generalized time values in the format
'%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To avoid
confusion, in addition to subset of ISO 8601 values, the LDAP generalized
time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as this is the
format user will see on the output).
Part of: https://fedorahosted.org/freeipa/ticket/3306
---
ipalib/__init__.py | 2 +-
ipalib/parameters.py | 45 +
ipalib/rpc.py| 14 --
ipapython/ipaldap.py | 3 +++
4 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/ipalib/__init__.py b/ipalib/__init__.py
index ab89ab77ec94603d242e56436021c9b6ed8663cb..5dfeab3326f0a7b77120f2ef560cf08e8b9aa704 100644
--- a/ipalib/__init__.py
+++ b/ipalib/__init__.py
@@ -886,7 +886,7 @@ from frontend import Command, LocalOrRemote, Updater, Advice
from frontend import Object, Method, Property
from crud import Create, Retrieve, Update, Delete, Search
from parameters import DefaultFrom, Bool, Flag, Int, Decimal, Bytes, Str, IA5Str, Password, DNParam, DeprecatedParam
-from parameters import BytesEnum, StrEnum, IntEnum, AccessTime, File
+from parameters import BytesEnum, StrEnum, IntEnum, AccessTime, File, DateTime
from errors import SkipPluginModule
from text import _, ngettext, GettextFactory, NGettextFactory
diff --git a/ipalib/parameters.py b/ipalib/parameters.py
index 757c185655bbe1b586fbf088256891a7e7558876..eb5d57fc8da3a1f3796abf6c9d08412ed2181dae 100644
--- a/ipalib/parameters.py
+++ b/ipalib/parameters.py
@@ -102,6 +102,7 @@ a more detailed description for clarity.
import re
import decimal
import base64
+import datetime
from xmlrpclib import MAXINT, MININT
from types import NoneType
@@ -1602,6 +1603,50 @@ class File(Str):
('noextrawhitespace', bool, False),
)
+class DateTime(Param):
+
+DateTime parameter type.
+
+Accepts subset of values defined by ISO 8601:
+%Y-%m-%dT%H:%M:%S
+%Y-%m-%dT%H:%M
+ '%Y%m%dT%H:%M:%S'
+ '%Y%m%dT%H:%M'
+
+Also accepts LDAP Generalized time without in the following format:
+ '%Y%m%d%H%M%SZ'
+
+Refer to the `man strftime` for the explanations for the %Y,%m,%d,%H.%M,%S.
+
+
+accepted_formats = ['%Y-%m-%dT%H:%M:%S',
+'%Y-%m-%dT%H:%M',
+'%Y%m%dT%H:%M:%S',
+'%Y%m%dT%H:%M',
+'%Y%m%d%H%M%SZ']
+
+type = datetime.datetime
+
+def _convert_scalar(self, value, index=None):
+if isinstance(value, datetime.datetime):
+return value
+elif isinstance(value, str) or isinstance(value, unicode):
+for date_format in self.accepted_formats:
+try:
+time = datetime.datetime.strptime(value, date_format)
+return time
+except ValueError:
+pass
+
+# If we get here, the strptime call did not succeed for any
+# the accepted formats, therefore raise error
+
+error = does not match any of accepted formats: %s % self.accepted_formats
+
+raise ValidationError(name=self.name,
+ value=value,
+
[Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI
Hi,
Adds a krbPrincipalExpiration attribute to the user class
in user.py ipalib plugin as a DateTime parameter.
Part of: https://fedorahosted.org/freeipa/ticket/3306
From 00691ffa8407f5059fde9b913e3a1253fe9a287e Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 9 Jan 2014 11:26:44 +0100
Subject: [PATCH 138/140] ipalib: Expose krbPrincipalExpiration in CLI
Adds a krbPrincipalExpiration attribute to the user class
in user.py ipalib plugin as a DateTime parameter.
Part of: https://fedorahosted.org/freeipa/ticket/3306
---
API.txt| 9 ++---
VERSION| 3 ++-
ipalib/plugins/user.py | 9 +++--
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/API.txt b/API.txt
index a6c3aed82370d690a678a034b0eea85d4f85b45f..e90cac0702cb9869a3864ff225383c5c37cd9231 100644
--- a/API.txt
+++ b/API.txt
@@ -3784,7 +3784,7 @@ output: Entry('result', type 'dict', Gettext('A dictionary representing an LDA
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
command: user_add
-args: 1,39,3
+args: 1,40,3
arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True)
option: Str('addattr*', cli_name='addattr', exclude='webui')
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
@@ -3801,6 +3801,7 @@ option: Str('ipasshpubkey', attribute=True, cli_name='sshpubkey', csv=True, mult
option: Str('ipatokenradiusconfiglink', attribute=True, cli_name='radius', multivalue=False, required=False)
option: Str('ipatokenradiususername', attribute=True, cli_name='radius_username', multivalue=False, required=False)
option: StrEnum('ipauserauthtype', attribute=True, cli_name='user_auth_type', csv=True, multivalue=True, required=False, values=(u'password', u'radius', u'otp'))
+option: DateTime('krbprincipalexpiration', attribute=True, cli_name='principal_expiration', multivalue=False, required=False)
option: Str('krbprincipalname', attribute=True, autofill=True, cli_name='principal', multivalue=False, required=False)
option: Str('l', attribute=True, cli_name='city', multivalue=False, required=False)
option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False, required=False)
@@ -3851,7 +3852,7 @@ output: Output('result', type 'bool', None)
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
command: user_find
-args: 1,49,4
+args: 1,50,4
arg: Str('criteria?', noextrawhitespace=False)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('carlicense', attribute=True, autofill=False, cli_name='carlicense', multivalue=False, query=True, required=False)
@@ -3871,6 +3872,7 @@ option: Str('initials', attribute=True, autofill=False, cli_name='initials', mul
option: Str('ipatokenradiusconfiglink', attribute=True, autofill=False, cli_name='radius', multivalue=False, query=True, required=False)
option: Str('ipatokenradiususername', attribute=True, autofill=False, cli_name='radius_username', multivalue=False, query=True, required=False)
option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=True, query=True, required=False, values=(u'password', u'radius', u'otp'))
+option: DateTime('krbprincipalexpiration', attribute=True, autofill=False, cli_name='principal_expiration', multivalue=False, query=True, required=False)
option: Str('krbprincipalname', attribute=True, autofill=False, cli_name='principal', multivalue=False, query=True, required=False)
option: Str('l', attribute=True, autofill=False, cli_name='city', multivalue=False, query=True, required=False)
option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, query=True, required=False)
@@ -3907,7 +3909,7 @@ output: ListOfEntries('result', (type 'list', type 'tuple'), Gettext('A list
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('truncated', type 'bool', None)
command: user_mod
-args: 1,40,3
+args: 1,41,3
arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True)
option: Str('addattr*', cli_name='addattr', exclude='webui')
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
@@ -3925,6 +3927,7 @@ option: Str('ipasshpubkey', attribute=True, autofill=False, cli_name='sshpubkey'
option: Str('ipatokenradiusconfiglink', attribute=True, autofill=False, cli_name='radius', multivalue=False, required=False)
option: Str('ipatokenradiususername', attribute=True, autofill=False, cli_name='radius_username', multivalue=False, required=False)
option: StrEnum('ipauserauthtype', attribute=True, autofill=False,
[Freeipa-devel] [PATCH 0139] acl: Remove krbPrincipalExpiration from list of excluded attrs
Hi, Since we're exposing the krbPrincipalExpiration attribute for direct editing in the CLI, remove it from the list of attributes that admin cannot edit by default. Part of: https://fedorahosted.org/freeipa/ticket/3306 From 7dbc0c10ecc473567c8c5e7de783c772e83efab5 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Thu, 9 Jan 2014 14:19:49 +0100 Subject: [PATCH 139/140] acl: Remove krbPrincipalExpiration from list of admin's excluded attrs Since we're exposing the krbPrincipalExpiration attribute for direct editing in the CLI, remove it from the list of attributes that admin cannot edit by default. Part of: https://fedorahosted.org/freeipa/ticket/3306 --- install/share/default-aci.ldif | 2 +- install/updates/60-trusts.update | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index 510ea32848ef0f51f67d8cca3e3c14351a4f..9af9ab28c72e35f7912795e5280170cc6e1bdd80 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -5,7 +5,7 @@ changetype: modify add: aci aci: (targetfilter = ((!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenRadiusConfiguration(target != ldap:///idnsname=*,cn=dns,$SUFFIX;)(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;) aci: (targetattr = memberOf || memberHost || memberUser)(version 3.0; acl No anonymous access to member information; deny (read,search,compare) userdn != ldap:///all;;) -aci: (targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || ipaUniqueId || memberOf || serverHostName || enrolledBy || ipaNTHash)(version 3.0; acl Admin can manage any entry; allow (all) groupdn = ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) +aci: (targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbTicketPolicyReference || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || ipaUniqueId || memberOf || serverHostName || enrolledBy || ipaNTHash)(version 3.0; acl Admin can manage any entry; allow (all) groupdn = ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) aci: (targetattr = userpassword || krbprincipalkey || sambalmpassword || sambantpassword)(version 3.0; acl selfservice:Self can write own password; allow (write) userdn=ldap:///self;;) aci: (targetattr = userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || ipaNTHash)(version 3.0; acl Admins can write passwords; allow (add,delete,write) groupdn=ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) aci: (targetfilter = (objectClass=krbPwdPolicy))(targetattr = krbMaxPwdLife || krbMinPwdLife || krbPwdMinDiffChars || krbPwdMinLength || krbPwdHistoryLength)(version 3.0;acl Admins can write password policies; allow (read, search, compare, write) groupdn = ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update index e0a289d449a17caa899a9a346b1b2d84c6b382ac..1fb3cc47c88189df4c45852aba67915c023f676d 100644 --- a/install/updates/60-trusts.update +++ b/install/updates/60-trusts.update @@ -37,7 +37,9 @@ remove:aci: '(targetattr = ipaNTHash)(version 3.0; acl Samba system principal replace:aci:'(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;)::(target != ldap:///idnsname=*,cn=dns,$SUFFIX;)(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;)' remove:aci:'(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases ||
[Freeipa-devel] [PATCH 0140] [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token
Hi,
For ipatokennotbefore and ipatokennotafter attributes use DateTime
parameter class instead of Str, since these are represented as
LDAP Generalized Time in LDAP.
Tomas
From cb671a7c1e746ef5f1c3de0e4ad30ae6ef42dcf1 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 9 Jan 2014 11:29:39 +0100
Subject: [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token
timestamp attributes
For ipatokennotbefore and ipatokennotafter attributes use DateTime
parameter class instead of Str, since these are represented as
LDAP Generalized Time in LDAP.
---
API.txt| 12 ++--
VERSION| 4 ++--
ipalib/plugins/otptoken.py | 10 +-
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/API.txt b/API.txt
index e90cac0702cb9869a3864ff225383c5c37cd9231..a150ba1f6b3c28da7a543e683ad433fabeb09b5e 100644
--- a/API.txt
+++ b/API.txt
@@ -2227,8 +2227,8 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui
option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False)
option: Bool('ipatokendisabled', attribute=True, cli_name='disabled', multivalue=False, required=False)
option: Str('ipatokenmodel', attribute=True, cli_name='model', multivalue=False, required=False)
-option: Str('ipatokennotafter', attribute=True, cli_name='not_after', multivalue=False, required=False)
-option: Str('ipatokennotbefore', attribute=True, cli_name='not_before', multivalue=False, required=False)
+option: DateTime('ipatokennotafter', attribute=True, cli_name='not_after', multivalue=False, required=False)
+option: DateTime('ipatokennotbefore', attribute=True, cli_name='not_before', multivalue=False, required=False)
option: StrEnum('ipatokenotpalgorithm', attribute=True, cli_name='algo', multivalue=False, required=False, values=(u'sha1', u'sha256', u'sha384', u'sha512'))
option: IntEnum('ipatokenotpdigits', attribute=True, cli_name='digits', multivalue=False, required=False, values=(6, 8))
option: OTPTokenKey('ipatokenotpkey', attribute=True, cli_name='key', multivalue=False, required=False)
@@ -2260,8 +2260,8 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui
option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False)
option: Bool('ipatokendisabled', attribute=True, autofill=False, cli_name='disabled', multivalue=False, query=True, required=False)
option: Str('ipatokenmodel', attribute=True, autofill=False, cli_name='model', multivalue=False, query=True, required=False)
-option: Str('ipatokennotafter', attribute=True, autofill=False, cli_name='not_after', multivalue=False, query=True, required=False)
-option: Str('ipatokennotbefore', attribute=True, autofill=False, cli_name='not_before', multivalue=False, query=True, required=False)
+option: DateTime('ipatokennotafter', attribute=True, autofill=False, cli_name='not_after', multivalue=False, query=True, required=False)
+option: DateTime('ipatokennotbefore', attribute=True, autofill=False, cli_name='not_before', multivalue=False, query=True, required=False)
option: StrEnum('ipatokenotpalgorithm', attribute=True, autofill=False, cli_name='algo', multivalue=False, query=True, required=False, values=(u'sha1', u'sha256', u'sha384', u'sha512'))
option: IntEnum('ipatokenotpdigits', attribute=True, autofill=False, cli_name='digits', multivalue=False, query=True, required=False, values=(6, 8))
option: Str('ipatokenowner', attribute=True, autofill=False, cli_name='owner', multivalue=False, query=True, required=False)
@@ -2289,8 +2289,8 @@ option: Str('delattr*', cli_name='delattr', exclude='webui')
option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False)
option: Bool('ipatokendisabled', attribute=True, autofill=False, cli_name='disabled', multivalue=False, required=False)
option: Str('ipatokenmodel', attribute=True, autofill=False, cli_name='model', multivalue=False, required=False)
-option: Str('ipatokennotafter', attribute=True, autofill=False, cli_name='not_after', multivalue=False, required=False)
-option: Str('ipatokennotbefore', attribute=True, autofill=False, cli_name='not_before', multivalue=False, required=False)
+option: DateTime('ipatokennotafter', attribute=True, autofill=False, cli_name='not_after', multivalue=False, required=False)
+option: DateTime('ipatokennotbefore', attribute=True, autofill=False, cli_name='not_before', multivalue=False, required=False)
option: Str('ipatokenowner', attribute=True, autofill=False, cli_name='owner', multivalue=False, required=False)
option: Str('ipatokenserial', attribute=True, autofill=False, cli_name='serial', multivalue=False, required=False)
option: Str('ipatokenvendor', attribute=True, autofill=False, cli_name='vendor', multivalue=False, required=False)
diff --git a/VERSION b/VERSION
index
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
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 Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: Martin Kosek wrote: On 01/09/2014 03:12 PM, Simo Sorce wrote: 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. They can remove the host right after they create a cert, I honestly do not think this is a valid concern. If your admin is rouge he can already take full ownership of your infrastructure in many ways, preventing setting a name in a cert doesn't really make a difference IMO. However I would be ok to limit this to some new Security Admin/CA Admin role that is not assigned by default. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0027] Add config.h.in~ and rpmbuild to git ignore
On Thu, 2014-01-02 at 09:58 +0100, Petr Viktorin wrote: On 12/23/2013 06:54 PM, Nathaniel McCallum wrote: Attached. config.in.h~ is a product of your specfific editor, right? You should add it to your personal ignore list, e.g. with: $ echo *~ ~/.gitignore $ git config --global core.excludesfile ~/.gitignore I don't remember editing config.in.h, but I've removed it from this version. As for rpmbuild, how is it generated? I don't think our makefile creates it, does it? make rpms If it does, I believe it would appear only in the root directory, in which case it should go in the Root directory section of .gitignore, start with a slash. Also it should end with a slash since it's a directory. Fixed. From 46b7030e27febee2a8b382d8af8a41c85a14e8ed Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Thu, 19 Dec 2013 16:45:55 -0500 Subject: [PATCH] Add rpmbuild/ to .gitignore --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index db213497202fc1ba904d3fc1b9ccea2ec5be3068..660bdca825d526c634f547919b324101ebb1d907 100644 --- a/.gitignore +++ b/.gitignore @@ -39,6 +39,7 @@ freeipa2-dev-doc !/Makefile /dist/ /RELEASE +/rpmbuild/ # Subdirectories /daemons/ipa-otpd/ipa-otpd -- 1.8.4.2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0029] Add libotp internal library for slapi plugins
Attached. From 035fe16ec8088effcd06824ae1aeee99222076b1 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Mon, 6 Jan 2014 16:50:07 -0500 Subject: [PATCH] Add libotp internal library for slapi plugins --- daemons/configure.ac | 1 + daemons/ipa-slapi-plugins/Makefile.am| 1 + daemons/ipa-slapi-plugins/libotp/Makefile.am | 9 + daemons/ipa-slapi-plugins/libotp/libotp.c| 502 +++ daemons/ipa-slapi-plugins/libotp/libotp.h| 92 + daemons/ipa-slapi-plugins/libotp/librfc.c| 168 + daemons/ipa-slapi-plugins/libotp/librfc.h| 61 daemons/ipa-slapi-plugins/libotp/t_librfc.c | 119 +++ 8 files changed, 953 insertions(+) create mode 100644 daemons/ipa-slapi-plugins/libotp/Makefile.am create mode 100644 daemons/ipa-slapi-plugins/libotp/libotp.c create mode 100644 daemons/ipa-slapi-plugins/libotp/libotp.h create mode 100644 daemons/ipa-slapi-plugins/libotp/librfc.c create mode 100644 daemons/ipa-slapi-plugins/libotp/librfc.h create mode 100644 daemons/ipa-slapi-plugins/libotp/t_librfc.c diff --git a/daemons/configure.ac b/daemons/configure.ac index 7086d8e1054ad9941232c75fc0a82e050a682247..b0bbe96a632337b973316a2849c9d35b5d642f5f 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -309,6 +309,7 @@ AC_CONFIG_FILES([ ipa-sam/Makefile ipa-otpd/Makefile ipa-slapi-plugins/Makefile +ipa-slapi-plugins/libotp/Makefile ipa-slapi-plugins/ipa-cldap/Makefile ipa-slapi-plugins/ipa-dns/Makefile ipa-slapi-plugins/ipa-enrollment/Makefile diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am index 08c7558c812effc00ae940661e448779077fb409..40725d2259d09010d2f82381543fc77d84435040 100644 --- a/daemons/ipa-slapi-plugins/Makefile.am +++ b/daemons/ipa-slapi-plugins/Makefile.am @@ -1,6 +1,7 @@ NULL = SUBDIRS = \ + libotp \ ipa-cldap \ ipa-dns \ ipa-enrollment \ diff --git a/daemons/ipa-slapi-plugins/libotp/Makefile.am b/daemons/ipa-slapi-plugins/libotp/Makefile.am new file mode 100644 index ..6aa60c56a2293916ba7c1d773968055c3f94a4fe --- /dev/null +++ b/daemons/ipa-slapi-plugins/libotp/Makefile.am @@ -0,0 +1,9 @@ +MAINTAINERCLEANFILES = *~ Makefile.in +AM_CPPFLAGS = -I/usr/include/dirsrv + +noinst_LTLIBRARIES = librfc.la libotp.la +libotp_la_LIBADD = librfc.la + +check_PROGRAMS = t_librfc +TESTS = $(check_PROGRAMS) +t_librfc_LDADD = $(NSPR_LIBS) $(NSS_LIBS) librfc.la diff --git a/daemons/ipa-slapi-plugins/libotp/libotp.c b/daemons/ipa-slapi-plugins/libotp/libotp.c new file mode 100644 index ..dd5ebe6a110c3ea7f61dde40dd71201deef4dd2e --- /dev/null +++ b/daemons/ipa-slapi-plugins/libotp/libotp.c @@ -0,0 +1,502 @@ +/** BEGIN COPYRIGHT BLOCK + * This Program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License as published by the Free Software + * Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS + * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along with + * this Program; if not, write to the Free Software Foundation, Inc., 59 Temple + * Place, Suite 330, Boston, MA 02111-1307 USA. + * + * In addition, as a special exception, Red Hat, Inc. gives You the additional + * right to link the code of this Program with code not covered under the GNU + * General Public License (Non-GPL Code) and to distribute linked combinations + * including the two, subject to the limitations in this paragraph. Non-GPL Code + * permitted under this exception must only link to the code of this Program + * through those well defined interfaces identified in the file named EXCEPTION + * found in the source code files (the Approved Interfaces). The files of + * Non-GPL Code may instantiate templates or use macros or inline functions from + * the Approved Interfaces without causing the resulting work to be covered by + * the GNU General Public License. Only Red Hat, Inc. may make changes or + * additions to the list of Approved Interfaces. You must obey the GNU General + * Public License in all respects for all of the Program code and other code used + * in conjunction with the Program except the Non-GPL Code covered by this + * exception. If you modify this file, you may extend this exception to your + * version of the file, but you are not obligated to do so. If you do not wish to + * provide this exception without modification, you must delete this exception + * statement from your version and license this file solely under the GPL without + * exception. + * + * + * Copyright (C) 2013 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT
Re: [Freeipa-devel] [PATCH 0028] Add OTP last token plugin
This new version now depends on my patch 0029. Sorry for the reverse ordering. On Mon, 2013-12-23 at 12:56 -0500, Nathaniel McCallum wrote: This plugin prevents the deletion or deactivation of the last valid token for a user. This prevents the user from migrating back to single factor authentication once OTP has been enabled. Thanks to Mark Reynolds for helping me with this patch. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel From 919da83ceb5b1bb54436ff04af65a51b5e79e2b2 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Mon, 16 Dec 2013 16:19:08 -0500 Subject: [PATCH] Add OTP last token plugin This plugin prevents the deletion or deactivation of the last valid token for a user. This prevents the user from migrating back to single factor authentication once OTP has been enabled. Thanks to Mark Reynolds for helping me with this patch. --- daemons/configure.ac | 1 + daemons/ipa-slapi-plugins/Makefile.am | 1 + .../ipa-otp-lasttoken/Makefile.am | 28 +++ .../ipa-otp-lasttoken/ipa-otp-lasttoken.sym| 1 + .../ipa-otp-lasttoken/ipa_otp_lasttoken.c | 188 + .../ipa-otp-lasttoken/otp-lasttoken-conf.ldif | 15 ++ freeipa.spec.in| 2 + ipaserver/install/dsinstance.py| 4 + 8 files changed, 240 insertions(+) create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/otp-lasttoken-conf.ldif diff --git a/daemons/configure.ac b/daemons/configure.ac index b0bbe96a632337b973316a2849c9d35b5d642f5f..3cdb9384c116e73a19c605a3c9401661772cf4d1 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -314,6 +314,7 @@ AC_CONFIG_FILES([ ipa-slapi-plugins/ipa-dns/Makefile ipa-slapi-plugins/ipa-enrollment/Makefile ipa-slapi-plugins/ipa-lockout/Makefile +ipa-slapi-plugins/ipa-otp-lasttoken/Makefile ipa-slapi-plugins/ipa-pwd-extop/Makefile ipa-slapi-plugins/ipa-extdom-extop/Makefile ipa-slapi-plugins/ipa-winsync/Makefile diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am index 40725d2259d09010d2f82381543fc77d84435040..06e6ee8b86f138cce05f2184ac98c39ffaf9757f 100644 --- a/daemons/ipa-slapi-plugins/Makefile.am +++ b/daemons/ipa-slapi-plugins/Makefile.am @@ -7,6 +7,7 @@ SUBDIRS = \ ipa-enrollment \ ipa-lockout \ ipa-modrdn \ + ipa-otp-lasttoken \ ipa-pwd-extop \ ipa-extdom-extop \ ipa-uuid \ diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am new file mode 100644 index ..1e3869bfda9f8fd14cd4d93d0d466780932ac40f --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am @@ -0,0 +1,28 @@ +MAINTAINERCLEANFILES = *~ Makefile.in +PLUGIN_COMMON_DIR = ../common +AM_CPPFLAGS = \ + -I. \ + -I$(srcdir) \ + -I$(srcdir)/../libotp \ + -I$(PLUGIN_COMMON_DIR) \ + -I/usr/include/dirsrv \ + -DPREFIX=\$(prefix)\ \ + -DBINDIR=\$(bindir)\\ + -DLIBDIR=\$(libdir)\ \ + -DLIBEXECDIR=\$(libexecdir)\ \ + -DDATADIR=\$(datadir)\\ + $(AM_CFLAGS) \ + $(LDAP_CFLAGS) \ + $(WARN_CFLAGS) + +plugindir = $(libdir)/dirsrv/plugins +plugin_LTLIBRARIES = libipa_otp_lasttoken.la +libipa_otp_lasttoken_la_SOURCES = ipa_otp_lasttoken.c +libipa_otp_lasttoken_la_LDFLAGS = -avoid-version -export-symbols ipa-otp-lasttoken.sym +libipa_otp_lasttoken_la_LIBADD = \ + $(LDAP_LIBS)\ + $(builddir)/../libotp/libotp.la + +appdir = $(IPA_DATA_DIR) +app_DATA = otp-lasttoken-conf.ldif +EXTRA_DIST = $(app_DATA) diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym new file mode 100644 index ..e32dc32f5693547bf604480490f42511368fdb81 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa-otp-lasttoken.sym @@ -0,0 +1 @@ +ipa_otp_lasttoken_init diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c new file mode 100644 index ..de54970416af3b9dd595e4789a464ac732f7c0cf --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c @@ -0,0 +1,188 @@ +/** BEGIN COPYRIGHT BLOCK + * This Program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License as published by the Free Software + * Foundation; version 2
[Freeipa-devel] [PATCH 0030] Add OTP sync plugin
This plugin adds an extended operation for synchronizing tokens. This operation is availalbe both with and without bind. In the latter case, the first factor is required. This operation can also be performed on a per-token or per-user level. In the latter case, we will attempt to find the token automatically. Thanks to Mark Reynolds for helping me with this patch. From 6c4927e3957c40aa9dca09fd55c76842996aadd1 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Tue, 17 Dec 2013 17:38:37 -0500 Subject: [PATCH] Add OTP sync plugin This plugin adds an extended operation for synchronizing tokens. This operation is availalbe both with and without bind. In the latter case, the first factor is required. This operation can also be performed on a per-token or per-user level. In the latter case, we will attempt to find the token automatically. Thanks to Mark Reynolds for helping me with this patch. --- daemons/configure.ac | 1 + daemons/ipa-slapi-plugins/Makefile.am | 1 + daemons/ipa-slapi-plugins/ipa-otp-sync/Makefile.am | 28 +++ .../ipa-otp-sync/ipa-otp-sync.sym | 1 + .../ipa-slapi-plugins/ipa-otp-sync/ipa_otp_sync.c | 151 ++ .../ipa-otp-sync/otp-sync-conf.ldif| 15 ++ daemons/ipa-slapi-plugins/ipa-otp-sync/request.c | 227 + daemons/ipa-slapi-plugins/ipa-otp-sync/request.h | 68 ++ freeipa.spec.in| 2 + ipaserver/install/dsinstance.py| 4 + 10 files changed, 498 insertions(+) create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-sync/Makefile.am create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-sync/ipa-otp-sync.sym create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-sync/ipa_otp_sync.c create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-sync/otp-sync-conf.ldif create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-sync/request.c create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-sync/request.h diff --git a/daemons/configure.ac b/daemons/configure.ac index 3cdb9384c116e73a19c605a3c9401661772cf4d1..8571e86a9b6f96d01e13b2a2d126abc106fa4def 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -315,6 +315,7 @@ AC_CONFIG_FILES([ ipa-slapi-plugins/ipa-enrollment/Makefile ipa-slapi-plugins/ipa-lockout/Makefile ipa-slapi-plugins/ipa-otp-lasttoken/Makefile +ipa-slapi-plugins/ipa-otp-sync/Makefile ipa-slapi-plugins/ipa-pwd-extop/Makefile ipa-slapi-plugins/ipa-extdom-extop/Makefile ipa-slapi-plugins/ipa-winsync/Makefile diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am index 06e6ee8b86f138cce05f2184ac98c39ffaf9757f..00a1ab1458d736193a3097e44411f542e03cc390 100644 --- a/daemons/ipa-slapi-plugins/Makefile.am +++ b/daemons/ipa-slapi-plugins/Makefile.am @@ -8,6 +8,7 @@ SUBDIRS = \ ipa-lockout \ ipa-modrdn \ ipa-otp-lasttoken \ + ipa-otp-sync \ ipa-pwd-extop \ ipa-extdom-extop \ ipa-uuid \ diff --git a/daemons/ipa-slapi-plugins/ipa-otp-sync/Makefile.am b/daemons/ipa-slapi-plugins/ipa-otp-sync/Makefile.am new file mode 100644 index ..5bd941c838635eca87641ebe1a6f09fbc2703927 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-sync/Makefile.am @@ -0,0 +1,28 @@ +MAINTAINERCLEANFILES = *~ Makefile.in +PLUGIN_COMMON_DIR = ../common +AM_CPPFLAGS = \ + -I. \ + -I$(srcdir) \ + -I$(srcdir)/../libotp \ + -I$(PLUGIN_COMMON_DIR) \ + -I/usr/include/dirsrv \ + -DPREFIX=\$(prefix)\ \ + -DBINDIR=\$(bindir)\\ + -DLIBDIR=\$(libdir)\ \ + -DLIBEXECDIR=\$(libexecdir)\ \ + -DDATADIR=\$(datadir)\\ + $(AM_CFLAGS) \ + $(LDAP_CFLAGS) \ + $(WARN_CFLAGS) + +plugindir = $(libdir)/dirsrv/plugins +plugin_LTLIBRARIES = libipa_otp_sync.la +libipa_otp_sync_la_SOURCES = request.c ipa_otp_sync.c +libipa_otp_sync_la_LDFLAGS = -avoid-version -export-symbols ipa-otp-sync.sym +libipa_otp_sync_la_LIBADD = \ + $(LDAP_LIBS) \ + $(builddir)/../libotp/libotp.la + +appdir = $(IPA_DATA_DIR) +app_DATA = otp-sync-conf.ldif +EXTRA_DIST = $(app_DATA) diff --git a/daemons/ipa-slapi-plugins/ipa-otp-sync/ipa-otp-sync.sym b/daemons/ipa-slapi-plugins/ipa-otp-sync/ipa-otp-sync.sym new file mode 100644 index ..880454f71a7aefb1998d52cb9cf8fcadc2edf701 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-sync/ipa-otp-sync.sym @@ -0,0 +1 @@ +ipa_otp_sync_init diff --git a/daemons/ipa-slapi-plugins/ipa-otp-sync/ipa_otp_sync.c b/daemons/ipa-slapi-plugins/ipa-otp-sync/ipa_otp_sync.c new file mode 100644 index ..68cecb9e48e13998da1641c7fb1b8e2858d5c032 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-sync/ipa_otp_sync.c @@ -0,0 +1,151 @@ +/** BEGIN COPYRIGHT BLOCK + * This Program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General
[Freeipa-devel] [PATCH 0031] Migrate ipa-pwd-extop to use libotp
Attached. From 8b0fa10fcbf87097bcafaba0c19749856b66bbf4 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Tue, 7 Jan 2014 12:42:29 -0500 Subject: [PATCH] Migrate ipa-pwd-extop to use libotp --- .../ipa-slapi-plugins/ipa-pwd-extop/Makefile.am| 12 +- daemons/ipa-slapi-plugins/ipa-pwd-extop/auth.c | 398 - daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h | 7 +- daemons/ipa-slapi-plugins/ipa-pwd-extop/otp.c | 180 -- daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 217 +-- daemons/ipa-slapi-plugins/ipa-pwd-extop/t_hotp.c | 82 - daemons/ipa-slapi-plugins/ipa-pwd-extop/t_totp.c | 103 -- 7 files changed, 118 insertions(+), 881 deletions(-) delete mode 100644 daemons/ipa-slapi-plugins/ipa-pwd-extop/auth.c delete mode 100644 daemons/ipa-slapi-plugins/ipa-pwd-extop/otp.c delete mode 100644 daemons/ipa-slapi-plugins/ipa-pwd-extop/t_hotp.c delete mode 100644 daemons/ipa-slapi-plugins/ipa-pwd-extop/t_totp.c diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am b/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am index 8bd89653de51ab33e295fc6b1f1d6d93576d3c64..98987446a56aab96d604ecc37e0a686d765b7f6c 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am @@ -10,6 +10,7 @@ KRB5_UTIL_SRCS = $(KRB5_UTIL_DIR)/ipa_krb5.c \ AM_CPPFLAGS = \ -I. \ -I$(srcdir) \ + -I$(srcdir)/../libotp \ -I$(PLUGIN_COMMON_DIR) \ -I$(KRB5_UTIL_DIR) \ -I$(COMMON_BER_DIR) \ @@ -33,20 +34,11 @@ AM_LDFLAGS = \ -avoid-version \ -export-symbols-regex ^ipapwd_init$ -# OTP Convenience Library and Tests -noinst_LTLIBRARIES = libotp.la -libotp_la_SOURCES = otp.c -check_PROGRAMS = t_hotp t_totp -t_hotp_LDADD = libotp.la -t_totp_LDADD = libotp.la -TESTS = $(check_PROGRAMS) - # Plugin Binary plugindir = $(libdir)/dirsrv/plugins plugin_LTLIBRARIES = libipa_pwd_extop.la -libipa_pwd_extop_la_LIBADD = libotp.la +libipa_pwd_extop_la_LIBADD = $(builddir)/../libotp/libotp.la libipa_pwd_extop_la_SOURCES = \ - auth.c\ common.c \ encoding.c \ prepost.c \ diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/auth.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/auth.c deleted file mode 100644 index cccddeb91d84b45aa23d13792725ff20d7af2c7f.. --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/auth.c +++ /dev/null @@ -1,398 +0,0 @@ -/** BEGIN COPYRIGHT BLOCK - * This Program is free software; you can redistribute it and/or modify it under - * the terms of the GNU General Public License as published by the Free Software - * Foundation; version 3 of the License. - * - * This Program is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS - * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License along with - * this Program; if not, write to the Free Software Foundation, Inc., 59 Temple - * Place, Suite 330, Boston, MA 02111-1307 USA. - * - * In addition, as a special exception, Red Hat, Inc. gives You the additional - * right to link the code of this Program with code not covered under the GNU - * General Public License (Non-GPL Code) and to distribute linked combinations - * including the two, subject to the limitations in this paragraph. Non-GPL Code - * permitted under this exception must only link to the code of this Program - * through those well defined interfaces identified in the file named EXCEPTION - * found in the source code files (the Approved Interfaces). The files of - * Non-GPL Code may instantiate templates or use macros or inline functions from - * the Approved Interfaces without causing the resulting work to be covered by - * the GNU General Public License. Only Red Hat, Inc. may make changes or - * additions to the list of Approved Interfaces. You must obey the GNU General - * Public License in all respects for all of the Program code and other code used - * in conjunction with the Program except the Non-GPL Code covered by this - * exception. If you modify this file, you may extend this exception to your - * version of the file, but you are not obligated to do so. If you do not wish to - * provide this exception without modification, you must delete this exception - * statement from your version and license this file solely under the GPL without - * exception. - * - * - * Copyright (C) 2013 Red Hat, Inc. - * All rights reserved. - * END COPYRIGHT BLOCK **/ - -#include ipapwd.h - -#define IPA_OTP_TOKEN_TOTP_OC ipaTokenTOTP -#define IPA_OTP_DEFAULT_TOKEN_ALGORITHM sha1 -#define IPA_OTP_DEFAULT_TOKEN_OFFSET 0 -#define IPA_OTP_DEFAULT_TOKEN_STEP 30 - -/* - * From otp.c - */ -bool ipapwd_hotp(const uint8_t *key, size_t len, const char *algo, int digits, - uint64_t
[Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
This patch is independent from my patches 0028-0031 and can be merged in
any order.
This patch has a bug, but I can't figure it out. We need to set
nsslapd-access-userattr-strict on cn=config to off. However, during
the rpm installation, I get this error:
DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting
attributes is not allowed', 'desc': 'Server is unwilling to perform'}
ERROR Update failed: Server is unwilling to perform: Deleting attributes
is not allowed
I'm not sure what is causing this. Does anyone have any suggestions?
Nathaniel
From b251a89a77f3ca2bbb639b46e83902cd1af691c6 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Tue, 7 Jan 2014 15:23:07 -0500
Subject: [PATCH] Update ACIs to permit users to add/delete their own tokens
---
freeipa.spec.in | 6 +++---
install/share/default-aci.ldif | 1 +
install/updates/10-config.update | 5 +
install/updates/40-otp.update| 1 +
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 6629f6a65551397965d1634ea641a3becbb085a5..bebe94028dafee12a9698fff19843750ab5b72f7 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -21,7 +21,7 @@ Source0:freeipa-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%if ! %{ONLY_CLIENT}
-BuildRequires: 389-ds-base-devel = 1.3.1.3
+BuildRequires: 389-ds-base-devel = 1.3.2.10
BuildRequires: svrcore-devel
BuildRequires: policycoreutils = %{POLICYCOREUTILSVER}
BuildRequires: systemd-units
@@ -96,7 +96,7 @@ Group: System Environment/Base
Requires: %{name}-python = %{version}-%{release}
Requires: %{name}-client = %{version}-%{release}
Requires: %{name}-admintools = %{version}-%{release}
-Requires: 389-ds-base = 1.3.1.3
+Requires: 389-ds-base = 1.3.2.10
Requires: openldap-clients 2.4.35-4
%if 0%{?fedora} == 18
Requires: nss = 3.14.3-2
@@ -152,7 +152,7 @@ Requires: zip
Requires: policycoreutils = %{POLICYCOREUTILSVER}
Requires: tar
Requires(pre): certmonger = 0.65
-Requires(pre): 389-ds-base = 1.3.1.3
+Requires(pre): 389-ds-base = 1.3.2.10
# With FreeIPA 3.3, package freeipa-server-selinux was obsoleted as the
# entire SELinux policy is stored in the system policy
diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif
index 510ea32848ef0f51f67d8cca3e3c14351a4f..1e0c21eec5ee0b3719cc09921f231743134908f9 100644
--- a/install/share/default-aci.ldif
+++ b/install/share/default-aci.ldif
@@ -103,3 +103,4 @@ add: aci
aci: (targetfilter = (objectClass=ipaToken))(targetattrs = objectclass || ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version 3.0; acl Users can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
aci: (targetfilter = (objectClass=ipaToken))(targetattrs = ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version 3.0; acl Users can write basic token info; allow (write) userattr = ipatokenOwner#USERDN;)
aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs = ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPclockOffset || ipatokenTOTPtimeStep)(version 3.0; acl Users can add TOTP token secrets; allow (write, search) userattr = ipatokenOwner#USERDN;)
+aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create and delete tokens; allow (add, delete) userattr = ipatokenOwner#USERDN;)
diff --git a/install/updates/10-config.update b/install/updates/10-config.update
index 1512b3601bcb2337392b82bf54f540cd48ee8382..f7e8c2126cd1cee631edfe42060552042a52bbb2 100644
--- a/install/updates/10-config.update
+++ b/install/updates/10-config.update
@@ -63,3 +63,8 @@ addifnew:nsSaslMapPriority: 10
# Can be removed when https://fedorahosted.org/389/ticket/47457 is fixed
dn: cn=config
only:nsslapd-sasl-max-buffer-size:2097152
+
+# Disable userattr strict mode. This is primarily for OTP where users
+# need to add objects that point to themselves. Requires 389ds = 1.3.2.10.
+dn: cn=config
+only:nsslapd-access-userattr-strict: off
diff --git a/install/updates/40-otp.update b/install/updates/40-otp.update
index 83dfab7c03bfeb121756410d79143c3812146de6..1204d30a594bcf5a50db6a9b07343e80846d3560 100644
--- a/install/updates/40-otp.update
+++ b/install/updates/40-otp.update
@@ -7,6 +7,7 @@ dn: $SUFFIX
add: aci:'(targetfilter = (objectClass=ipaToken))(targetattrs = objectclass || ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version 3.0; acl Users can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN;)'
add: aci:'(targetfilter = (objectClass=ipaToken))(targetattrs
[Freeipa-devel] [PATCH 0033] Add HOTP token support
This patch depends on my patch 0029.
In the past we have talked about not adding HOTP support due to the
inability to guarantee timely updates to the counter across replication.
I went ahead and implemented HOTP support for two reasons:
1. Testing the OTP stack with TOTP tokens can be a bit frustrating
waiting for the tokens to generate.
2. Since we aren't implementing watermark support for TOTP, the HOTP
security guarantee seems very similar to me.
Nathaniel
From 8df0458f68072d18b20d0a535ada7d9e44ace3f2 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Wed, 8 Jan 2014 15:08:55 -0500
Subject: [PATCH] Add HOTP token support
---
API.txt | 10 +++---
VERSION | 2 +-
daemons/ipa-slapi-plugins/libotp/libotp.c | 43 +++
install/share/70ipaotp.ldif | 2 ++
install/share/default-aci.ldif| 3 +-
install/updates/40-otp.update | 1 +
ipalib/plugins/otptoken.py| 26 ++
ipaserver/install/plugins/update_anonymous_aci.py | 2 +-
8 files changed, 68 insertions(+), 21 deletions(-)
diff --git a/API.txt b/API.txt
index a6c3aed82370d690a678a034b0eea85d4f85b45f..e2f5e036e416bfc248b845c742e3d563958f1772 100644
--- a/API.txt
+++ b/API.txt
@@ -2220,12 +2220,13 @@ output: Entry('result', type 'dict', Gettext('A dictionary representing an LDA
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
command: otptoken_add
-args: 1,20,3
+args: 1,21,3
arg: Str('ipatokenuniqueid', attribute=True, cli_name='id', multivalue=False, primary_key=True, required=False)
option: Str('addattr*', cli_name='addattr', exclude='webui')
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False)
option: Bool('ipatokendisabled', attribute=True, cli_name='disabled', multivalue=False, required=False)
+option: Int('ipatokenhotpcounter', attribute=True, cli_name='counter', minvalue=0, multivalue=False, required=False)
option: Str('ipatokenmodel', attribute=True, cli_name='model', multivalue=False, required=False)
option: Str('ipatokennotafter', attribute=True, cli_name='not_after', multivalue=False, required=False)
option: Str('ipatokennotbefore', attribute=True, cli_name='not_before', multivalue=False, required=False)
@@ -2240,7 +2241,7 @@ option: Str('ipatokenvendor', attribute=True, cli_name='vendor', multivalue=Fals
option: Flag('qrcode?', autofill=True, default=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('setattr*', cli_name='setattr', exclude='webui')
-option: StrEnum('type', attribute=False, cli_name='type', multivalue=False, required=False, values=(u'totp',))
+option: StrEnum('type', attribute=False, cli_name='type', multivalue=False, required=False, values=(u'totp', u'hotp'))
option: Str('version?', exclude='webui')
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
output: Output('summary', (type 'unicode', type 'NoneType'), None)
@@ -2254,11 +2255,12 @@ output: Output('result', type 'dict', None)
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
command: otptoken_find
-args: 1,20,4
+args: 1,21,4
arg: Str('criteria?', noextrawhitespace=False)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False)
option: Bool('ipatokendisabled', attribute=True, autofill=False, cli_name='disabled', multivalue=False, query=True, required=False)
+option: Int('ipatokenhotpcounter', attribute=True, autofill=False, cli_name='counter', minvalue=0, multivalue=False, query=True, required=False)
option: Str('ipatokenmodel', attribute=True, autofill=False, cli_name='model', multivalue=False, query=True, required=False)
option: Str('ipatokennotafter', attribute=True, autofill=False, cli_name='not_after', multivalue=False, query=True, required=False)
option: Str('ipatokennotbefore', attribute=True, autofill=False, cli_name='not_before', multivalue=False, query=True, required=False)
@@ -2274,7 +2276,7 @@ option: Flag('pkey_only?', autofill=True, default=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Int('sizelimit?', autofill=False, minvalue=0)
option: Int('timelimit?', autofill=False, minvalue=0)
-option: StrEnum('type', attribute=False, autofill=False, cli_name='type', multivalue=False, query=True, required=False, values=(u'totp',))
+option: StrEnum('type', attribute=False, autofill=False, cli_name='type', multivalue=False, query=True,
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On 01/09/2014 02:32 PM, Nathaniel McCallum wrote:
This patch is independent from my patches 0028-0031 and can be merged in
any order.
This patch has a bug, but I can't figure it out. We need to set
nsslapd-access-userattr-strict on cn=config to off. However, during
the rpm installation, I get this error:
DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting
attributes is not allowed', 'desc': 'Server is unwilling to perform'}
ERROR Update failed: Server is unwilling to perform: Deleting attributes
is not allowed
I'm not sure what is causing this. Does anyone have any suggestions?
I believe the IPA update mechanism works by doing a modify/del of the
attribute followed by a modify/add. By default, cn=config restricts the
attributes which can be deleted. You can add
nsslapd-access-userattr-strict to this list. Unfortunately, it is
rather painful to do so.
Method one: Don't use the ipa update mechanism to update this
attribute. Instead, just use an ldap modify directly e.g. using ldapmodify:
ldapmodify
dn: cn=config
changetype: modify
replace: nsslapd-access-userattr-strict
nsslapd-access-userattr-strict: off
or in python-ldap:
conn = ldap.connection(my ldap url)
conn.simple_bind_s(cn=directory manager, password)
mod = [(ldap.MOD_REPLACE, nsslapd-access-userattr-strict, ['off'])]
conn.modify_s(cn=config, mod)
Method two: allow deletion of nsslapd-access-userattr-strict in order to
use ipa update method
This will unfortunately require the use of something other than the ipa
update method, again.
1) do a search to get the current value in cn=config
nsslapd-allowed-to-delete-attrs - it is a single space delimited list
2) add nsslapd-access-userattr-strict to the list
3) mod/replace the value
Nathaniel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA OTP End-to-End
New RPMs are up: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ WHAT'S NEW IN THE RPMS? * 389ds OTP Last Token Plugin * 389ds OTP Sync Plugin * HOTP token support * OTP UI is now working All of the non-UI code is currently on the list. Petr is working on UI cleanup. You can see all the patches here: https://github.com/npmccallum/freeipa/tree/otp https://github.com/npmccallum/freeipa/tree/otpui KNOWN ISSUES Setting User Auth Type globally doesn't work: https://fedorahosted.org/freeipa/ticket/4105 SELinux is broken on F20 (should be fixed in rawhide): https://bugzilla.redhat.com/show_bug.cgi?id=970163 User's can't add their own tokens. A patch to fix this is in the RPMs, but currently has a bug. A workaround exists. Details are here: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00068.html Alexander Bokovoy (I think) found some issues when interacting with pkinit. I don't know the state of this. Alexander Bokovoy found a bug with SSSD that has (a few minutes ago) been patched. Details are here: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-January/017934.html STILL NEEDED * UI patches polished and sent to the list. * OTP Sync Client (both CLI and UI). Nathaniel On Fri, 2013-12-13 at 15:57 -0500, Nathaniel McCallum wrote: This is an email to track the status of the OTP project as we push toward completion. I'm also attempting to get all the pieces in play so that they are testable. RPMs Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ These currently contain the CLI and UI patches, but exclude the DS plugin patch. I will merge this last patch in when submitted to the list. OTP CLI All of the patches are merged except npmccallum-0024, which is undergoing active review. https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html OTP UI Thanks to Petr Vobornik for his set of patches implementing the UI. They can be found rebased on top of my otp changes here: https://github.com/npmccallum/freeipa/commits/otpui Authentication methods and RADIUS proxy support seems to be fully functional and I have not encountered any bugs. I'm not currently able to get the OTP UI to show up at all (I may well be doing something wrong). I believe Petr plans to clean these up and resubmit them to the list. One additional patch will be required for the token sync extop. DS PLUGIN I am nearing completion on the DS plugin providing support for deletion protection and the token sync extop. This should hit the list next week. OTHER Am I missing anything? Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: This patch is independent from my patches 0028-0031 and can be merged in any order. This patch has a bug, but I can't figure it out. We need to set nsslapd-access-userattr-strict on cn=config to off. Uhmm what is the effect on ACL evaluation of changing this boolean ? I can;t figure out from your commit not from 389ds commit what exactly changes and how it impacts the security of the directory. I ask because I was planning on using userattr to protect some operations in the password plugin but was waiting due to bug: https://fedorahosted.org/389/ticket/47571 which is beeing resolved. I want to make sure your change won't change what this ACIs would allow. Is this option simply allowing the use of add/delete ACIs to be specified in conjunction with userattr, so that a user can add an attr only if it contains its own DN ? Will it allow the user to add multiple values to the same attr as long as one of the is the userDN ? O will it restrict that case ? (I know that ipaTokenOwner is a single-value attribute, but the mechanism you are enabling here is general, and I want to be sure of what the semantics are) Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
Simo Sorce wrote: On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: This patch is independent from my patches 0028-0031 and can be merged in any order. This patch has a bug, but I can't figure it out. We need to set nsslapd-access-userattr-strict on cn=config to off. Uhmm what is the effect on ACL evaluation of changing this boolean ? Ticket 47653 - Need a way to allow users to create entries assigned to themselves Bug Description: There are cases where users need to be able to create, edit and delete their own entries. Using an ACI with the userattr keyword does not work with ADD operations(to prevent a security hole). This prevents IPA's OTP plugin from performing some necessary operations. Fix Description: Added a new config attribute nsslapd-access-userattr-strict. The default is on or strict. For the IPA case, it would need to be set to off in order to allow the desired behavior. https://fedorahosted.org/389/ticket/47653 This patch is included in 389-ds-base-1.3.2.10 and newer. I can;t figure out from your commit not from 389ds commit what exactly changes and how it impacts the security of the directory. I ask because I was planning on using userattr to protect some operations in the password plugin but was waiting due to bug: https://fedorahosted.org/389/ticket/47571 which is beeing resolved. Thank you for waiting. We are going to add the fix to the next release (1.3.2.11). Thanks! --noriko I want to make sure your change won't change what this ACIs would allow. Is this option simply allowing the use of add/delete ACIs to be specified in conjunction with userattr, so that a user can add an attr only if it contains its own DN ? Will it allow the user to add multiple values to the same attr as long as one of the is the userDN ? O will it restrict that case ? (I know that ipaTokenOwner is a single-value attribute, but the mechanism you are enabling here is general, and I want to be sure of what the semantics are) Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote: Simo Sorce wrote: On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: This patch is independent from my patches 0028-0031 and can be merged in any order. This patch has a bug, but I can't figure it out. We need to set nsslapd-access-userattr-strict on cn=config to off. Uhmm what is the effect on ACL evaluation of changing this boolean ? Ticket 47653 - Need a way to allow users to create entries assigned to themselves Bug Description: There are cases where users need to be able to create, edit and delete their own entries. Using an ACI with the userattr keyword does not work with ADD operations(to prevent a security hole). This prevents IPA's OTP plugin from performing some necessary operations. Fix Description: Added a new config attribute nsslapd-access-userattr-strict. The default is on or strict. For the IPA case, it would need to be set to off in order to allow the desired behavior. https://fedorahosted.org/389/ticket/47653 This patch is included in 389-ds-base-1.3.2.10 and newer. Thank you Noriko, but as I mentioned, I already read through the 389ds patch and it doesn't help me. Below I have a few more questions, I will add one that is more clear. Is this option simply allowing the use of add/delete ACIs to be specified in conjunction with userattr, so that a user can add an attr only if it contains its own DN ? So the entry in this case does not exist yet, so my question is whether the (userattr=attrFoo#userDN) part will actually match that attrFoo is set to contain the DN of the user that is performing the operation ? Will it allow the user to add multiple values to the same attr as long as one of the is the userDN ? O will it restrict that case ? This is also important, if attrFoo is a multivalued attribute, does this option allow any values to be set as long as one of them is userDN ? Or will it enforce that *only* userDN is add in the add operation ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
Simo Sorce wrote:
On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote:
Simo Sorce wrote:
On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
This patch is independent from my patches 0028-0031 and can be merged in
any order.
This patch has a bug, but I can't figure it out. We need to set
nsslapd-access-userattr-strict on cn=config to off.
Uhmm what is the effect on ACL evaluation of changing this boolean ?
Ticket 47653 - Need a way to allow users to create entries assigned
to themselves
Bug Description: There are cases where users need to be able to
create, edit and delete
their own entries. Using an ACI with the
userattr keyword does not
work with ADD operations(to prevent a security
hole). This prevents IPA's
OTP plugin from performing some necessary operations.
Fix Description: Added a new config attribute
nsslapd-access-userattr-strict. The default
is on or strict. For the IPA case, it would
need to be set to off in
order to allow the desired behavior.
https://fedorahosted.org/389/ticket/47653
This patch is included in 389-ds-base-1.3.2.10 and newer.
Thank you Noriko, but as I mentioned, I already read through the 389ds
patch and it doesn't help me. Below I have a few more questions, I will
add one that is more clear.
Is this option simply allowing the use of add/delete ACIs to be
specified in conjunction with userattr, so that a user can add an attr
only if it contains its own DN ?
So the entry in this case does not exist yet, so my question is whether
the (userattr=attrFoo#userDN) part will actually match that attrFoo is
set to contain the DN of the user that is performing the operation ?
I uesd this ACI:
aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl userattr
test; allow (add,write,delete,read,search,compare) userattr =
description#USERDN;)
Please note uid=nuser does not exist yet. Does your question mean by
this add? Before coming to the ACL code, bind fails...
$ ldapmodify ... -D 'uid=nuser,o=my.com' -w Nuser -a EOF
dn: uid=Nuser, o=my.com
objectClass: top
[...]
uid: Nuser
description: uid=nuser,o=my.com
userPassword: {CLEAR}Nuser
EOF
ldap_simple_bind: No such object
ldap_simple_bind: matched: o=my.com
Will it allow the user to add multiple values to the same attr as long
as one of the is the userDN ? O will it restrict that case ?
This is also important, if attrFoo is a multivalued attribute, does this
option allow any values to be set as long as one of them is userDN ?
Or will it enforce that *only* userDN is add in the add operation ?
As long as the type of the attribute is not restricted as DN syntax, it
takes any value including DN. I tested with 'description' (e.g.,
userattr = description#USERDN) and verified it takes userDN as well as
any other values.
$ ldapmodify ... -D 'cn=directory manager' -w pw
dn: uid=nuser4,o=my.com
changetype: modify
add: description
description: uid=nuser4,o=my.com
$ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4
dn: uid=nuser4,o=my.com
changetype: modify
add: description
description: uid=nuser0,o=my.com
modifying entry uid=nuser4,o=my.com
$ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0
dn: uid=nuser4,o=my.com
changetype: modify
add: description
description: uid=nuser1,o=my.com
modifying entry uid=nuser4,o=my.com
$ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1
dn: uid=nuser4,o=my.com
changetype: modify
add: description
description: value
$ ldapsearch ... -D 'cn=directory manager' -w pw -b
uid=nuser4,o=my.com description
dn: uid=Nuser4,o=my.com
description: uid=nuser4,o=my.com
description: uid=nuser0,o=my.com
description: uid=nuser1,o=my.com
description: value
--noriko
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
