endojs / endo

Endo is a distributed secure JavaScript sandbox, based on SES
Apache License 2.0
829 stars 72 forks source link

feat(eventual-send): breakpoint on delivery by env-options #1860

Closed erights closed 10 months ago

erights commented 1 year ago

closes: #XXXX refs: #XXXX

Description

Given an environment variable setting of

$ export ENDO_DELIVERY_BREAKPOINTS="quatloos issuer.getAmountOf=*"

then when E invokes a getAmountOf method on an object with @@toStringTag of 'Alleged: quatloos issuer', it should first execute a JavaScript debugger; statement. When run normally, i.e., not under a debugger, the debugger; statement has no effect. But when run under a debugger, this statement acts as a breakpoint, causing execution to pause there.

If the "*" at the end is replaced by a number, then each time execution matches, the number is decremented by 1. When it reaches zero, it executes debugger;.

If the "getAmountOf" is replaced with "*", then it breakpoints on any method of a quatloos issuer.

If the "quatloos issuer" is replaced with "*", then it breakpoints on calling a method named "getAmountOf" on anything.

Similarly

$ export ENDO_SEND_BREAKPOINTS="quatloos issuer.getAmountOf=*"

will breakpoint when the message is eventually sent, so that you can look up the stack in the debugger to understand why it was sent. The name only matches if the object itself, or a remote presence for the object, is the target and so has the correct @@toStringTag. This does not work when eventually sending to a promise. To catch those cases, use "Promise" or "*" for the target name.

Security Considerations

As with all use of env-options, we should worry about whether an adversary can read or write these options, and so interfere with code that is supposed to use these options.

Scaling Considerations

If the ENDO_DELIVERY_BREAKPOINTS env-option is not even set, this implementation takes a fast path which should have essentially no penalty compared to the absence of these mechanisms.

When ENDO_DELIVERY_BREAKPOINTS is present but has no "*" on the method name, we still try to minimize the overhead on non-matching method names. But once we have a method name match, then we do a linear search among these directives on each such call.

Likewise for ENDO_SEND_BREAKPOINTS

Documentation Considerations

Let's get some road experience ourselves first. But if it proves useful, it'll be a great debugging aid to explain.

It will be interesting to figure out how to show how to use it interactively from inside a debugger well, including dynamically changing breakpoints. Probably a short video?

Testing Considerations

Since this alters only the behavior seen from a debugger, it is unclear how to write an automated test.

Upgrade Considerations

None.

dckc commented 12 months ago

This looks like a new product feature. I'd like us to bring @sufyaankhan up to speed and get his take on it.

Documentation Considerations Let's get some road experience ourselves first.

Before merging it? Or before documenting it?

erights commented 12 months ago

This looks like a new product feature. I'd like us to bring @sufyaankhan up to speed and get his take on it.

Absolutely! @sufyaankhan would love your thoughts.

Documentation Considerations Let's get some road experience ourselves first.

Before merging it? Or before documenting it?

Before documenting. We won't get enough road experience ourselves if we don't merge it first.

erights commented 10 months ago

I have not yet made the suggested representation changes, so I reverted this PR to Draft.

erights commented 10 months ago

Note to reviewers: Enough changed that it wasn't worth preserving old commits, so I squashed since you last reviewed.

erights commented 10 months ago

Reviewers, Now that this is ready for review, I'll avoid further squashes without first asking you.