-
Notifications
You must be signed in to change notification settings - Fork 2k
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
auth: use ACLsDisabledACL
when ACLs are disabled
#18754
Conversation
10c2d59
to
32a3adb
Compare
32a3adb
to
4ae6246
Compare
The RPC handlers expect to see `nil` ACL objects whenever ACLs are disabled. By using `nil` as a sentinel value, we have the risk of nil pointer exceptions and improper handling of `nil` when returned from our various auth methods that can lead to privilege escalation bugs. This is the final patch in a series to eliminate the use of `nil` ACLs as a sentinel value for when ACLs are disabled. This patch adds a new virtual ACL policy field for when ACLs are disabled and updates our authentication logic to use it. Included: * Extends auth package tests to demonstrate that nil ACLs are treated as failed auth and disabled ACLs succeed auth. * Adds a new `AllowDebug` ACL check for the weird special casing we have for pprof debugging when ACLs are disabled. * Removes the remaining unexported methods (and repeated tests) from the `nomad/acl.go` file. * Update the semgrep rules to detect improper nil ACL checking and remove the old invalid ACL checks. * Update the contributing guide for RPC authentication. Ref: hashicorp/nomad-enterprise#1218 Ref: #18703 Ref: #18715 Ref: #16799 Ref: #18730 Ref: #18744
4ae6246
to
b722882
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Just noting something I looked at when reviewing this PR for future: can/should we avoid building the iradix transactions when performing the client/server/disabled ACL init? Curious what the time/space gain would be, and even if it's safe.
Oh, I bet we could. We just need to make sure the |
…o release/1.7.x #19278 Co-authored-by: Tim Gross <[email protected]>
As of #18754 which shipped in Nomad 1.7, we no longer need to nil-check the object returned by `ResolveACL` if there's no error return, because in the case where ACLs are disabled we return a special "ACLs disabled" ACL object. Checking nil is not a bug but should be discouraged because it opens us up to future bugs that would bypass ACLs. While working on an unrelated feature @lindleywhite discovered that we missed removing the nil check from several endpoints with our semgrep linter. This changeset fixes that. Co-Author: Lindley <[email protected]>
As of #18754 which shipped in Nomad 1.7, we no longer need to nil-check the object returned by `ResolveACL` if there's no error return, because in the case where ACLs are disabled we return a special "ACLs disabled" ACL object. Checking nil is not a bug but should be discouraged because it opens us up to future bugs that would bypass ACLs. While working on an unrelated feature @lindleywhite discovered that we missed removing the nil check from several endpoints with our semgrep linter. This changeset fixes that. Co-Author: Lindley <[email protected]>
As of #18754 which shipped in Nomad 1.7, we no longer need to nil-check the object returned by `ResolveACL` if there's no error return, because in the case where ACLs are disabled we return a special "ACLs disabled" ACL object. Checking nil is not a bug but should be discouraged because it opens us up to future bugs that would bypass ACLs. While working on an unrelated feature @lindleywhite discovered that we missed removing the nil check from several endpoints with our semgrep linter. This changeset fixes that. Co-Author: Lindley <[email protected]>
As of #18754 which shipped in Nomad 1.7, we no longer need to nil-check the object returned by ResolveACL if there's no error return, because in the case where ACLs are disabled we return a special "ACLs disabled" ACL object. Checking nil is not a bug but should be discouraged because it opens us up to future bugs that would bypass ACLs. We fixed a bunch of these cases in #20150 but I didn't update the semgrep rule, which meant we missed a few more. Update the semgrep rule and fix the remaining cases.
As of #18754 which shipped in Nomad 1.7, we no longer need to nil-check the object returned by ResolveACL if there's no error return, because in the case where ACLs are disabled we return a special "ACLs disabled" ACL object. Checking nil is not a bug but should be discouraged because it opens us up to future bugs that would bypass ACLs. We fixed a bunch of these cases in #20150 but I didn't update the semgrep rule, which meant we missed a few more. Update the semgrep rule and fix the remaining cases.
The RPC handlers expect to see
nil
ACL objects whenever ACLs are disabled. By usingnil
as a sentinel value, we have the risk of nil pointer exceptions and improper handling ofnil
when returned from our various auth methods that can lead to privilege escalation bugs. This is the final patch in a series to eliminate the use ofnil
ACLs as a sentinel value for when ACLs are disabled.This patch adds a new virtual ACL policy field for when ACLs are disabled and updates our authentication logic to use it. Included:
AllowDebug
ACL check for the weird special casing we have for pprof debugging when ACLs are disabled.nomad/acl.go
file.Ref: https://github.com/hashicorp/nomad-enterprise/pull/1218
Ref: #18703
Ref: #18715
Ref: #16799
Ref: #18730
Ref: #18744
Notes for reviewers:
if aclObj != nil
lines all over the RPC endpoints 😀if aclObj != nil
from those RPC endpoints too.