fix(model): honour role trust policy as resource policy for sts:AssumeRole#32
Open
xoverride wants to merge 1 commit into
Open
fix(model): honour role trust policy as resource policy for sts:AssumeRole#32xoverride wants to merge 1 commit into
xoverride wants to merge 1 commit into
Conversation
…eRole
A role's trust policy (AssumeRolePolicyDocument) is the resource policy
that governs sts:AssumeRole, but it is stored in the GAAD rather than in
the explicitly loaded resource policies. generate_solver only consulted
resource_policies, so when a role was the *target* of an assume its trust
constraint was set to False, making z3.Bool("resource") unsatisfiable and
denying every same-account and cross-account assume that AWS allows.
Resolve the target role's trust policy from the loaded GAAD on demand when
no explicit resource policy exists, for both can_i and the source-account
pruning in _check_viable_source_accounts (so who_can finds cross-account
assumers). Explicit resource policies still take precedence.
Add the first sts:AssumeRole integration tests: explicit-principal trust,
:root delegation trust, non-matching trust, :root without identity
permission, and who_can resolution.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
IAMSpy returns denied for
sts:AssumeRolecalls that AWS allows, for both same-account and cross-account assumes, whenever the target is an IAM role.A role's trust policy (
AssumeRolePolicyDocument) is the resource policy that governssts:AssumeRole, but it lives in the GAAD rather than in the resource policies loaded viaload_resource_policies.generate_solveronly consultedresource_policies, so when a role was the target of an assume,add_resourcefound nothing and setresource_<target> == False. That makesz3.Bool("resource")unsatisfiable, and since thests:assumerolerule requiresresourceto be true, every assume was denied.This affected both an explicit
Principal:{AWS:".../Caller"}trust and an account-rootPrincipal:{AWS:"...:root"}trust — confirming the defect is in resource-side trust loading, not:rootresolution.Root cause
iamspy/model.py—generate_solverresource loop only loaded explicitly-provided resource policies; a target role's trust doc was never loaded resource-side. A secondary instance in_check_viable_source_accountspruned cross-account sources for trust-only roles, sowho_canmissed cross-account assumers.Fix
_get_role_trust_policyhelper). Explicit resource policies still take precedence._check_viable_source_accountsso cross-account assumers are evaluated.Tests
First
sts:AssumeRoleintegration tests in the suite::rootdelegation trust -> allowed:roottrust but caller lackssts:AssumeRoleidentity permission -> denied (delegation still requires identity)who_canresolves only the identity-permitted callerAll 46 tests pass.