Open parente opened 8 years ago
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.
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.
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
, andhistory_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 filtercode
fromexecute_input
sent by a kernel. I believe we need to expand the logic to something like: