[JENKINS-70108] CastBlock must contextualize invoker to avoid issues in mixed-trust scenarios #640
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…in mixed-trust scenarios
dwnusbaum
commented
Dec 12, 2022
Comment on lines
+707
to
+709
| "Script1.super(Script1).setBinding(Binding)", | ||
| "Script1.trusted", | ||
| "Script1.foo()"); |
There was a problem hiding this comment.
Previously, we would also intercept new File(String), which was wrong because the cast is in trusted code and so it should not be intercepted by the sandbox.
| @@ -527,7 +527,7 @@ public void regexpOperator() throws Throwable { | |||
| @Test | |||
| public void arrayPassedToMethod() throws Throwable { | |||
| assertEvaluate(4, "def m(x) {x.size()}; def a = [1, 2]; a.size() + m(a)"); // control case | |||
| assertEvaluate(4, "def m(x) {x.size()}; def a = [1, 2].toArray(); a.length + m(List.of(a))"); // workaround #1 | |||
| assertEvaluate(4, "def m(x) {x.size()}; def a = [1, 2].toArray(); a.length + m(Arrays.asList(a))"); // workaround #1 | |||
| import java.util.List; | ||
| import org.codehaus.groovy.runtime.InvokerInvocationException; | ||
| import org.codehaus.groovy.runtime.ScriptBytecodeAdapter; | ||
|
|
||
| public class CastBlock implements Block { | ||
| public class CastBlock extends CallSiteBlockSupport { |
There was a problem hiding this comment.
I verified that this does not cause problems deserializing CastBlocks serialized before this change.
dwnusbaum
commented
Dec 13, 2022
Comment on lines
+718
to
+719
| * 1. Add a CallSiteBlock parameter to ContinuationGroup.castToBoolean, and use it to contextualize the invoker | ||
| * used in that method. All Blocks that use the method would need to be updated to implement CallSiteBlock. |
There was a problem hiding this comment.
This seems like the simplest option. Let me know if you think it's worth fixing. There are eight Blocks that would need to implement CallSiteBlock if we make this change. The second option might be better in terms of reducing overall complexity, but it would be more complex to implement.
jglick
approved these changes
Dec 13, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See JENKINS-70108.
819cc9b introduced a new
Blockfor casts,CastBlock, which did not implementCallSiteBlockand did not contextualize itsInvoker. In cases where untrusted code calls trusted code that performs a cast, this could result in trusted code callingSandboxInvoker.castinstead ofDefaultInvoker.cast. In practical terms, this means that casts inside of global Pipeline libraries were sometimes incorrectly blocked by the sandbox.This PR makes
CastBlockimplementCallSiteBlockso that it can contextualizeInvokercorrectly before performing the cast.TODO:
ContinuationGroup.castToBooleanalso need changes?asBooleanmethod that is not allowed by the sandbox, so IDK if it matters in practice.