On Mon, 2016-07-25 at 11:26 -0400, Simo Sorce wrote: > On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote: > > >> Simo Sorce wrote: > > >>> As described in #232 start restricting the use of the setkeytab > > >>> operation to just the computers objects. > > >>> > > >>> I haven't tested this with older RHEL/CentOS machines that actully use > > >>> the setkeytab operation as I do not have such an old VM handy right now. > > >>> > > >>> Meanwhile I'd like to know if ppl agree with this approach. > > >> > > >> What about services? > > > > > > Do we automatically acquire keytab for services in the old clients ? > > > > > > Are you thinking about scripted ipa-getkytab callouts ? > > > > You are limiting access to host keytabs, what about service keytabs? > > Should they be or are they now similarly restricted? > > > > Installers for something like Foreman may try to generate a service > > keytab in its installer, probably using admin credentials. I am planning > > to do the same in Openstack. > > Ok I'll amend the patch to allow service keytabs to still use the > setkeytab control still, and restrict only users. > However note that the idea of using this method is that admin can change > this default on their own, so they can restrict more or less if they > want, to that end I need to remember how to set a default that we do not > override in the update file. > > Simo. > Amended patch to allow services too. Only users are excluded.
Simo. -- Simo Sorce * Red Hat, Inc * New York
From e91403837f1ca679898030591f3fcc64f9378b98 Mon Sep 17 00:00:00 2001 From: Simo Sorce <s...@redhat.com> Date: Mon, 25 Jul 2016 06:46:24 -0400 Subject: [PATCH] Restrict the old setkeytab operation Allow it only to set computers/services keys by default. This is to allow older clients to join a newer IPA Server and manage their service. But at the same time prevent users from bypassing password policies by using this old broken interface. Ticket: https://fedorahosted.org/freeipa/ticket/232 Signed-off-by: Simo Sorce <s...@redhat.com> --- daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 13 ++++++++++++- install/updates/20-aci.update | 4 ++++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c index 3c2c44f6198bf74615fff1ae231a48bed77526ee..48880cdb74d2d12f016905c151f8fa9ad36c6d8a 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c @@ -1171,6 +1171,8 @@ done: return rc; } +#define SETKEYS_OP_CHECK "ipaProtectedOperation;set_keys" + /* Password Modify Extended operation plugin function */ static int ipapwd_setkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg) { @@ -1238,15 +1240,24 @@ static int ipapwd_setkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg) goto free_and_return; } - /* Accesseck strategy: + /* Access check strategy: * If the user has WRITE access, a new keytab can be set on the entry. * If not, then we fail immediately with insufficient access. This * means that we don't leak any useful information to the client such * as current password wrong, etc. + * + * In addition to the historic check, we now also check if the setkeytab + * operation is allowed at all. */ allowed_access = is_allowed_to_access_attr(pb, bindDN, targetEntry, "krbPrincipalKey", NULL, SLAPI_ACL_WRITE); + if (allowed_access) { + /* check if we are allowed to *set* keys */ + allowed_access = is_allowed_to_access_attr(pb, bindDN, targetEntry, + SETKEYS_OP_CHECK, NULL, + SLAPI_ACL_WRITE); + } if (!allowed_access) { LOG_FATAL("Access not allowed to set keytab on [%s]!\n", serviceName); diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index e9c10f54aadf5062c5a03f0d4b36343079462919..b12018004d6dfc51aabd5d6a006ee62660914dd6 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -113,6 +113,10 @@ add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Group add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey themselves"; allow(write) userdn="ldap:///self";;) add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) userattr="managedby#USERDN";) +# Set Keytab operation Access Control +# legacy interface for old hosts and ipa-getkeytab utils +add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;set_keys")(version 3.0; acl "Entities are allowed to set keys on managed entries (Compatibility)"; allow(write) userattr="managedby#USERDN";) +add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;set_keys")(version 3.0; acl "(Deprecated)Admins are allowed to set host keytabs (Compatibility)"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) # User certificates dn: $SUFFIX -- 2.5.5
-- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
