Security considerations #99
Comments
|
As observed by @mewmew, right now, Goa is used by a small circle of mutually trusting people. But even today, I already ran into the situation where the goarc file that comes with @jschlatow's https://github.com/jschlatow/goa-projects contains settings (like This is of course not a Goa-specific issue. The same attack vector exists for any Makefile originating from a potentially malicious 3rd part. But Goa is in a good position to take measures against such risks.
Until these measures are in place, it is probably best to use a "disposable" development VM when dealing Goa projects of untrusted origin. |
|
Thanks @mewmew and @nfeske for raising the discussion.
Tcl is actually able to create safe child interpreters. There is also some example code that we could use for reference. Using a safe interpreter would prevent any exec and file operations in goarc files. However, it might still be possible to trick Goa into performing harmful file system operations. For instance, any goarc file may set |
This reduces the use of global variables and renders bin/goa easier to grasp. Moreover, this change paves the way for eliminating config variables from the global namespace without the need to adapt every line that uses such a variable. Within procedures, we can easily import namespace variables. #99
|
In preparation of using a child interpreter to load goarc files, I had a longer cleanup session. Commit bdee6c6 moves the main program logic into a goa namespace and separate procedures, and paves the way for moving config variables into a config namespace. |
TCL's safe interpreter hides file operations, source, and exec commands. Loading goarc files with a safe slave interpreter is a basic security measure. This change also moves all config variables into a separate namespace. Our interpreter additionally hides the set command in order to make sure that goarc files are only able to set predefined variables in the config namespace. genodelabs#99
TCL's safe interpreter hides file operations, source, and exec commands. Loading goarc files with a safe slave interpreter is a basic security measure. This change also moves all config variables into a separate namespace. Our interpreter additionally hides the set command in order to make sure that goarc files are only able to set predefined variables in the config namespace. genodelabs#99
Restrict path variables to working directory and project directory. The set of allowed paths can be extended by adding `lappend allowed_paths ...` commands to _~/goarc_ or _/goarc_. genodelabs#99
|
Commit c271490 implements the idea of using a safe TCL interpreter for goarc loading. Moreover, commit 00a2559 adds the policy that path variables must refer to paths inside the working directory or project directory. The policy can be extended by appending to the list |
|
That's amazing! |
|
I further reviewed Goa w.r.t. sensitive commands (exec, spawn, file, glob). There are a few obvious and less obvious issues that we need to address:
|
Restrict tool paths to PATH, Goa-internal tools and the default Genode tool-chain path. The set of allowed tool paths can be extended by adding `lappend allowed_tools ...` commands to _~/goarc_ or _/goarc_. This commit prevents malicious configuration of cross_dev_prefix. genodelabs#99
In order to prevent that the presence of malicious symlinks can be used to escape the allowed_paths, we replace the file command with an alias. This allows validation of paths during `file normalize` and `file link` operations, which both resolve symlinks. genodelabs#99
TCL's safe interpreter hides file operations, source, and exec commands. Loading goarc files with a safe slave interpreter is a basic security measure. This change also moves all config variables into a separate namespace. Our interpreter additionally hides the set command in order to make sure that goarc files are only able to set predefined variables in the config namespace. genodelabs#99
Restrict path variables to working directory and project directory. The set of allowed paths can be extended by adding `lappend allowed_paths ...` commands to _~/goarc_ or _/goarc_. genodelabs#99
Restrict tool paths to PATH, Goa-internal tools and the default Genode tool-chain path. The set of allowed tool paths can be extended by adding `lappend allowed_tools ...` commands to _~/goarc_ or _/goarc_. This commit prevents malicious configuration of cross_dev_prefix. genodelabs#99
In order to prevent that the presence of malicious symlinks can be used to escape the allowed_paths, we replace the file command with an alias. This allows validation of paths during `file normalize` and `file link` operations, which both resolve symlinks. genodelabs#99
In order to prevent untrusted goarc files to execute malicious commands via target_opt(sculpt-cmd), users must confirm the command execution interactively. genodelabs#99
This is addressed by 838c084 |
Fixed by 94a73be |
|
Commit b6f2b11 further adds an |
|
With commit 9675bdc, Goa now intercepts Tcl's file operations in order to check arguments against the |
The command downloads and installs the current Genode toolchain (if unavailable) and converts it into a squashfs. The squashfs is mounted via squashfuse and bind mounted into the bubblewrapped build environment. genodelabs#99
|
I pushed another commit series to my issue099_security branch. The series implement the sandboxing of build-tool executions using bubblewrap. For better re-usability, I added a wrapper script called gaol (pronounced "jail") around bwrap. Moreover, I added a download mechanism for the Genode toolchain in case a system-wide installation was not found. In this case, the toolchain archive is downloaded and converted into a squashfs archive. Goa then mounts the archive using squashfuse and bind mounts it into the sandbox environment. There is a new "install-toolchain" command that takes care of this. I would have liked to implement the mounting mechanism in the gaol tool as well. However, since I want to preserve stderr output of the bwrap command (and its children), I cannot use expect. tclsh, on the other hand, has no awareness of signals so that I'm unable to perform cleanup tasks such as unmounting the squashfs when the user hits ctrl-c during the build procedure. |
|
@atopia I'd be interested in your thoughts on providing the rust toolchain as squashfs as well. This would relieve the user from any manual installation tasks when building rust components. |
This is in preparation of moving the tool chain into a squashfs image. genodelabs#99
The command downloads and installs the current Genode toolchain (if unavailable) and converts it into a squashfs. The squashfs is mounted via squashfuse and bind mounted into the bubblewrapped build environment. genodelabs#99
|
I force pushed my issue branch with a few fixups for cmake and qmake. I also changed the gaol tool to execute the bwrap command within bash, which enables the use of arbitrary file descriptors (e.g. required for the The latter turned out to be useful for adding support for signing archives via sq, which does not cache passwords of secret keys. The |
Instead of trying to export all secret keys referenced by the depot directory, the to-be-exported secret keys must be mentioned explicitly. genodelabs#99 genodelabs#104
This reduces the use of global variables and renders bin/goa easier to grasp. Moreover, this change paves the way for eliminating config variables from the global namespace without the need to adapt every line that uses such a variable. Within procedures, we can easily import namespace variables. #99
My understanding is that we provide a custom Genode C/C++ toolchain because we need to control code generation w.r.t. features like Thread Local Storage and because we want to control the update cycle of the gcc suite for The alternatives would be to a) actually distribute a version of the toolchain ourselves (as we have done in the past, but also by utilizing rustup) and/or b) to implement I've written down the result of my quick exploration of the topic in #107. Seeing that we currently don't have a pressing need to require a specific Rust version on the system, I would put the feature on the back burner, unless people feel there is an urgent need to automate toolchain installation? |
In issue #98, @mewmew raised a fairly important topic that deserves a dedicated issue. It is not urgent but we should keep the topic in eyesight and eventually address it. Here is @mewmew's original text:
The text was updated successfully, but these errors were encountered: