Only allow ipywidget comm channel messages to reach the kernel after initial top-to-bottom execute

[parente]

Filter out any messages sent from the frontend client to the kernel at the backend server except for ipywidgets comm messages on the shell channel. Allowing any other message gives the user the ability to execute arbitrary code. (In fact, it's not yet know if locking down to comm messages only is good enough to prevent code execution or not yet, but it's a step in the right direction.)

See https://github.com/jupyter-incubator/dashboards/wiki/Deployed-Dashboard-Threat-Analysis

[jhpedemonte]

Filtering enabled with commit 0fb64a6.

Still need to think about how to filter out after initial top-to-bottom execute.

[dalogsdon]

Our current filter will filter out execute requests where the code is not a nonnegative integer. This disallows executing arbitrary code but still allows multiple executions of existing dashboard cell code. We will need to keep track of executions per kernel if we are to only allow one execution per cell.

[parente]

Are you lobbying for tracking multiple executions as part of this item? Or is that a follow-on? If the code got executed once, I don't think there's a huge risk (rm -rf level) in executing it again. But there is certainly risk if it changes any backend system state and it's not idempotent.

[dalogsdon]

My thought was there could be a few cases where re-running would be detrimental. Certainly updating system state and also things like interrupting streaming tasks or running heavyweight code could be undesirable to run again.

This would be a follow-on item as it could be a larger undertaking.

[parente]

OK. If the baseline filtering is in, go ahead and close this out if you think it's done.

[parente]

Opened #13 about preventing repeat runs.