Switch from blacklisting to whitelisting messages

[parente]

During the security review of 0.6.0 for #196, I noted that blacklisting rather than whitelisting messages that can be sent from the dashboard server client to a kernel leaves the door open for unknown vulnerabilities. For example, complete_request, inspect_request, and history_request might allow a user to get information about data/secrets stored in kernel memory but not exposed in the dashboard view.

At the moment, we manipulate execute_request sent from the client and filter code from execute_input sent by a kernel. I believe we need to expand the logic to something like:

if msg is from client to kernel on shell:
  if msg type is comm_open, comm_msg, comm_close, kernel_info_request, or comm_info_request:
    pass through
  else if msg type is execute_request:
    do code lookup for integer cell number
  else
   drop the message
if msg is from kernel to client on iopub:
  if msg type is stream, display_data, execute_result, error, status, clear_output:
    pass through
if msg is anything else:
  drop the message

[jhpedemonte]

I thought of this when we were first putting together the proxy, but was worried about unintended consequences. Particularly, would we be breaking a 3rd party extension, for example, that made legitimate use of message types that we had not white listed. Any thoughts on that?

But in the long run, our main focus is on securely deploying these dashboards and there may be some necessary sacrifices in order to achieve that.

[parente]

Particularly, would we be breaking a 3rd party extension, for example, that made legitimate use of message types that we had not white listed. Any thoughts on that?

My thought is that explicit is better than implicit.

If we whitelist, we can explicitly tell developers what is allowed and what is not. As users find libs that are broken, we can look at loosening up the list on a case by case basis while understanding the impact on security.

I'd rather get bug reports about libs not working than bug reports that someone managed to rm -rf / through some weird message trick.