runtime: enforce standard descriptors are open on initialization

[rolandshoemaker]

As of CL 501223, under various circumstances we enforce that when the runtime initializes, the standard file descriptors (0, 1, 2) are open and if they are not attempt to open them, pointing to /dev/null. This negates a class of privilege escalation vulnerabilities.

I propose that we always enforce this behavior, regardless of the SUID/SGID status of a program. Ignoring the dangerous behavior this can enable, it also seems confusing on the face that a program could be executed and os.Std{in,out,err} could be closed, or point to unexpected file descriptors if the program opens files itself, without a simple way for the program to determine this itself.

Enforcing these descriptors are open makes programs safe by default, and makes the behavior of a program much more easy to reason about without deep knowledge about the mechanisms of the os.Std{in,out,err} abstractions and unix file descriptor inheritance and precedence semantics.

Rust already enforces this behavior across the board: https://github.com/rust-lang/rust/blob/3572d7451d1062e8bccf310af6bbf6255091d296/library/std/src/sys/unix/mod.rs#L81-L164, rust-lang/rust#75295.

[prattmic]

I can imagine scenarios where having the runtime try to open a file would be problematic, such as when the program runs in any empty mount namespace (/dev/null doesn't exist) or in a seccomp sandbox that disallows open.

But even in those cases, it should be straightforward to make the parent process ensure that it passes a pipe to nowhere or something to bypass this behavior. Thus, I have no complaints.

[thediveo]

if you happen to come across some "Dirty Harry" seccomp profiles you don't get any chance after attempting to open /dev/null because they terminate instead of deny. Shoot first, ask later.

[prattmic]

It turns out that we've been unconditionally opening a file at startup since https://go.dev/cl/170858, so the seccomp issue wouldn't be new.

[thediveo]

thanks for the information, so nothing to worry about.

[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]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group