Part of my series on Automating Cybersecurity Metrics. AWS Organizations. IAM. Deploying a Static Website. The Code.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
In my last post I explained how to terminate an AWS CLI session.
In this post, I want to try to prevent privilege escalation using an AWS IAM Permission Boundary. I wrote about IAM Permission Boundaries in this post.
Keep this complication in mind if you use a Permission Boundary. If you apply a permission boundary to an existing principal that accesses resources they may be locked out of things they need to access. I've seen issues like this make S3 buckets inaccessible when the administrator was the only one allowed to manage the bucket. I am not sure why this problem exists and why AWS can't fix it.
Here's the thing that honestly confuses me the way the AWS documentation describes permission boundaries.
On the one had the AWS documentation describes them as a way to limit the IAM Policies the user can create:
A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity.
In the next sentence, it sounds like a permission boundary limits the actions the principal can take to whom the permission boundary is applied.
An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.
So let's say you grant a user S3 and IAM permissions. If you don't grant S3 permissions in the permission boundary which of the following can the principal (user or role) do?
- Perform S3 actions
- Create a policy with S3 actions
- Assign a policy with S3 actions to a user
- Assign a policy with S3 actions to a role
- Assign a policy with S3 actions to a group
- Assign a user to a group that is allowed to perform S3 actions in a directly assigned policy
- Assign a user to a group that is allowed to assume a role that can perform S3 actions
- Assign a role to an EC2 instance that can perform S3 actions
- Assign a role to a Lambda function that can perform S3 actions
- Assign a role to a Lambda function that can assume a role that can perform S3 actions
- Create a policy with Lambda actions
Do you know which ones the principal can and cannot perform? Let's test.
Here's what I create:
- A manual user named TestPB
- I assign a policy directly to the user that allows s3:* and iam:*
- I create a permission boundary that only allows iam:*
On the user details page:
I assign the IAM full access permission, but no S3 permissions.
Now the permission boundary is set:
Let's test our actions one by one.
Perform S3 actions
Login as the test user. Navigate to S3 buckets.
With the above policy configuration, the user cannot view the S3 buckets even though the user has full S3 permission.
Create a policy with S3 actions
Navigate to IAM and Policies.
Choose all S3 list actions.
All resources:
Name the policy and save it:
I was able to create the S3 policy.
What if I change the policy to s3:*
Policy created and successfully updated.
Assign a policy with S3 permissions to a user
Create a user.
Assign the new policy to the user.
Was I able to create the user? Yes.
Does the user have S3 permissions? Yes.
Well, I don't have to go through the motions of assigning the policy to a role or group or assigning these permissions to an EC2 instance. The permission boundary isn't stopping any of that which is a bit confusing based on how the documentation is worded. What it is doing is limiting the permissions of the actions the user can take. The user cannot take any actions not in the permission boundary, but they are not restricted from giving other people permissions that are not in the permission boundary.
Create a policy with Lambda permissions
What about the last item on the list? Can the user with the above permission create a policy that allows Lambda actions?
Yes.
So what was this policy doing for us again?
Permission Boundaries with Deny actions
What if we deny all but IAM actions in our Permission Boundary?
What if we deny all but IAM actions in the policy?
Create the policy:
Assign the policy as a Permission Boundary on the TestPB user.
Can the TestPB user access S3?
No.
Can the TestPB user create an S3 policy? Well, no, because the user can't even List IAM policies anymore.
Clearly that's not what we want.
What if we allow all IAM actions and Deny all but IAM actions?
Here I am explicitly allowing all IAM but denying any actions that are not IAM.
Can the user create a policy that allows S3 actions?
Yes.
So what were permission boundaries supposed to do again?
Let's consider this statement:
A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity.
That's a bit misleading. That's not actually what this permission boundary is doing.
But this statement is accurate:
An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.
The explanation is misleading though not entirely inaccurate. Let's try to clear it up.
A simpler explanation of a how to use a permission boundary
If you read the documentation for Permission Boundaries it is using a fairly complex policy to try to explain what the Permission Boundary is doing. Let's make it simpler.
The key to using a permission boundary is this:
- Create a Permission Boundary with the maximum permissions you want to allow.
- Add a statement to the administrator policy that only allows them to create a new user or role with a specific permission boundary assigned.
The effective outcome of that restriction is that no matter what permissions the user assigns in the policy, it cannot exceed the permissions granted in the permission boundary.
What I want to do is to limit my test user from creating an IAM user or Role that does not have the Permission Boundary attached to it.
That boils down to adding this condition to the applicable IAM actions:
You also need to make sure the admin cannot modify the Permission Boundary:
The permission boundary does not limit the policies or roles that the admin can assign to resources either. You'll need to handle that in the primary IAM Policy for the administrator to prevent privilege escalation that can occur from other mechanisms I wrote about in prior IAM posts.
Now that the purpose and implementation of IAM Boundaries is clearer, we can add one to our accounts and modify our admin user policy to limit the policies they can create and assign.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
The best way to support this blog is to sign up for the email list and clap for stories you like. If you are interested in IANS Decision Support services so you can schedule security consulting calls with myself and other IANS faculty, please reach out on LinkedIn via the link below. Thank you!
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
Author: Cybersecurity for Executives in the Age of Cloud
Presentations: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Security Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Software Engineering, Master of Infosec
Company: Cloud Penetration Tests, Assessments, Training ~ 2nd Sight Lab
Like this story? Use the options below to help me write more!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Clap
❤️ Referrals
❤️ Medium: Teri Radichel
❤️ Email List: Teri Radichel
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ Threads: @teriradichel
❤️ Bluesky: @teriradichel
❤️ YouTube: @2ndsightlab
❤️ Buy a Book: Teri Radichel on Amazon
❤️ Request a penetration test, assessment, or training
via LinkedIn: Teri Radichel
❤️ Schedule a consulting call with me through IANS ResearchMy Cybersecurity Book: Cybersecurity for Executives in the Age of Cloud
