proposal: runtime: add a way to check if fd is used by go runtime

[kolyshkin]

Proposal Details

While working on fixing CVE-2024-21626, we had to implement a function that closes all file descriptors above a specific one (similar to what close_range(2) does). Once we did that, we found out that closing go's internal poll fds results in subsequent panic from go runtime, so we had to exclude those.

The only way possible way to do so was to use internal/poll.IsPollDescriptor (via go:linkname kludge). You can see the code doing this here (initially added by this commit).

We'd like this functionality as a part of public Go API. Perhaps something like this:

package runtime

// IsInternalDescriptor reports whether fd is a
// descriptor being used by Go runtime internally.
func IsInternalDescriptor(fd uintptr) bool

Cc @cyphar

[kolyshkin]

Adding a bit of context here as the CVE text referenced above is quite long.

There exists a container-specific (chroot-specific) attack vector, for which having CLOEXEC flag for an open (directory) FD is not a remediation. Those FDs had to be explicitly closed before spawning a child.

[kolyshkin]

In addition to the above, Go 1.23 adds pidfd support for Linux, so there will be another class of file descriptors used internally by Go runtime -- pidfds. Those are probably also need to be reported.

[cyphar]

@kolyshkin Are the pidfds used internally or are they all just associated with things Go program users need? If they're not used by the Go runtime internally, we can just close_range them like everything else AFAICS?

[rsc]

Can this be explained better without reference to the very large CVE text?
What fd's exactly need to be covered?
If you close the epoll fd then yes it breaks epoll.
But if you close the cached /dev/random fd that will break crypto/rand.
Don't you need to know about that fd too?
And what about other fds that are cached by other packages?
I don't understand why "used by runtime" is a meaningful line.
What about other packages with cached fds?
Don't we want to not break those too?

[kolyshkin]

@kolyshkin Are the pidfds used internally or are they all just associated with things Go program users need?

It is used internally by os, even if specified by a user (the latter case is being fixed by https://go.dev/cl/607695

Can this be explained better without reference to the very large CVE text?

Sorry for being brief before, please see below for answers. The summary is: we need a way to close all file descriptors
above a specific number (very similar to what close_range(2) does on Linux), excluding those that are owned by Go runtime. Note that having CLOEXEC bit set on those FDs is not enough -- we have a peculiar requirement to explicitly close them before the exec happens.

What fd's exactly need to be covered?

Those that are owned (were opened and used internally) by the go runtime, [and are essential for go runtime to function properly]. (1)

(I'm not entirely sure if the square bracketed part should be part of the definition or not).

If you close the epoll fd then yes it breaks epoll.

I'd like to add it breaks it badly (runtime panics).

But if you close the cached /dev/random fd that will break crypto/rand.
Don't you need to know about that fd too?
And what about other fds that are cached by other packages?
I don't understand why "used by runtime" is a meaningful line.

Yes, I just realized that I made a mistake above suggesting that we include pidfd into the same category, crossing the line between "fds owned by go runtime" (as in pollfd) and "fds owned by go standard library" (as in a pidfds used by os, or /dev/random fd used by crypto/rand).

I think we only need ones from the first category only (as defined in (1) above). If we'll also need those owned by packages from the standard library, I guess those packages can add a way to identify if a certain fd is owned by them. (2)

What about other packages with cached fds?
Don't we want to not break those too?

I guess, similar to (2) above, those package could have similar interfaces / ways to figure out if an fd is owned by them.