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

[Jan Cholasta]

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.

-- 
Jan Cholasta