Security policy is not documented

[mkantor]

This project could use a security audit and some documentation about "this is what it means for Operator to be secure" and "this is how to keep your site from getting hacked".

The current stance is something like "Operator is only as secure as the stuff in your content directory, so be careful", but it would be nice to come up with a set of best practices to go along with that. Some ideas:

• Always create a dedicated user with limited permissions to run the server and/or run it inside a locked-down container/chroot jail.
• Make sure that nobody except you has write permissions for the content directory and everything inside it (and, again, don't run Operator as yourself in production).
• Any executables you put in the content directory must be trustworthy, and you should think carefully about what effects they can have. An executable that can run rm -rf / or fork bomb your system is not good!

---

Executables are scary

Of particular concern are executables, since they could be abused to cause lasting damage, data exfiltration, or resource exhaustion.

Capability-wise, executables are intentionally very limited right now in order to sidestep some of the scarier concerns (e.g. they have no way to observe any request data, which makes request-based code injection impossible). However, these limitations mean that some clearly-desirable functionality is impossible to implement (collecting form data, user agent sniffing, inspecting cookies, using query strings, etc). It would be nice to give executables more capabilities, but this is blocked on a coherent security story.

Operator could do some sandboxing when running executables to make them safer (e.g. unsetting environment variables might be a good start, but we could go all out with something like Linux namespaces and/or seccomp (although cross-platform-ness is an important consideration too)). Operator could also perform a mini audit of the content directory during startup (e.g. logging a warning if any of its contents are writable). It might also be totally acceptable to do none of this and put the burden on users to make sure their executables are trusted; that just needs to be documented loudly.

[mkantor]

Closed by mkantor/operator-website#10.