On Wed, Feb 08, 2017 at 08:02:18AM +0100, Jan Cholasta wrote: > On 8.2.2017 07:29, Fraser Tweedale wrote: > > On Mon, Feb 06, 2017 at 10:24:31AM +0100, Jan Cholasta wrote: > > > On 17.1.2017 08:57, David Kupka wrote: > > > > On 13/01/17 08:07, Fraser Tweedale wrote: > > > > > Related to design: > > > > > http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication > > > > > > > > > > Currently there are some operations that hit the CA that involve a > > > > > number of privileged operations against the CA, but for which there > > > > > is only one associated IPA permission. Deleting a CA is a good > > > > > example (but it is one specific case of a more general issue). > > > > > Summary of current ca-del behaviour: > > > > > > > > > > 1. Disable LWCA in Dogtag (uses RA Agent cert) > > > > > 2. Delete LWCA in Dogtag (uses RA Agent cert) > > > > > 3. Delete CA entry from IPA (requires "System: Delete CA" permission) > > > > > > > > > > So there are two things going on under the hood: a modify operation > > > > > (disable CA) and the delete. > > > > > > > > > > When we implement proxy authentication to Dogtag, Dogtag will > > > > > enforce the IPA permissions on its operations. Disable will map to > > > > > "System: Modify CA" and delete to "System: Delete CA". So to delete > > > > > a CA a user will need *both* permissions. Which could be > > > > > surprising. > > > > > > > > > > There are a couple of reasonable approaches to this. > > > > > > > > > > 1. Decouple the disable and delete operations. If CA is not > > > > > disabled, the user will be instructed to execute the ca-disable > > > > > command separately before they can disable the CA. This introduces > > > > > an additional manual step for operators. > > > > > > > > > > 2. Just improve the error reporting. In my WIP, for a user that has > > > > > 'System: Delete CA' permission but not 'System: Modify CA', the > > > > > reported failure is a 403 Authorization Error from Dogtag. We can > > > > > add guards to fail more gracefully. > > > > > > > > > > I lean towards #2 because I guess the common case will be that users > > > > > either get all CA admin permissions, or none, and we don't want to > > > > > make more work (in the form of more commands to run) for users in > > > > > the common case. > > > > > > > > > > I welcome alternative views and suggestions. > > > > > > > > > > Thanks, > > > > > Fraser > > > > > > > > > Hi Fraser, > > > > as a user with "System: Delete CA" permission calling "ca-del" command I > > > > would be really surprised that I don't have enough privileges to > > > > complete the action. > > > > > > > > I would expect: > > > > a) "Cannot delete active CA, disable it first" error. > > > > b) Delete will be completed successfully. All internal and to my sight > > > > hidden operations will be allowed just because I'm allowed to perform > > > > the delete operation. > > > > > > > > I think that b) might lead to strange exceptions in authorization > > > > checking and therefore to security issues. So I would prefer decoupling > > > > ca-disable and ca-del as you're describing in 1). > > > > > > IMO having to disable the CA before deletion is an implementation detail > > > and > > > should not be exposed to the user at all. Why do we have to disable the CA > > > from IPA in ca-del? I would expect Dogtag to disable it itself internally > > > when it's being deleted. > > > > > The CA requiring disablement before deletion is a property of how > > Dogtag Lightweight CAs are implement. I don't intend to change this > > (besides, it might need to be this way for Common Criteria; a > > similar restriction exists for profiles). > > OK. > > > > > We could make it so that in IPA context, delete permission implies > > disable permission. Currently (in Dogtag) permission to > > enable/disable is the 'modify' permission. So to do this without > > implying that someone with 'delete' permission as 'modify' > > permission, I'd need to add an explicit 'enable/disable ca' > > permission. > > +1 > > > > > This is a good idea, but it is more work to add the required ACLs > > (which will need to be done during IPA upgrade or installation). > > I'll shelve https://github.com/freeipa/freeipa/pull/415 for now, but > > keep the patch in my working branch and code it out later, if > > there's time before release. Otherwise we might need to keep it > > until there's time for the proper fix, so that things don't break. > > OK. I can give you a hand with the ACLs if you want. > Thanks. The ACLs are part of Dogtag actually; so when we upgrade to a verison of Dogtag with the new permissions, new ACLs will need to be added. There will be two versions of the ACLs: one set for use with RA Agent cert authn, and one set for use with externally authenticated FreeIPA principals.
There are a handful of similar "new ACLs to chase Dogtag changes" that will be part of the GSS-API work. I have a good understanding of what needs to happen. Cheers, Fraser -- 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