[
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)
