9 ms·
> The ability to apply a wildcard match on the s3:ResourceAccount condition key That’s the crazy part. No good can ever come from this - there is no legitimate
by jameshart 3y ago
> The ability to apply a wildcard match on the s3:ResourceAccount condition key
That’s the crazy part. No good can ever come from this - there is no legitimate reason why you would grant or deny permission based on a partial account id match.
- efitz 3y agoThat's the part that surprised me as well; it doesn't seem like a field that should be eligible for anything other than an exact match. I am unable to conceive of a use case for pattern matching account IDs.
- sroussey 3y agoWell, that assumes that the ID is cryptographically random. Perhaps that is a bad assumption.
- pc86 3y agoEven if it's not that doesn't mean pattern matching IDs is good.
- sroussey 3y agoOh god, no. Seems like a bad idea indeed! But might give some insight into their system.
- dclowd9901 3y agoIf it's sequential, that somehow seems worse?
- jameshart 3y agoMy general assumption is not that they’re random, but at least that they’re not correlated; in particular that Amazon is not in the habit of handing out, like, account IDs 676363687000 - 676363687999 to a single organization. Even if they did hand out a sequential batch of 1000 account IDs, it would be more likely to be 676363687541 - 676363688540 than a set with a single consistent prefix. Odds are that an account wildcard match like 676363687* will just match a few hundred entirely random AWS accounts.
- dpedu 3y agoI once was involved in creating two (linked) amazon accounts at the "same" time, and ended up with account IDs of which the first 4 digits are identical.
- jameshart 3y agoA namespace you and only 100 million other accounts share - probably reasonable to just grant access to “1234*”.
- naniwaduni 3y ago> in particular that Amazon is not in the habit of handing out, like, account IDs 676363687000 - 676363687999 to a single organization Honestly, wouldn't surprise me that much if they were willing to accommodate this if for sufficiently large accounts. It'd still pretty sketchy to design your access control around, but it wouldn't be unrealistic.
- brickteacup 3y agoit's irrelevant whether they're "cryptographically" random, all that matters is that account IDs are not controlled by the user and therefore have no logical relation to any access-control policies the user may wish to implement
- twoodfin 3y agoIf for some reason you’re dealing with thousands of accounts that are architecturally indistinguishable, bucketing them by ID prefix isn’t a particularly wild thing to want to do.
- dclowd9901 3y agoCan you even block off IDs like this?
- tempay 3y agoIf you’re big enough to need it I’m sure it can be arranged.
- NovemberWhiskey 3y agoIf you're big enough to think you need it, you're also big enough to have people who can tell you it's a bad idea and there's a better tool for the job.
- leetcrew 3y agoaws support is not going to bend over backwards just to let you shoot yourself in the foot. it's more likely they grant an exception to one of the iam quotas.
- x3n0ph3n3 3y agoAt that point you should be using AWS Organizations and OUs.
- derefr 3y agoI think the GP is talking about granting access to a particular bucket to an unbounded number of customer AWS accounts — probably in requester-pays config. (Think: static data used by an Amazon Marketplace virtual appliance.)
- 3y ago
- supriyo-biswas 3y agoThis is because, I assume, the AWS policy execution has a number of “operators” and “operands”, and in this case, you’re using the StringLike operand on the account ID string. Anyway, this discussion is a bit amusing to me, since Devops people are discovering side channels[1] now, although other types of side channels such as speculative execution side channels on CPUs (Meltdown, Spectre) already made waves at the time of discovery, and before that we had power analysis[2] and Magnetostriction detection, and constant time cryptography (this one is a field of its own, so I omit references.) [1] https://en.m.wikipedia.org/wiki/Side-channel_attack https://en.m.wikipedia.org/wiki/Side-channel_attack [2] https://en.m.wikipedia.org/wiki/Power_analysis https://en.m.wikipedia.org/wiki/Power_analysis
- paulddraper 3y ago> the AWS policy execution has a number of “operators” and “operands” That is correct. The IAM condition language is flexible and does not prevent you from doing strange things.
- jameshart 3y agoIt’s a consequence of weak typing choices - not an inevitable result of allowing flexibility. Doing glob matching on account IDs is like doing concatenation with guids, applying a bitshift to a UTF8 string, or running a regex on an integer. It is a nonsensical operation, and - as shown here - results in surprising security properties of the resulting system. Surprising security properties are an undesirable result in an access control policy language.
- paulddraper 3y agoOf course it's possible to create a more sophisticated system with less possibility for user error.
- asdfaoeu 3y agoThey have ARN's which include the account which a glob match is useful. Something like "arn:aws:*:*:1234567890:*" is useful but "arn:aws:*:*:1234567*:*" isn't
- PaulHoule 3y agoProbably comes out of a tendency to generalize. Last week for one of my side projects I built something that lets you write queries in a format inspired by OWL and it has a library of relational operators that can, say, extract the host from a URL or do a prefix query, like query, regex query, etc. As it is my side project’s side project I do what is easy so these operators are always available even in cases where they don’t make sense (I dunno what happens if you try a regex query on a number, I don’t care) I can imagine there is something a bit like this inside AWS but for a security-sensitive system with a lot of users you have a different standard.
- johnklos 3y agoThis is like matching a bitfield on the group ID on a Unix system. I could see someone coming up with this idea, and I could see them thinking this is somehow smart, but implementing it on systems that aren't 100% in your control would just be silly.
- creatonez 3y ago> there is no legitimate reason why you would grant or deny permission based on a partial account id match. You're not a fan of my AWS lottery idea where accounts ending in 666 get access to a free bitcoin miner??
- lobsterthief 3y agoI love the idea, but maybe we can pair it with my ICO idea of flipping a virtual stack of Pogs to unlock new units of currency that can be mined.