Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exceptions during authorization can be hidden #49999

Open
jaymode opened this issue Dec 9, 2019 · 1 comment
Open

Exceptions during authorization can be hidden #49999

jaymode opened this issue Dec 9, 2019 · 1 comment
Assignees
Labels
>bug :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC Team:Security Meta label for security team

Comments

@jaymode
Copy link
Member

jaymode commented Dec 9, 2019

In the introduction of support for authorization engines (#38358), the authorization code was changed to support asynchronous authorization calls. In one of the changed blocks of code an exception could get hidden and the user will only get a 403 Access Denied error without any clue into what caused this.

To reproduce this specific scenario:

  • Use run as
    • The authenticated user may have a simple role
    • The run as user needs to have a complex role combination that will trigger a TooComplexToDeterminize exception (or some other way to cause an exception)

See the following block of code:

ActionListener<AuthorizationResult> runAsListener = wrapPreservingContext(ActionListener.wrap(result -> {
if (result.isGranted()) {
if (result.isAuditable()) {
auditTrail.runAsGranted(requestId, authentication, action, request,
authzInfo.getAuthenticatedUserAuthorizationInfo());
}
authorizeAction(requestInfo, requestId, authzInfo, listener);
} else {
if (result.isAuditable()) {
auditTrail.runAsDenied(requestId, authentication, action, request,
authzInfo.getAuthenticatedUserAuthorizationInfo());
}
listener.onFailure(denialException(authentication, action, null));
}
}, e -> {
auditTrail.runAsDenied(requestId, authentication, action, request,
authzInfo.getAuthenticatedUserAuthorizationInfo());
listener.onFailure(denialException(authentication, action, null));
}), threadContext);
authorizeRunAs(requestInfo, authzInfo, runAsListener);

An exception that is thrown during the rest of the authorization process, will wind up getting caught by that listener's exception consumer. This leads to a confusing run_as_denied audit event after a run_as_granted event for the same request. I think the first item to address is the fact that e gets dropped in that code. The second item is to avoid the confusion of having the error reported as a run_as_denied event and appropriately handle the exception.

@jaymode jaymode added >bug :Security/Security Security issues without another label labels Dec 9, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (:Security/Security)

@jaymode jaymode added :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC and removed :Security/Security Security issues without another label labels Dec 9, 2019
@albertzaharovits albertzaharovits self-assigned this Dec 16, 2019
@rjernst rjernst added the Team:Security Meta label for security team label May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC Team:Security Meta label for security team
Projects
None yet
Development

No branches or pull requests

4 participants