Sandboxing a full node.js stack with Firejail

[glitsj16]

The current node.js related profiles are implemented via several redirects, including the main nodejs-common.profile. As already indicated in #4172, this has a few shortcomings. Sadly that PR isn't moving for quite a while.

Some parts of the node.js stack like gulp, node-gyp, npx and semver don't have profiles. Another issue is nvm. Although that has a profile, it is pretty much useless. Due to its implementation as a sourced shell function - not a executable binary - it isn't directly firejailable. It is however pretty easy to add support to the programs being called internally: curl, sha256sum, tar and wget.

I've been testing a refactored setup that tries to simplify sandboxing a full node.js stack with Firejail for several weeks. Building on the fact that gulp, node-gyp, npm, npx and semver are all scripts with the #!/usr/bin/env node shebang, I opted to drop the redirect profiles. We can discuss this implementation here.

This is the PR: #5051.

[kmk3]

Sandboxing a full node.js stack with Firejail

On a given language environment, there are usually 3 different categories of
programs:

• the runtime itself (e.g.: python, ruby, jvm)
• the package managers (/build systems) (e.g.: npm/yarn, pip, bundler
  ant/maven/gradle)
• the runtime version manager (e.g.: nvm, pyenv, rvm)

I think that the runtime itself would ideally be more restricted than the
package and runtime managers.

That is, npm/yarn should have permission to install and remove packages, but
maybe not something that just happens to run on the node runtime (and IIRC nvm
probably does not need it either).

Though this is off the top of my head; I haven't dealt with the specifics of
node for a while and I don't remember what exactly calls what (as in, maybe
there is a common node-based script that may call npm/yarn), so this is more of
a general comment about language-based runtimes.

[glitsj16]

Thanks for the illuminating write-up. I do understand the distinction between runtime, package manager and version manager and the different levels of restriction one would want to implement in an attempt at sandboxing a stack. This is another valid point for keeping the relevant redirect profiles, as you already pointed out in your PR review.

I'll take a step back and let this sink in a while, so I put the PR into draft mode. This was exactly the kind of feedback I was looking for. Very much appreciated. The Node.js stack sandboxing saga continues :-)

The nvm parts of the PR need to be adressed though, regardless of what happens to the rest of the related profiles. Unless someone comes up with a way to firejail a shell function. Maybe I can take out those pieces and open a separate PR for that specific problem.

[glitsj16]

Follow-up. Several node.js security-related events have made 'headlines' somewhere before. By itself this is nothing new or surprising. The very recent protestware situation is probably one that got even wider attention for obvious reasons. IMO firejail can be another tool to help protect users and/or try to minimise potential damage. Currently (including potential future merge of pending PR #5058) this relies quite heavily on user actions, as none of the related profiles are enabled in firecfg. It's tempting to suggest flipping them on. But I'm at best a very occasional node.js user and testing one's own use cases is hardly sufficient. So if anyone is inclined to put our implementation to the test, that would be awesome.