[Kimchi-devel] [RFC] Authorization enhancement

[Shu Ming]

? 2014/1/20 21:58, Aline Manera ??:
> On 01/15/2014 05:03 AM, Shu Ming wrote:
>>
>>
>>   Background
>>
>>
>> In Kimchi, now we have a basic authentication model based on PAM.  In 
>> this model, all the authenticated user get all of the privileges to 
>> access the resources in Kimchi. However, it is too simple to cause 
>> some security holes and classifying the user with different roles is 
>> a way to address the holes. Roles with very fine grained privileges 
>> need huge effort and time, so here we are trying to split the effort 
>> with several steps.  And we will discuss the first step of the effort 
>> in the below which can be achieved in a certain time bound and 
>> reserve the forward compatibility for future extensions.
>>
>>
>>   First step of the effort
>>
>>
>
> I think managing kimchi users roles will be the next step of 
> authorization.
>
> The idea for now (Kimchi 1.2) is differ between root and non-root 
> users. What does that mean?
> Users in "sudo" linux group will have full access to kimchi. And user 
> not in this group will have limited access to kimchi.
> Users with "sudo" privilege will act as admin.
>
>> In this step, the goal is to authorize the user's action on a 
>> resource by roles. The user action here is applied by the REST API 
>> exposed by Kimchi.  Every action on Kimchi resources should be 
>> checked based on the user's role.  In this step, we will not try to 
>> have roles in a very fine granularity. Naturally, three permanent 
>> roles will be created by default, the system administrator role, the 
>> infrastructure role and the user role.
>>
>>    * The system administrator get the privileges to manage the roles 
>> for the other users including assigning a role to a user, removing 
>> the role from a user &etc.  A default user "admink" will be created 
>> by default with a system administrator role assigned to it. And the 
>> role of the user "admink" can not be modified.
>>
>>    * The infrastructure role get the privileges to  manage the 
>> physical resources and virtual resources including network's creation 
>> and deletion, create or delete storage storage pools or storage 
>> volumes' creation and deletion, adding a user to the user list of 
>> storage storage pool &etc.
>>
>>    * The user role get the privileges to apply action on VMs 
>> including VMs' starting and stopping, viewing the VM console by VNC &etc.
>>
>>    * Some of the change can be enhanced on the existing REST API like 
>> "DELETE /storagepools/poo1/vo1".  But we need create new REST APIs 
>> for actions like adding a role for a user like " PUT /users/user1 
>> {role: "user role"}"
>>
>>    * Database is needed to store the user information including roles 
>> and resource user list
>
> From my view, the roles will be user groups in linux system.
> So add an user to a role is add him to a group and we don't need to 
> keep the info internally.
> Internally we will only have the map: user group => allowed URIs
Database is not necessary for this step.
Assuming the users in user groups get the roles inferred from the group 
may be not enough.   Most of the user group in Linux hosts can not 
mapped to a meaningful roles defined above.  The only meaningful logical 
group should be "root" group and "non-root" group which are composed of 
other default groups in Linux host like "bin, "sys", "adim" &etc.  
Further more,  we should keep in mind that we will use standard 
directory service like AD or LDAP to replace Linux system users,  so it 
is not a right direction to let Linux hosts users to interfere with 
Kimchi authorization in a deeper way.
>
>>
>> Beside the privileges inherited from the user's role, Kimchi will 
>> check if a user get the permission to access a resource based on a 
>> tuple.  The tuple is composed from both the privileges of the user 
>> and the user list of the resource. An example is, if a user try ti 
>> delete a storage volume from the stroage pool,  Kimchi will check if 
>> it is assigned a infrastructure role and if it is in the user list of 
>> the storage pool.
>>
>>
>>   Next step of the effort
>>
>>
>> *  The roles are defined in a very fine granularity containing the 
>> privileges precisely matching what the system administrator expects.
>>
>> *  Existing roles can by customized by the system administrator from 
>> a set of previleges.   The set of privileges should be pre-defined 
>> and hierarchy.
>>
>> * The system administrator can create new roles with customized 
>> privileges
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140121/5f1918c7/attachment.html>