# Proper Mastodon, Proper Permissions

## After a kind exploitation, I'm taking it even more seriously

You know how every time any startup deployed software for the 2010s, a news article was posted 6-12 months later about how their files were all stored in a completely unprotected S3 bucket? It’s my turn and it’s a speedrun!

## Kindness of strangers

Mere days after deploying Mastodon the second time, I received a message from @dylan@newsie.social:

Hi, I wanted to inform you that your current access policy on Minio gives anyone complete freedom with your storage. This includes adding new files and deleting existing files. As a proof, I deleted your profile picture (don’t be mad please) (you may have to clear your browser’s cache). I also uploaded this file: …

## Fix it fix it fix it

Just change Minio’s bucket setting from public (which shouldn’t be an option, and definitely shouldnt’ be the default) to custom. Then give it the following policy where it can only s3:GetObject.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::bfd-so/*"
]
}
]
}


## Then how does Mastodon write to it?

Mastodon uses the user or API key permissions to do the writing. The bucket policy applies to unauthenticated users.

Under Access Keys, check the key that matches your AWS_ACCESS_KEY_ID and make sure it can PutObject and DeleteObject.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bfd-so"
]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:DeleteObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::bfd-so/*"
]
}
]
}


## Check for other access concerns while you’re at it

Check other buckets for public. Check other access keys to be sure the Resource is set to the specific buckets they should access.

## Hope that your next vulnerability is found by a kind stranger

I’m sure this isn’t the last.