-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[filters] Add RBAC condition fuzzer (CEL expressions) #8752
Conversation
/review @kyessenov |
} else { | ||
return CelValue::CreateString(info_.downstreamRemoteAddress()->asStringView()); | ||
if (info_.downstreamLocalAddress() != nullptr) { |
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.
downstreamRemoteAddress?
|
||
// Create the CEL expression. | ||
Protobuf::Arena arena; | ||
Expr::BuilderPtr builder = Expr::createBuilder(&arena); |
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.
You can move the builder out of the loop. It reuses the constant arena, so you might want to disable constant folding to reduce interference.
@@ -157,9 +157,13 @@ absl::optional<CelValue> PeerWrapper::operator[](CelValue key) const { | |||
auto value = key.StringOrDie().value(); | |||
if (value == Address) { | |||
if (local_) { | |||
return CelValue::CreateString(info_.downstreamLocalAddress()->asStringView()); | |||
if (info_.downstreamLocalAddress() != nullptr) { | |||
return CelValue::CreateString(info_.downstreamLocalAddress()->asStringView()); |
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.
This is fine, but the stream info header states both can never be null.
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.
Ah OK. Should be fine then now since TestStreamInfo
sets both. Originally it caught a ubsan bug when it wasn't set. Changed, since the fuzzer shouldn't hit that case.
@@ -96,7 +96,7 @@ absl::optional<CelValue> ResponseWrapper::operator[](CelValue key) const { | |||
return CelValue::CreateInt64(code.value()); | |||
} | |||
} else if (value == Size) { | |||
return CelValue::CreateInt64(info_.bytesSent()); | |||
return CelValue::CreateUint64(info_.bytesSent()); |
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.
Can we leave this to be int64? It makes inter-op with other int64 values better. Otherwise, we have to cast in the expressions to int64, which is annoying.
@kyessenov are comprehension expressions supported? It seems like they aren't because |
@asraa Comprehensions are explicitly disabled as of #8746 since they can cause non-linear resource complexity. Same for string/list concatenations. I think you should get an exception building an expression for comprehensions, but not string/list concatenations. That's because string/list concat shares the operator + with normal addition (which is a language issue, that is being discussed). In any case, the evaluator should still successfully produce an error as a result of create expression or eval expression. |
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Gotcha thanks! Thanks for that PR. I updated the branch and added the testcase that was failing from the comprehension expressions. Should be good now. |
Changes look fine to me, but I'm not very familiar with the fuzzing framework. Let me know if the fuzzer detects something. |
Will do. After about a day of being checked in to upstream, OSS-Fuzz will report any crashes that come up. I'll reach out to you with anything that comes up. Also feel free to ping me if you want to extend fuzzers for the filter. |
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
@@ -187,6 +187,7 @@ absl::optional<CelValue> PeerWrapper::operator[](CelValue key) const { | |||
if (value == Address) { | |||
if (local_) { | |||
return CelValue::CreateString(info_.downstreamLocalAddress()->asStringView()); | |||
|
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.
extra new line
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.
Done, thank you!
Signed-off-by: Asra Ali <[email protected]>
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.
Generally this looks great, nice fuzzer design. Just some comments/clarification requests and then LGTM.
|
||
DEFINE_PROTO_FUZZER(const test::extensions::filters::common::expr::EvaluatorTestCase& input) { | ||
// Create builder without constant folding. | ||
static Expr::BuilderPtr builder = Expr::createBuilder(nullptr); |
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.
Is this stateless? I.e. it won't vary between test cases and so is safe to make static? If so, please update the above comment.
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.
Builder can be shared between expressions.
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.
Updated comment. Yep, it was time-consuming to create the builder between iterations as well, so I felt it was a worthy object to make static.
Http::TestHeaderMapImpl response_trailers = Fuzz::fromHeaders(input.trailers()); | ||
|
||
// Evaluate the CEL expression. | ||
Protobuf::Arena arena; |
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.
What is this for?
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.
CEL creates all temporary objects on an arena. I think this is used for this purpose.
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.
Updated, passed in to evaluate
. I was playing around with which would be faster.
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
This pull request has been automatically closed because it has not had activity in the last 14 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Sorry it passed through my attention until it was marked closed!! Should be ready now. |
This adds a fuzzer for CEL expression matching. These conditions are used in the RBAC filter for complementing the existing principal/permission model.
About a quarter of the execution time is coming from
google::api::expr::runtime::RegisterBuiltinFunctions
. The test runs locally at about 250 exec/sec.See: #7716
Risk Level: Low
Testing: Converted unit tests into corpus entries