I/O safety forbids the "pass FD via env var" pattern (e.g., jobserver)

[RalfJung]

In #114780 we have clarified what is meany by I/O safety. In particular:

//! To uphold I/O safety, it is crucial that no code acts on file descriptors it does not own or
//! borrow, and no code closes file descriptors it does not own. In other words, a safe function
//! that takes a regular integer, treats it as a file descriptor, and acts on it, is *unsound*.

This is unfortunately in conflict with a reasonably common pattern on Unix systems: execing a process with a file descriptor initialized somewhere, and setting an env var to tell it where to find the FD. This pattern is used, for instance, by the jobserver protocol. The jobserver crate hence just takes an integer from an env var, turns it into a file descriptor, and reads/writes to that -- a violation of I/O safety. Crates like cc hence are technically unsound when they expose a safe function that internally uses the jobserver crate. The potential concern here is that the env var might be wrong, the jobserver crate now acts on a random FD by someone else, and that someone might have relied on I/O safety to protect their FD from foreign influence.

Assuming that we don't want to tell the cc maintainer that cc::Build::new() must be unsafe, what shall we do about this?
There's been a lot of prior discussion:

• Does I/O safety forbid duping arbitrary file descriptors? #114167
• Determine and document the distinction between I/O safety and regular safety on unsafe stdlib APIs unsafe-code-guidelines#434
• Zulip, t-opsem thread
• Zulip, t-lang thread

I'm aware of the following proposals to resolve this situation:

1. "export" the safety burden to the environment: starting a process that uses cc and setting the env var the wrong way is violating a precondition of this process, and Rust's soundness guarantees do not apply. This is undermined by set_var though; even if we make that unsafe we'd have to phrase its safety contract very carefully if it want to go this route.
2. Weaken the entire concept of I/O safety to no longer provide any protection against random FDs being read/written, and only protect against random FDs being closed.
3. Develop some elaborate system of "initially existing global FDs" that cc/jobserver could use to be sure that the FD they work on already existed when the program started, and is not some other crate's private property. See here for a bit of elaboration on that idea.

We should pick one, or develop some alternative that provides a satisfying answer to how cc::Build::new() can be a sound function.

[the8472]

Assuming that we don't want to tell the cc maintainer that cc::Build::new() must be unsafe, what shall we do about this?

Well, we could promote more sane protocols instead such as named fifos, file-descriptor passing via unix sockets or also putting the dev/ino in the environment variable to enable sanity checks in the child.

Then the sane ways are safe and the legacy approaches are unsafe.

[RalfJung]

I'm kind of assuming that this would take way too long to really prevent us from having to come up with a justification for what happens currently. Like, realistically, when could cc start refusing to use the old protocol (required to justify its soundness) -- no less than five years from now, I would assume.

(And that's assuming that someone will actually spend all the effort of doing that, and they will be able to convince the rest of the ecosystem to adopt the new approach. In particular the second point I am doubtful about.)

[the8472]

The new jobserver protocol already exists, we didn't even have to invent it. We just need to works towards making it the default (yes, that'll take time)
But it could still serve as precedent for future projects.

I'm kind of assuming that this would take way too long to really prevent us from having to come up with a justification for what happens currently.

Well, we can be pragmatic there and treat it like before_exec which should be unsafe but for backwards-compatibility reasons it isn't. Ideally we'd have #[deprecated_safe] for that but it looks like that's in limbo.

[ChrisDenton]

If anyone has a concrete proposal for cc supporting the new jobserver protocol, it would be useful to open an issue on the cc issue tracker.

[ple1n]

Well, we could promote more sane protocols instead such as named fifos, file-descriptor passing via unix sockets or also putting the dev/ino in the environment variable to enable sanity checks in the child.

There is nothing "insane" about passing FDs. They are perfectly fine and efficient. If your security means a loss of features, it's not good security. You can have zero-cost (relatively) security with type system and formal methods.

[carbotaniuman]

A good starting point would be taking a look at this PR: rust-lang/jobserver-rs#57

[RalfJung]

You can have zero-cost (relatively) security with type system and formal methods.

There's nothing we can do inside Rust to make these protocols well-behaved. This is a cross-process communication problem; types within a programming language are not able to help (much) here. We'd need the OS itself to enforce interface types in processes.

Some interfaces are just inherently cursed and cannot be contained with language-level techniques, they need a more security-aware OS/platform design: /proc/self/mem, bare FD passing, mmap -- I'm sure the list goes on. Sometimes all formal methods can do is point out that an API is just not designed well enough for modular/compositional reasoning principles to apply.

If you want to discuss this further, please do so on Zulip; this issue is about what concretely we can do about the mess that is passing bare FDs around, not the philosophy of whether that interface is "sane" or not. This pattern is causing problems, as documented in the issue description. If you want to help, make concrete suggestions for what could be done. Asking us to use "type system and formal methods" is not helpful.

[the8472]

Note that I was talking about the specific incarnation of an FD-passing protocol used by the make jobserver. Not about FD-passing as a general category. In the very same post I proposed more reliable alternatives.