3 ms·

Yes. Most auth systems do to the developer - GCP & AWS IAM give particularly detailed errors; nearly every feature/permission system I have implemented did. How

Yes. Most auth systems do to the developer - GCP & AWS IAM give particularly detailed errors; nearly every feature/permission system I have implemented did. However, it wouldn't be unusual for the full error to be wrapped or swallowed by some lazy error handling. Its a bit of a PITA but well worth it to translate to a safe and informative user facing error. as a nit; RBAC is applied to an object based permissions system rather than being one. Simply, RBAC is a simplification of permission management in any underlying auth system.

8note 2y ago
ive never seen aws give a useful error where i could say which resources need a handshake of permissions, or which one of the two needs the permission granted, or which permission needs to be granted.
- milch 2y ago
  AWS throws errors that look like `arn:aws:iam:... is not authorized to call "$SERVICE_NAME:$API_NAME" on resource arn:aws:$SERVICE_NAME:...`. I think it's more complicated when you go cross account, and the receiving account doesn't have permissions set up (if the calling account doesn't have it set up you get the same error). In any case you would still find that information in the CloudTrail logs of the receiving account
  - hobs 2y ago
    Right, you can go to cloudtrail and probably get it, but I have definitely ran into things like service says you do not have access to resource or it does not exist - randomly providing the account some other tangentially related permission magically fixes it, I've found sometimes trying the UI and the API will give different errors to help, and neither is particularly more useful than the others.
    - deleted 2y ago
      [deleted]
    - bshacklett 2y ago
      assuming you can get the cloud trail message sometimes there’s more information that you can decode using the STS service: https://docs.aws.amazon.com/cli/latest/reference/sts/decode-authorization-message.html https://docs.aws.amazon.com/cli/latest/reference/sts/decode-...
    - donavanm 2y ago
      Look in to the AWS IAM “service description files” aka SDF. Thats exposed via the console Policy Builder or Policy Evaluator logic. The SDF _should_ encode all the context (eg resource attributes, principal metadat) that goes in to the authz decision. The most common opaque issue youll see is where one action has other required resources/actions. Eg a single action attaching an ebs volume requires permission on both instance and volume and _maybe_ kms key with permissions across those services.
- donavanm 2y ago
  This is intentional. You, the caller, get a generic http 400 “resource does not exist or are not authorized” response and message. Providing additional information about resource existence or permissions opens an entire category of information disclosure, resource discovery, attribute enumeration, policy enumeration problems. The IAM admin persona is the one who gets a bunch of additional information. Thats accessible through aws iam policy builder, access logs, etc. And no, its not feasible to determine if the initial caller is an appropriate iam admin persona and vary the initial response.
  - Atotalnoob 2y ago
    Just add this to the end of the error message “If this resource exists, you will need to add permission X. “
    - donavanm 2y ago
      A late reply, but thats not how AWS IAM (or most advanced authz systems) work. AWS IAM is a “capability” system with dynamic policies; its nothing so simple as a “role” based authorization contrary to some product naming. To wit, every authz evaluation is a dynamic evaluation of policy and context. Each check uses one or more policies with one or more policy statements that are combined with some boolean logic and predicate rules. The policies may be associated (sourced) with the particular request based on calling principal, principal attributes, the target resource, a related resource, or even other metadata like AWS Org membership. Thats combined with the point in time context from the request (ex action name, parameters), request metadata (eg time), principal (id, tags, etc), resource (arn, attributes, tags), and some more “system” specific context variables. You (and the authorizing service) need ALL of that information to perform an authz evaluation. This is complicated by dynamic data, like time or source address or caller principal tag values, so even identical requests may have different results. There are also complications like DENY statements and “unless” predicates that entirely defeat a simple “resource x requires y” approach. Evem if you solve all of those challenges via magic you end up back at information disclosure where your adversary is now capable of rapidly enumerating and testing all your authz policies!
  - 2y ago
winwang 2y ago
Slightly disagree at least for GCP. It will error with a detailed permission, but you're not just going to add that -- you're going to add a role (standard, unless you have custom roles), which you technically have to map back to the permission you need. But also, those (standard) roles have many permissions in one, so you likely overprovision (though presumably by just a bit). ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.
- da_chicken 2y ago
  > ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep. The problem with that is that it can be difficult to know what you need, and it may be impossible to simulate in any practical sense. Like, sure, I can stand up a pair of test systems and fabricate every scenario I can possibly imagine, but my employer does want me to do other things this month. And what happens when one of the systems involves a third party? Really, the need is to be able to provision access after the relationship is established. It's weird that you need a completely new secret to change access. Imagine if this were Linux and in order to access a directory you had to provision a new user to do it? How narrow do you really think user security access would be in practical terms then?
  - winwang 2y ago
    > the need is to be able to provision access after the relationship is established Could you go into more detail? At a base level interpretation, this is how it works already (you need a principal to provision access for...), but you presumably mean something more interesting?
    - da_chicken 2y ago
      With token-based access, you typically assign the role when the token is created. The access level the token has is typically locked at that point. If you're generating an API access token, you might specify the token is read-only. If you later decide that read/write access is needed, you need to generate a new token with the new access level and replace the token id and value in the client system. It's not difficult, but it's a much bigger pain in the ass than just changing access or changing role on a user.
raverbashing 2y ago
But obviously then the security people will raise ruckus about any attempt of telling you what is wrong (Which ok, for an external facing system is ok) I can bet the huge prevalence of "system says no, and nothing tells you why" helps a lot with creating vulnerable systems. System need an "let X person do Action" instead of having people waddle through 10 options like SystemAdminActionAllow that don't mean anything to an end user

8note 2y ago

ive never seen aws give a useful error where i could say which resources need a handshake of permissions, or which one of the two needs the permission granted, or which permission needs to be granted.

milch 2y ago
AWS throws errors that look like `arn:aws:iam:... is not authorized to call "$SERVICE_NAME:$API_NAME" on resource arn:aws:$SERVICE_NAME:...`. I think it's more complicated when you go cross account, and the receiving account doesn't have permissions set up (if the calling account doesn't have it set up you get the same error). In any case you would still find that information in the CloudTrail logs of the receiving account
- hobs 2y ago
  Right, you can go to cloudtrail and probably get it, but I have definitely ran into things like service says you do not have access to resource or it does not exist - randomly providing the account some other tangentially related permission magically fixes it, I've found sometimes trying the UI and the API will give different errors to help, and neither is particularly more useful than the others.
  - deleted 2y ago
    [deleted]
  - bshacklett 2y ago
    assuming you can get the cloud trail message sometimes there’s more information that you can decode using the STS service: https://docs.aws.amazon.com/cli/latest/reference/sts/decode-authorization-message.html https://docs.aws.amazon.com/cli/latest/reference/sts/decode-...
  - donavanm 2y ago
    Look in to the AWS IAM “service description files” aka SDF. Thats exposed via the console Policy Builder or Policy Evaluator logic. The SDF _should_ encode all the context (eg resource attributes, principal metadat) that goes in to the authz decision. The most common opaque issue youll see is where one action has other required resources/actions. Eg a single action attaching an ebs volume requires permission on both instance and volume and _maybe_ kms key with permissions across those services.
donavanm 2y ago
This is intentional. You, the caller, get a generic http 400 “resource does not exist or are not authorized” response and message. Providing additional information about resource existence or permissions opens an entire category of information disclosure, resource discovery, attribute enumeration, policy enumeration problems. The IAM admin persona is the one who gets a bunch of additional information. Thats accessible through aws iam policy builder, access logs, etc. And no, its not feasible to determine if the initial caller is an appropriate iam admin persona and vary the initial response.
- Atotalnoob 2y ago
  Just add this to the end of the error message “If this resource exists, you will need to add permission X. “
  - donavanm 2y ago
    A late reply, but thats not how AWS IAM (or most advanced authz systems) work. AWS IAM is a “capability” system with dynamic policies; its nothing so simple as a “role” based authorization contrary to some product naming. To wit, every authz evaluation is a dynamic evaluation of policy and context. Each check uses one or more policies with one or more policy statements that are combined with some boolean logic and predicate rules. The policies may be associated (sourced) with the particular request based on calling principal, principal attributes, the target resource, a related resource, or even other metadata like AWS Org membership. Thats combined with the point in time context from the request (ex action name, parameters), request metadata (eg time), principal (id, tags, etc), resource (arn, attributes, tags), and some more “system” specific context variables. You (and the authorizing service) need ALL of that information to perform an authz evaluation. This is complicated by dynamic data, like time or source address or caller principal tag values, so even identical requests may have different results. There are also complications like DENY statements and “unless” predicates that entirely defeat a simple “resource x requires y” approach. Evem if you solve all of those challenges via magic you end up back at information disclosure where your adversary is now capable of rapidly enumerating and testing all your authz policies!
- 2y ago

winwang 2y ago

Slightly disagree at least for GCP. It will error with a detailed permission, but you're not just going to add that -- you're going to add a role (standard, unless you have custom roles), which you technically have to map back to the permission you need. But also, those (standard) roles have many permissions in one, so you likely overprovision (though presumably by just a bit). ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.

da_chicken 2y ago
> ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep. The problem with that is that it can be difficult to know what you need, and it may be impossible to simulate in any practical sense. Like, sure, I can stand up a pair of test systems and fabricate every scenario I can possibly imagine, but my employer does want me to do other things this month. And what happens when one of the systems involves a third party? Really, the need is to be able to provision access after the relationship is established. It's weird that you need a completely new secret to change access. Imagine if this were Linux and in order to access a directory you had to provision a new user to do it? How narrow do you really think user security access would be in practical terms then?
- winwang 2y ago
  > the need is to be able to provision access after the relationship is established Could you go into more detail? At a base level interpretation, this is how it works already (you need a principal to provision access for...), but you presumably mean something more interesting?
  - da_chicken 2y ago
    With token-based access, you typically assign the role when the token is created. The access level the token has is typically locked at that point. If you're generating an API access token, you might specify the token is read-only. If you later decide that read/write access is needed, you need to generate a new token with the new access level and replace the token id and value in the client system. It's not difficult, but it's a much bigger pain in the ass than just changing access or changing role on a user.

raverbashing 2y ago

But obviously then the security people will raise ruckus about any attempt of telling you what is wrong (Which ok, for an external facing system is ok) I can bet the huge prevalence of "system says no, and nothing tells you why" helps a lot with creating vulnerable systems. System need an "let X person do Action" instead of having people waddle through 10 options like SystemAdminActionAllow that don't mean anything to an end user