Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Wed, 30 Apr 2014 17:50:18 +0000 (UTC)
From: "Prachi Damle (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12710669.1398462762139.207967.1398880218167@arcas>
In-Reply-To: <JIRA.12710669.1398462762139@arcas>
References: <JIRA.12710669.1398462762139@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-6517) IAM - Admin is allowed to
 create PortFowarding rule for a regular user, when admin does not have "
 UseEntry" permission for IpAddress.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985818#comment-13985818 ] 

Prachi Damle commented on CLOUDSTACK-6517:
------------------------------------------

Analysis

Subtask- CLOUDSTACK-6545
- IAM was applying ordering on accessTypes. Thus if an account had OperateEntry access, he got USEEntry access as well. 
- So even if IAM schema did not have 'UseEntry" permission for IpAddress, some other 'OperateEntry' permission on IpAddress was letting this operation go through.
- Upon analysis, this should not be done at the IAM level. Reason being, due to AccessType ordering, admin policy gets permission to USE resources from other account just because he has OPERATE access on those resources due to some other APIs.
- So we should fix IAM to NOT do ordering of access types anymore. IAM will perform strict accessType check only.
- Subtask is logged for this fix


Subtask- CLOUDSTACK-6546
- Now due to this fix, we break backwards compatibilty with CS 4.3.
- CS 4.3 allowed root admin to do the createPF operation for a user by passing in networkId of the user.
- Same was the case for domain admins within their domains
- Why this worked in CS 4.3 because in CS 4.3 no IAM checks happen for admins. It simply returns true for root admin/domain admin(within his domain)
- So to maintain backwards compatibilty, we need to add the logic to return "true" for root admin and domain admin just like CS 4.3 in CS 4.4
- This logic will be part of CloudStack core and not IAM. Per IAM these operation will not be allowed. But CS needs this logic to override that decision inorder to maintain backwards compatibility.
- Exception is: For Network, AffinityGroup and Templates, we still will respect IAM even for root admin/domain admin, since CS 4.3 did access checks for these resource_types. 
- So just for these 3 resource_types, it used to perform access checks even for root admin/domain admin and Cs 4.4 IAM will do that.
- True way to let IAM handle this is to refactor CloudStack code to handle Impersonation at every API consistently.

> IAM - Admin is allowed to create PortFowarding rule for a regular user, when admin does not have " UseEntry" permission for IpAddress. 
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-6517
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6517
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: IAM
>    Affects Versions: 4.4.0
>         Environment: Build from 4.4
>            Reporter: Sangeetha Hariharan
>            Assignee: Prachi Damle
>             Fix For: 4.4.0
>
>
> IAM - Admin is allowed to create PortFowarding rule for a regular user, when admin does not have " UseEntry" permission for IpAddress.
> Steps to reproduce the problem:
> As regular user , on a network he owns , acquire an ip address.
> As admin , try to create a PF rule on this ip address  without passing account and domainId.
> Creating PF rule succeeds. 
> Since Admin has only  "ListEntry" permission for IpAddress owned by other users , we expect this api call to fail. 
> mysql> select * from iam_policy_permission where resource_type = 'IpAddress' and policy_id=2;
> +------+-----------+-----------------------+---------------+----------+---------+--------------+------------+-----------+---------+---------------------+
> | id   | policy_id | action                | resource_type | scope_id | scope   | access_type  | permission | recursive | removed | created             |
> +------+-----------+-----------------------+---------------+----------+---------+--------------+------------+-----------+---------+---------------------+
> | 1840 |         2 | listPublicIpAddresses | IpAddress     |       -1 | ALL     | ListEntry    | Allow      |         0 | NULL    | 2014-04-22 18:31:03 |
> | 1841 |         2 | listPublicIpAddresses | IpAddress     |       -1 | ACCOUNT | UseEntry     | Allow      |         0 | NULL    | 2014-04-22 18:31:03 |
> Admin should be allowed to do this only , when he passes account and domainId of the regular user is passed.


--
This message was sent by Atlassian JIRA
(v6.2#6252)