Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: enforce standard descriptors are open on initialization #60641

Closed
rolandshoemaker opened this issue Jun 6, 2023 · 8 comments
Closed
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Proposal Proposal-Accepted
Milestone

Comments

@rolandshoemaker
Copy link
Member

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.

@gopherbot gopherbot added this to the Proposal milestone Jun 6, 2023
@prattmic
Copy link
Member

prattmic commented Jun 6, 2023

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.

@prattmic prattmic added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jun 6, 2023
@thediveo
Copy link

thediveo commented Jun 6, 2023

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
Copy link
Member

prattmic commented Jun 6, 2023

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
Copy link

thediveo commented Jun 7, 2023

thanks for the information, so nothing to worry about.

@rsc
Copy link
Contributor

rsc commented Jun 28, 2023

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
Copy link
Contributor

rsc commented Jul 5, 2023

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

@rsc
Copy link
Contributor

rsc commented Jul 12, 2023

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@rsc rsc changed the title proposal: runtime: enforce standard descriptors are open on initialization runtime: enforce standard descriptors are open on initialization Jul 12, 2023
@rsc rsc modified the milestones: Proposal, Backlog Jul 12, 2023
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/509020 mentions this issue: runtime: enforce standard file descriptors open on init on unix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Proposal Proposal-Accepted
Projects
Status: Accepted
Development

No branches or pull requests

6 participants