rage.fail

aws-ec2-modify-image-attr

derived aws emits CanModifyConfiguration

match (effective permission)

{ "action": "ec2:ModifyImageAttribute", "resource_type": "AWS::EC2::Image" }

emit

source type	`Identity`
target type	`*`
source	`<principal>`
target	`<AMI in scope>`
permissions	`ec2:ModifyImageAttribute`
conditions	`iam_permission`

Narrative

{principal.name} can modify AMI {image.name} attributes (ec2:ModifyImageAttribute), influencing imdsSupport/launchPermission/description for future instances that boot from it.

Raw rule rules/derived/aws/ec2.yaml

id: aws-ec2-modify-image-attr
emits: CanModifyConfiguration
match_effective_permission:
  action: ec2:ModifyImageAttribute
  resource_type: AWS::EC2::Image
emit:
  source_type: Identity
  target_type: '*'
  source: <principal>
  target: <AMI in scope>
  permissions:
  - ec2:ModifyImageAttribute
  conditions:
  - iam_permission
  note: ModifyImageAttribute only changes launchPermission/imdsSupport/description, never the on-disk
    blocks. Cross-account sharing (launchPermission) is modeled by aws-ec2-share-ami; genuine AMI code
    control is aws-ec2-create-image.
  false_positive_note: ModifyImageAttribute changes launchPermission/imdsSupport/description, not the
    image blocks themselves; it does NOT poison the AMI's executable content. True in-place code poisoning
    requires ec2:CreateImage from a compromised instance (see aws-ec2-create-image). Treat this as configuration/launch
    influence, not a binary edit.
  narrative: '{principal.name} can modify AMI {image.name} attributes (ec2:ModifyImageAttribute), influencing
    imdsSupport/launchPermission/description for future instances that boot from it.'