[Freeipa-devel] [DESIGN] IPA permission enforcement in Dogtag

[Jan Cholasta]

On 8.2.2017 08:06, Fraser Tweedale wrote:
> 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.

I see. I though you meant ACIs on IPA side.

Are we not going to rely on our ACIs for access control in Dogtag + GSSAPI?

>
> Cheers,
> Fraser
>


-- 
Jan Cholasta