From 55e4c51ac76f1da3537f33536c1d2bfea15e5b93 Mon Sep 17 00:00:00 2001 From: Philipp Wollermann Date: Tue, 28 Feb 2017 13:14:02 +0000 Subject: Design Docs: Add a section to the Sandboxing 2.0 Doc on what files a sandboxed process should have access to. -- PiperOrigin-RevId: 148758110 MOS_MIGRATED_REVID=148758110 --- site/designs/_posts/2016-06-02-sandboxing.md | 49 ++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 3 deletions(-) (limited to 'site/designs/_posts') diff --git a/site/designs/_posts/2016-06-02-sandboxing.md b/site/designs/_posts/2016-06-02-sandboxing.md index 579bd11b11..a063cc9ab1 100644 --- a/site/designs/_posts/2016-06-02-sandboxing.md +++ b/site/designs/_posts/2016-06-02-sandboxing.md @@ -146,8 +146,51 @@ trigger a rebuild when it changes. *Open question: Should the whitelist of environment variables be configurable, e.g. in the WORKSPACE file?* -### Known issues in this area of work +### What files does a sandboxed process have access to? -[Bazel #577: genrules leaking PATH into environment] -(https://github.com/bazelbuild/bazel/issues/577) +Ideally, we would want to execute SpawnActions in an environment that looks like this: + * Allows read access to everything in /. + * Except the workspace (e.g. /home/philwo/src/bazel). + * Except the "real" execroot (e.g. /tmp/_bazel_philwo/6d3feea2bf88e88127079b36d7ddade1/execroot). + * Except a user-configurable set of blacklisted files or directories (e.g. /var/secret). + + * Has a separate execroot just for this action: /tmp/_bazel_philwo/6d3feea2bf88e88127079b36d7ddade1/execroot-1 + * which only contains the input files listed for the action. + * to which the output files will be written. + * from which the output files will be moved to the real execroot after successful execution. + + * Processes can write wherever they naturally have permission to do so. + * However, writes have no influence on the host system, instead they are redirected into a separate folder (see: overlayfs's upperdir). + +#### Open issues + + * We don't know a way to hide the workspace, while still making selected input files out of it available inside the new execroot. Ideas we tried: + * copying: Works, but too slow. + * hard-linking: Does not work when workspace and output_base are on different filesystems. + * bind mounting them: Works only on Linux, does not scale (the mount syscall becomes really slow once you're at >20000 active mounts). + * building a custom FUSE filesystem: Might work, but lots of effort. + + * How to hide files from the sandboxed process? + * There seems to be no good way to "hide" files on Linux or macOS. + * The best we can do on both systems is to make them unreadable. + + * overlayfs is not usable for our purposes, because it requires root on all systems except Ubuntu. + +#### What can we do today? + +This is what Bazel is doing for sandboxing at the moment: + + * Allows read access to everything in /. + * Except a [user-configurable](https://github.com/bazelbuild/bazel/blob/0f119a4db515105217244e4db5d4fed9371ef1a4/src/main/java/com/google/devtools/build/lib/sandbox/SandboxOptions.java#L96) set of blacklisted files or directories (e.g. /var/secret). + + * Has a separate execroot just for this action: /tmp/_bazel_philwo/6d3feea2bf88e88127079b36d7ddade1/execroot-1 + * which contains symlinks to the input files listed for the action (the targets are in the workspace or the "real" execroot). + * to which the output files will be written. + * from which the output files will be moved to the real execroot after successful execution. + + * Processes can only write to their private execroot and a private $TMPDIR. + +### Related links + + * [Known issues in this area of work](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3A%22category%3A+sandboxing%22) -- cgit v1.2.3