-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
Comments
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. |
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. |
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. |
thanks for the information, so nothing to worry about. |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely accept. |
No change in consensus, so accepted. 🎉 |
Change https://go.dev/cl/509020 mentions this issue: |
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.
The text was updated successfully, but these errors were encountered: