Filtering kernel messages

[SylvainCorlay]

One of the goals of the standalone jupyters_server is to enable use cases where certain messages are not allowed such as execute_requests.

The main usecase is for widgets-based applications, that should not allow arbitrary code execution.

Should there be an option for disabling execute_request globally (at least as a first iteration), or have a more complex security scenario where this would depend on who is connected.

cc @jasongrout @rgbkrk

[SylvainCorlay]

From discussion with @minrk, the right place to do this is in function on_message, to make it check for a whitelist of message type, that would be specified as a configurable on the app type.

https://github.com/jupyter/jupyter_server/blob/master/jupyter_server/services/kernels/handlers.py#L294

[rgbkrk]

Neat. When disabled, it would be really nice if there's some amount of feedback that it's being blocked.

• A message (on the protocol) for the UI to consume
• Log attempts to use the blocked message types so that we can:
  • find out which app is using the message (maybe erroneously, maybe maliciously)
  • escalate incident response when attempts are being made

[SylvainCorlay]

Yeah, initially, I thought of only disabling execute_request and sending execute_reply message back to the frontend with a failing status, but the more generic "filter all messages" can probably not do this without a lot more code.

[jasongrout]

It would also be great if there was a framework to register a message handler, which could possibly transform messages, or hand back a sentinel value that indicates to not deliver the message (and perhaps a separate reply message to send back when applicable, like you suggest with execute_reply). Making the handler configurable makes it easy to experiment with different workflows. For example, @williamstein at one point wanted to intercept display messages to strip out image mimedata to store it in a database and replace the data with a link.

As you indicate, it's probably a lot more code (so maybe not now?), but it's also a lot more flexible in the long run.

[SylvainCorlay]

Agreed. jupyter_server is a smaller codebase to enable this kind of features than the classic notebook, so we should be able to do this sort of things soon.