Bug #46078
closedinvalid principal arn in bucket policy grants access to all
0%
Description
if I have an invalid principal in a bucket policy, access is granted to all users according to the action specified.
1. have a radosgw user create a bucket, in this case foobucket
2. Using the attached bucket policy, apply it with aws s3api put-bucket-policy --bucket foobucket --policy file://foobucket.json
3. after being applied, any user can access the bucket with the level of 'Action' specified in the policy.
Note, the arn for the user in the policy is incorrect. It should be:
"arn:aws:iam:::user/username"
not:
"aws:iam:::username"
A bad policy entry should NOT allow access to everybody (fail closed as opposed to fail open)
This may be related to https://tracker.ceph.com/issues/45912
I've reproduced this on 15.2.2 and 15.2.3 on CentOS 8
Files
Updated by Casey Bodley almost 4 years ago
- Assignee set to Adam Emerson
- Priority changed from Normal to High
Updated by Chris Durham almost 4 years ago
Chris Durham wrote:
if I have an invalid principal in a bucket policy, access is granted to all users according to the action specified.
1. have a radosgw user create a bucket, in this case foobucket
2. Using the attached bucket policy, apply it with aws s3api put-bucket-policy --bucket foobucket --policy file://foobucket.json
3. after being applied, any user can access the bucket with the level of 'Action' specified in the policy.
Note, the arn for the user in the policy is incorrect. It should be:
"arn:aws:iam:::user/username"
not:
"aws:iam:::username"A bad policy entry should NOT allow access to everybody (fail closed as opposed to fail open)
This may be related to https://tracker.ceph.com/issues/45912
I've reproduced this on 15.2.2 and 15.2.3 on CentOS 8
On second thought, probably NOT related to https://tracker.ceph.com/issues/45912 This bug deals with user ARNs and the other bug relates to bucket ARNs, so probably not the same parsing code....just a thought
Updated by Pritha Srivastava almost 4 years ago
I tried the following steps on both master and 15.2.2, but failed to reproduce the error:
1. Create 3 users
2. Create a bucket bucket1 using credentials of user1
3. Attach policy to bucket bucket1, to allow access to user2 using incorrect ARN format ("Principal": {"AWS": "aws:iam:::TESTER"},)
4. Access bucket using credentials of user3 (Action is set to s3:* in the bucket policy)
Step 4 gives an AccessDenied error.
@Chris: Are the repro steps correct?
Updated by Chris Durham almost 4 years ago
Pritha Srivastava wrote:
I tried the following steps on both master and 15.2.2, but failed to reproduce the error:
1. Create 3 users2. Create a bucket bucket1 using credentials of user1
3. Attach policy to bucket bucket1, to allow access to user2 using incorrect ARN format ("Principal": {"AWS": "aws:iam:::TESTER"},)
4. Access bucket using credentials of user3 (Action is set to s3:* in the bucket policy)
Step 4 gives an AccessDenied error.
@Chris: Are the repro steps correct?
@Pritha: Your steps seem correct, so I tried again, and was able to easily reproduce. However, I discovered something new. If I have:
{ "Principal": {"AWS": ["arn:aws:iam:::user"]} it reproduces fine, all users have access, as this arn is invalid (no 'user/')
If I have:
{ "Principal": {"AWS": ["arn:aws:iam:::user"], ["arn:aws:iam:::user/username"]}}
The second in this list being a properly constructed ARN, the problem does NOT occur and only arn:aws:iam:::user/username has access.
If this does not help, I'll generate up some debug rgw = 20 logs for you
I discovered this quite by accident when I tried to give access to just one user (but put in an invalid ARN) and the next day discovered that all my users had access, after which I tracked it to the invalid ARN.
Updated by Chris Durham almost 4 years ago
Chris Durham wrote:
Pritha Srivastava wrote:
I tried the following steps on both master and 15.2.2, but failed to reproduce the error:
1. Create 3 users2. Create a bucket bucket1 using credentials of user1
3. Attach policy to bucket bucket1, to allow access to user2 using incorrect ARN format ("Principal": {"AWS": "aws:iam:::TESTER"},)
4. Access bucket using credentials of user3 (Action is set to s3:* in the bucket policy)
Step 4 gives an AccessDenied error.
@Chris: Are the repro steps correct?
@Pritha: Your steps seem correct, so I tried again, and was able to easily reproduce. However, I discovered something new. If I have:
{ "Principal": {"AWS": ["arn:aws:iam:::user"]} it reproduces fine, all users have access, as this arn is invalid (no 'user/')
If I have:
{ "Principal": {"AWS": ["arn:aws:iam:::user"], ["arn:aws:iam:::user/username"]}}
The second in this list being a properly constructed ARN, the problem does NOT occur and only arn:aws:iam:::user/username has access.
If this does not help, I'll generate up some debug rgw = 20 logs for you
I discovered this quite by accident when I tried to give access to just one user (but put in an invalid ARN) and the next day discovered that all my users had access, after which I tracked it to the invalid ARN.
Note, the entry should be:
{ "Principal": {"AWS": ["arn:aws:iam:::user", "arn:aws:iam:::user/username"]}}
a single list
Updated by Abhishek Lekshmanan almost 4 years ago
- Assignee changed from Adam Emerson to Abhishek Lekshmanan
Updated by Abhishek Lekshmanan over 3 years ago
- Status changed from New to Fix Under Review
- Pull request ID set to 36303
Updated by Casey Bodley over 3 years ago
- Tags set to iam
- Backport set to nautilus octopus
Updated by J. Eric Ivancich over 3 years ago
- Status changed from Fix Under Review to Pending Backport
Updated by Nathan Cutler over 3 years ago
- Copied to Backport #46953: octopus: invalid principal arn in bucket policy grants access to all added
Updated by Nathan Cutler over 3 years ago
- Copied to Backport #46954: nautilus: invalid principal arn in bucket policy grants access to all added
Updated by Nathan Cutler over 3 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".