I am not sure if this was a conscious design decision or not. Dependent actions are always added with wildcards (*) and may not be the expected behavior.
Example
When generating a policy document for write actions on a KMS key ARN, the dependent actions are added as wildcards which could lead to granting more permissions than anticipated.
kms:ReplicateKey is a write action that is added when I specify a key ARN (as designed)
Two dependent actions of it are kms:CreateKey and kms:PutKeyPolicy
I understand kms:CreateKey has no resource requirements and is added as a wildcard. kms:PutKeyPolicy on the other hand CAN take a key ARN as a resource constraint but is indiscriminately added as a wildcard action as well. This leads to the generated policy being able to put a key policy on any KMS key (if a key has the default key policy or an overly permissive one)
I attempted to add a bit of code to writing/sid_group.py to add the dependent action to the same SID as the other actions if they share the same resource constraint (but part of a different access_level).
if len(dependent_actions) > 0:
for dep_action in dependent_actions:
# If a dependent action has the same resource constraint, add it to actions
# instead of * which could grant more access than anticipated.
for level in ["Read", "Write", "List", "Tagging", "Permissions management"]:
if dep_action in get_actions_with_arn_type_and_access_level(
service_prefix, resource_type_name, level):
if not dep_action in actions:
actions.append(dep_action)
if not dep_action in actions:
self.add_action_without_resource_constraint(dep_action)
I am not sure if this was a conscious design decision or not. Dependent actions are always added with wildcards (*) and may not be the expected behavior.
Example
When generating a policy document for write actions on a KMS key ARN, the dependent actions are added as wildcards which could lead to granting more permissions than anticipated.
kms:ReplicateKey
is a write action that is added when I specify a key ARN (as designed) Two dependent actions of it arekms:CreateKey
andkms:PutKeyPolicy
I understand
kms:CreateKey
has no resource requirements and is added as a wildcard.kms:PutKeyPolicy
on the other hand CAN take a key ARN as a resource constraint but is indiscriminately added as a wildcard action as well. This leads to the generated policy being able to put a key policy on any KMS key (if a key has the default key policy or an overly permissive one)Observed behavior
Expected behavior
Possible remediation
I attempted to add a bit of code to
writing/sid_group.py
to add the dependent action to the same SID as the other actions if they share the same resource constraint (but part of a different access_level).