proposal: os/exec: Add ability to limit or prohibit the use of spawning subprocess'

[ecnepsnai]

Background

The os/exec pacakge allows Go applications to spawn subprocesses, which can enable Go applications to interact with other executables on the system. This is a widely used practice, but presents a security risk for the running system.

Should the running application be impacted by a remote code execution vulnerability, the ability to spawn applications on the running system can pose a significant threat.

For example, a recurring trend on other langues like Go is malicious third-party packages that contain cryptocurrency mining malware, or "cryptominers". Typically, these malicious packages don't actually contain the mining code in package itself, but rather code that downloads a malicious binary and runs it, as reported on by Bleeping Computer

Some operating systems provide mechanisms to limit process spawning, such as Security Enhanced Linux (SELinux), or Windows AppLocker, however not all of the supported OS targets of Go offer such features. Additionally, these features can be difficult to configure and are often disabled.

Proposal

As an optional security hardening measure for Go applications, I am proposing that we add the ability to restrict or prohibit the use of spawning subprocesses through os/exec.

In cases where the functionality is disabled, no subprocesses can be spawned through os/exec. However, we could provide an allowlist mechanism where only specific binaries may be executed by their path.

In an application where the developers know there will not be any need for spaning subprocesses, disabling that functionality provides a layer of defence. In the example of malicious packages above, this mechanism would prevent the malicious mining binary from being executed. This should not be seen as a complete defence, but an additional safeguard used in conjuction with others.

This feature should be opt-in so that existing applications are unaffected.

Design

Disabling spawning subprocesses

At build time, set the GOEXECDISABLED=1 environment variable.

Then, any calls to os/exec.Cmd.Start() return an error indicating that the functionality is disabled.

Restrict spwaning subprocesses

At build time, set the GOEXECALLOW="/usr/bin/foo:/usr/bin/bar" environment variable, which takes a colon separated list of files that can be executed by os/exec. If GOEXECDISABLED is specified, it would take precedence over this.

Then, any calls to os/exec.Cmd.Start() return an error if the execuable path is not in the allowlist, otherwise it is executed normally.

[ecnepsnai]

This is my first proposal to go, so please forgive me if I've made a mistake on the process somewhere!

[seankhliao]

cc @golang/security

[mvdan]

How can we possibly restrict this via just os/exec? Presumably I could make the right fork+exec syscalls myself, or copy the bits from os/exec which do this. Or use cgo to instead fork and execute a program from there.

[ianlancetaylor]

There are many ways that a Go program is vulnerable if an attacker is able to force it to execute code determined by the attacker. The os/exec package is just one of many cases. Most obviously, Go programs can make system calls directly using syscall.Syscall, and can easily start programs using syscall.ForkExec.

So my concern would be that this idea, though not in itself terrible, is just a small bandaid that will in the best case do nothing much and in the worst case lead people to believe that there is more security than there actually is.

[ecnepsnai]

Closing as not technically feasible

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

This proposal has been declined as infeasible.
— rsc for the proposal review group