Re: [Freeipa-devel] [PATCHES] 0546-0547 Allow alternate aci keyword in ACIs
Petr Viktorin wrote: On 04/30/2014 07:25 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, The first patch adds == to ACI object to simplify comparisons. The second patch moves existing tests to the test suite. The third patch adds support for an alternate aci keyword that DS supports (but I couldn't get any documentaion on it). Dogtag adds ACIs with this keyword to cn=config, so we'll need this fix when parsing ACIs there. Rob, you wrote the parser; does this look OK to you? ACK. Only minor quibble is you left a couple of print statements in the tests. Those are intentional. When a failed test prints something, Nose shows the output. It's pretty nice for debugging. Ok. As you note, I had some tests that I ran when I was implementing the aci module. Moving these to formal testing is definitely the right thing to do. I do wonder one thing though. In the equality test I had reversed some ordering of things to ensure that things were normalized in the same way. For the check_aci_parsing() tests is it worth considering doing something similar? I'm not sure I follow; what part are you referring to? The ordering is problematic for sure; everything relies on dict order. That's the main reason why in my work I only use this class to parse ACIs, and I made a stable routine for generating them. Until we start running the tests with PYTHONHASHSEED=random, I figured we can just use them as they are. Ok. I had some vague memory I had stuck a sort() in there to not rely on dict ordering, maybe that was just an intention. I noticed that we are apparently not normalizing target filters because there is a space in the DN. Something for later. Or not; I'd like to get rid of the export_to_string part completely. There is no ticket. Probably fine since this is mostly just shuffling deck chairs. Yeah, same thinking here. It's part of the general ACI work. Alright, push away then. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for DNSSEC keys
On 04/30/2014 10:19 AM, Petr Spacek wrote: Hello list, following text summarizes schema DIT layout for DNSSEC key storage in LDAP. This is subset of full PKCS#11 schema [0]. It stores bare keys with few metadata attributes when necessary. The intention is to make transition to full PKCS#11-in-LDAP schema [0] as easy as possible. This transition should happen in next minor version of FreeIPA. In theory, the transition should be just adding few object classes to existing objects and populating few new metadata attributes. Related object classes are marked below with (in long-term). Please comment on it soon. We want to implement it ASAP :-) DNSSEC key == - Asymmetric - Private key is stored in LDAP as encrypted PKCS#8 blob - Public key is published in LDAP - Encrypted with symmetric DNSSEC master key (see below) - Private key - represented as LDAP object with object classes: ipaEPrivateKey [1] # encrypted data ipaWrappedKey [2] # pointer to master key, outside scope of pure PKCS#11 ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata - Public key - represented as LDAP object with object classes: ipaPublicKey[1] # public key data ipk11PublicKey [3] (in long-term) # PKCS#11 metadata Master key == - Symmetric - Stored in LDAP as encrypted blob - Encrypted with asymmetric replica key (see below) - 1 replica = 1 blob, n replicas = n blobs encrypted with different keys - A replica uses it's own key for master key en/decryption - Represented as LDAP object with object classes: ipaESecretKey [1] ipk11SecretKey [3] (in long-term) Replica key === - Asymmetric - Private key is stored on replica's disk only - Public key for all replicas is stored in LDAP - Represented as LDAP object with object classes: ipaPublicKey [1] ipk11PublicKey [3] (in long-term) DIT layout == DNSSEC key material --- - Container: cn=keys, cn=sec, cn=dns, dc=example - Private and public keys are stored as separate objects to accommodate all PKCS#11 metadata. - We need to decide about object naming: - One obvious option for RDN is to use uniqueID but I don't like it. It is hard to read for humans. - Other option is to use uniqueID+PKCS#11 label or other attributes to make it more readable. Can we use multi-valued RDN? If not, why? What are technical reasons behind it? I would encourage you not to use multi-valued RDNs. There aren't any technical reasons - multi-valued RDNs are part of the LDAP standards and all conforming LDAP implementations must support them. However, they are hard to deal with - you _must_ have some sort of DN class/api on the client side to handle them, and not all clients do - many clients expect to be able to just do dnstr.lower() == dnstr2.lower() or possibly do simple escaping. As far as being human readable - the whole goal is that humans _never_ have to look at a DN. If humans have to look at and understand a DN to accomplish a task, then we have failed. Has the DogTag team reviewed this proposal? Their data storage and workflows are similar. It is question if we like: nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda more than: ipk11Label=meaningful_label+ipk11Private=TRUE ipk11Label=meaningful_label+ipk11Private=FALSE DNSSEC key metadata --- - Container (per-zone): cn=keys, idnsname=example.net, cn=dns - Key metadata can be linked to key material via DN or ipk11Id. - This allows key sharing between zones. (DNSSEC-metadata will be specified later. That is not important for key storage.) Replica public keys --- - Container: cn=DNS,cn=replica FQDN,cn=masters,cn=ipa,cn=etc,dc=example - or it's child object like cn=wrappingKey Master keys --- - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example - Single key = single object. - We can use ipk11Label or ipk11Id for naming: ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc. Work flows == Read DNSSEC private key --- 1) read DNSSEC private key from LDAP 2) ipaWrappedKey objectClass is present - key is encrypted 3) read master key denoted by ipaWrappingKey attribute in DNSSEC key object 4) use local replica key to decrypt master key 5) use decrypted master key to decrypt DNSSEC private key Add DNSSEC private key -- 1) use local replica key to decrypt master key 2) encrypt DNSSEC private key with master key 3) add ipaWrappingKey attribute pointing to master key 4) store encrypted blob in a new LDAP object Add a replica - ipa-replica-prepare: 1) generate a new replica-key pair for the new replica 2) store key pair to replica-file (don't scream yet :-) 4) add public key for the new replica to LDAP 3) fetch master key from LDAP 4) encrypt master key with new replica public key 5) store resulting master key blob to LDAP ipa-replica-install:
Re: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin
Ade Lee wrote: I have attached a patch that contains code for the new dogtag DRM plugin vault functionality. This patch should be applied on top of the ones used to install a DRM. Forthcoming is a patch to actually start using this plugin. All the imports should be at the top of the file. In _create_pem_file there is a ipaserver.install.certs.export_pkcs12() that you can re-use. Similarly install_pem_from_p12() probably does the same thing, and your copy doesn't take the PKCS#12 password as input AFAICT. In _transport_cert_present you can use: from ipaserver.install import certs db = certs.CertDB(self.realm, nssdir=self.sec_dir) return db.has_nickname(self.transport_nick) Should there be error handling around keyclient calls or will that be handled at a different level? Incidentally, installing a replica on F-20 with pki-ca-10.2.0-0.1 against an F-20 master with pki-ca-10.1.1-1 fails with this traceback in pkispawn: File /usr/sbin/pkispawn, line 514, in module main(sys.argv) File /usr/sbin/pkispawn, line 423, in main info = parser.sd_get_info() File /usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py, line 463, in sd_get_info info = sd.getSecurityDomainInfo() File /usr/lib/python2.7/site-packages/pki/system.py, line 44, in getSecurityDomainInfo info.name = response.json()['id'] KeyError: 'id' rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration
On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote:
On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote:
On Tue, 11 Mar 2014, Jan Pazdziora wrote:
On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote:
Before this patch, ipa-kdb would load global configuration on startup
and never update it. This means that if global configuration is changed,
the KDC never receives the new configuration until it is restarted.
This patch enables caching of the global configuration with a timeout of
60 seconds.
https://fedorahosted.org/freeipa/ticket/4153
From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 24 Feb 2014 14:19:13 -0500
Subject: [PATCH] Periodically refresh global ipa-kdb configuration
Before this patch, ipa-kdb would load global configuration on startup and
never update it. This means that if global configuration is changed, the
KDC never receives the new configuration until it is restarted.
This patch enables caching of the global configuration with a timeout of
60 seconds.
https://fedorahosted.org/freeipa/ticket/4153
I have only read the code and it looks sane, so depending on how much
you consider my word about code-reading worth, ack.
However, my gut feeling is that my preferred way of handling the issue
(without knowing much about the background of the ticket) would
probably be a HUP signal handler or something similar, rather than
polling for current values with the value timeout. This patch
introduces small nondeterminism to the behaviour when the usage of the
new values cannot really be enfoced by the admin (without the daemon
restart).
Thing is, we need the update to happen when other, non-root process
makes the changes -- in our case when IPA server running under httpd
privileges performs series of MS-RPC calls towards smbd which lead to
creating certain LDAP objects. httpd couldn't send SIGHUP to a process
not owned by httpd's effective user (non-root).
Yes but this is not really the way to go.
The proper fix is to use syncrepl/persistent search to get a
notification of when we need to reload the configuration.
On the patch itself I have a NACK due to this syntax used in various
places: function()-attribute
don't. do. that. ever.
assign whatever come from the function to a local variable and *check*
it is not null, *then* use it.
Attached patch fixes the NACK issue, but does not address the question
of the larger approach. Do we need to take a different approach? If so,
what is it?
Nathaniel
From 0749ce930a3ca0dcefd7b7dc6ace5a851285a7d4 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 24 Feb 2014 14:19:13 -0500
Subject: [PATCH] Periodically refresh global ipa-kdb configuration
Before this patch, ipa-kdb would load global configuration on startup and
never update it. This means that if global configuration is changed, the
KDC never receives the new configuration until it is restarted.
This patch enables caching of the global configuration with a timeout of
60 seconds.
https://fedorahosted.org/freeipa/ticket/4153
---
daemons/ipa-kdb/ipa_kdb.c| 65 +---
daemons/ipa-kdb/ipa_kdb.h| 17 +++---
daemons/ipa-kdb/ipa_kdb_audit_as.c | 9 +++--
daemons/ipa-kdb/ipa_kdb_mspac.c | 10 --
daemons/ipa-kdb/ipa_kdb_principals.c | 11 --
5 files changed, 75 insertions(+), 37 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c
index 0f3996cdfa35374c005bc1ed174dea0816a27747..1b55735f1118ccbba2fc5d810c0171724634f9ad 100644
--- a/daemons/ipa-kdb/ipa_kdb.c
+++ b/daemons/ipa-kdb/ipa_kdb.c
@@ -25,6 +25,8 @@
#include ipa_kdb.h
+#define IPADB_GLOBAL_CONFIG_CACHE_TIME 60
+
struct ipadb_context *ipadb_get_context(krb5_context kcontext)
{
void *db_ctx;
@@ -41,6 +43,7 @@ struct ipadb_context *ipadb_get_context(krb5_context kcontext)
static void ipadb_context_free(krb5_context kcontext,
struct ipadb_context **ctx)
{
+struct ipadb_global_config *cfg;
size_t c;
if (*ctx != NULL) {
@@ -56,10 +59,11 @@ static void ipadb_context_free(krb5_context kcontext,
ipadb_mspac_struct_free((*ctx)-mspac);
krb5_free_default_realm(kcontext, (*ctx)-realm);
-for (c = 0; (*ctx)-authz_data (*ctx)-authz_data[c]; c++) {
-free((*ctx)-authz_data[c]);
+cfg = (*ctx)-config;
+for (c = 0; cfg-authz_data cfg-authz_data[c]; c++) {
+free(cfg-authz_data[c]);
}
-free((*ctx)-authz_data);
+free(cfg-authz_data);
free(*ctx);
*ctx = NULL;
@@ -209,7 +213,7 @@ void ipadb_parse_user_auth(LDAP *lcontext, LDAPMessage *le,
ldap_value_free_len(vals);
}
-int ipadb_get_global_configs(struct ipadb_context *ipactx)
+static int
