[posnet]

"fine-grained access control in complex environments"

Oh that sounds...

"...is inspired by AWS IAM Policies."

Oh god no.

My day to day work is debugging IAM polices that have accidentally given global s3 write access or everyone but admins, admin access.

[jopsen]

I agree... IAM policies are too complicated.

For services I write I've been using simple permission strings. Call them scopes on the form: 'service:action:resource/sub-resource...'

Each client is then associated a set of scopes, if a scope ends with '' it matches all suffixes. And then you just ask if a client has a set of scopes.

By only allowing at the end, and otherwise just having permission as a set of strings you can most interesting operations: - intersection - union - empty-set - sub-set between any two sets of scopes.

Hence, you can do do automated reasoning about permissions assigned. For example you check automatically verify an assumption that no role grants a scope A to a user who also has scope B.

Lack of support for doing combining IAM policies makes it hard to verify your policies with high-level assertions.

[golangman]

Why do those policies make it there in the first place? Could you share some scenarios? I'd love to improve the managibility of policies :)

The hydra ( http://github.com/ory/hydra ) project for example has groups, which allow you to set e.g. an admin group and then assign people to it. I think this helps a lot with managing policies!

[posnet]

It almost always comes down to complexity.

The inclusion of boolean logic in the policies is the root cause.

Specifically, having not resources, or not principals and their interaction with the other policies in the account.

The second highest common cause is misunderstanding how the default deny works.

Again, not really an issue with the landon project, but more an observation on how added power (complexity) to access control systems can sometimes make things less secure.

[schlarpc]

Just to give an example of the pain that can be caused by NotAction in practice: https://www.reddit.com/r/aws/comments/3recc9/this_iam_policy...

This policy looks reasonable to a casual observer, but actually gives * access to everything in the account. IAM policies are _hard_.

[dastbe]

Yeah, I can see how using "Not" as opposed to "Inverted" would trip up people here. However, I would say that's a naming issue and (for some reason) a resiliency to using explicit deny policies.