Compartmentalized privileges

[kobelb]

The following is super hand-wavey and inspired largely by Chrome's approach to Linux Sandboxing: https://chromium.googlesource.com/chromium/src/+/master/docs/linux/sandboxing.md

Currently, Kibana runs as a single process and all code has the same privileges to the filesystem, Elasticsearch, network, etc. As a result, we continue to run into security concerns from granting Kibana privileges when it would dramatically increase the actions that an attacker would be able to perform if they found an RCE.

For example, we currently require user intervention for Ingest Manager packages to be updated because we're concerned about giving the kibana_system user too many privileges. This comes at a detriment to our end-users because they have to wait for an adequately privileged user to come around and update the packages. These inconveniences are expanding over time, and are being tracked by #89827

If we weren't worried about all of Kibana's code having the same privileges, and could for example drop privileges after initial startup, or run different plugins with different privileges, it seems like this would largely mitigate against these concerns.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[kobelb]

/cc @alexh97 @scunningham

[legrego]

I could envision the kibana_system account being leveraged [nearly] exclusively by core, with core creating lesser privileged credentials for each registered plugin. Perhaps an API Key, or something similar to an API Key.

It wouldn't prevent an RCE from reading kibana_system's credentials off of the file system, but something like nodejs/node#33504 / npm/rfcs#297 might give us what we need if/when that lands into node itself.

[pgayvallet]

I could envision the kibana_system account being leveraged [nearly] exclusively by core, with core creating lesser privileged credentials for each registered plugin.

I'm not up to date with node's security sandboxing. Would that forces us to run all plugins in distinct processes (I don't need to explain the technical implications of implementation that), or can the sandboxing be controlled at a more granular intra-process level?

(Can I add that I really miss Java's security manager / isolated class loaders for such issues?)

[kobelb]

I'm not up to date with node's security sandboxing. Would that forces us to run all plugins in distinct processes (I don't need to explain the technical implications of implementation that), or can the sandboxing be controlled at a more granular intra-process level?

As far as I'm aware, Node.js doesn't currently have any method of sandboxing code. However, operating systems themselves provide various facilities that apply to an entire process, for example: https://en.wikipedia.org/wiki/Seccomp

[Bamieh]

As far as I'm aware, Node.js doesn't currently have any method of sandboxing code.

That is true. NodeJS provides a VM API to compile/execute isolated scripts BUT they are not intended for security purposes. IMO Managing system level priviledges inside an application is just as troublesome as not having any sandboxing between modules.

[naugtur]

Have you tried using Compartments with SES shim?
https://www.youtube.com/watch?v=Qjeh7Qo2u28

https://github.com/LavaMoat/LavaMoat/
https://github.com/endojs/endo
https://github.com/endojs/endo/tree/master/packages/ses