3 ms·

If this had been another s3 bucket on AWS we would be blaming amazon. Here we don’t blame jira/atlassian. Why do we do this? (Honest question)

deleted 7y ago
[deleted]
viraptor 7y ago
> we would be blaming amazon Would we? Amazon requires you to explicitly make the bucket open. It also allows you to prevent that account-wide with IAM policies. It also allows delegating the opening to public to specific people. And I believe you get warnings about public buckets from their advisor. (May be misremembering that one) You can easily audit that too. So basically I don't see what else could AWS do to make this more secure. It's 100% on the user at this point.
- Godel_unicode 7y ago
  > Would we? By all current evidence, we'd blame Capital One, so I guess this is consistent?
BinaryIdiot 7y ago
When you setup an S3 bucket the permissions are pretty explicit. The issue here is the UI is confusing (arguably it's wrong but I digress) and is related to a configuration that you'd have to hunt for. It's not an obvious permission that you can easily know it should be changed unless you have experience with it (whereas S3 it's listed right there when you created it and by default it's pretty private).
- deleted 7y ago
  [deleted]
- paulstovell 7y ago
  It didn’t used to be. When you set up a bucket with public read access, you might also decide to give other people on your team write access to the bucket. AWS conveniently provided an All Users option for this. Except it wasn’t “All Users in your AWS account”, it literally meant ALL USERS of AWS. Disaster. This led to the same problems as this Jira issue. AWS changed it so that’s no longer an option. Atlassian should do the same.
Thorrez 7y ago
Huh? It seems the exact opposite of that. The top comment here is blaming Jira[1]. But when Capital One got hacked last week due to apparently some AWS misconfiguration, it seemed no one blamed AWS (even though the hacker had previously worked at AWS)[2]. [1] https://news.ycombinator.com/item?id=20597264 https://news.ycombinator.com/item?id=20597264 [2] https://news.ycombinator.com/item?id=20560342 https://news.ycombinator.com/item?id=20560342

deleted 7y ago

[deleted]

viraptor 7y ago

> we would be blaming amazon Would we? Amazon requires you to explicitly make the bucket open. It also allows you to prevent that account-wide with IAM policies. It also allows delegating the opening to public to specific people. And I believe you get warnings about public buckets from their advisor. (May be misremembering that one) You can easily audit that too. So basically I don't see what else could AWS do to make this more secure. It's 100% on the user at this point.

Godel_unicode 7y ago
> Would we? By all current evidence, we'd blame Capital One, so I guess this is consistent?

BinaryIdiot 7y ago

When you setup an S3 bucket the permissions are pretty explicit. The issue here is the UI is confusing (arguably it's wrong but I digress) and is related to a configuration that you'd have to hunt for. It's not an obvious permission that you can easily know it should be changed unless you have experience with it (whereas S3 it's listed right there when you created it and by default it's pretty private).

deleted 7y ago
[deleted]
paulstovell 7y ago
It didn’t used to be. When you set up a bucket with public read access, you might also decide to give other people on your team write access to the bucket. AWS conveniently provided an All Users option for this. Except it wasn’t “All Users in your AWS account”, it literally meant ALL USERS of AWS. Disaster. This led to the same problems as this Jira issue. AWS changed it so that’s no longer an option. Atlassian should do the same.

Thorrez 7y ago

Huh? It seems the exact opposite of that. The top comment here is blaming Jira[1]. But when Capital One got hacked last week due to apparently some AWS misconfiguration, it seemed no one blamed AWS (even though the hacker had previously worked at AWS)[2]. [1] https://news.ycombinator.com/item?id=20597264 https://news.ycombinator.com/item?id=20597264 [2] https://news.ycombinator.com/item?id=20560342 https://news.ycombinator.com/item?id=20560342