New system calls: pidfd_open() and close_range()

Posted May 28, 2019 2:50 UTC (Tue) by mirabilos (subscriber, #84359)
In reply to: New system calls: pidfd_open() and close_range() by sbaugh
Parent article: New system calls: pidfd_open() and close_range()

Except it’s in the Korn Shell’s definition that only explicitly passed fds are passed to processes.

Except that sometimes you *do* want to close all other fds (sometimes even all fds, before reopening /dev/null as fd 0 and duping it to 1 and 2) for security reasons.

Programmers will shoot themselves into the foot, but if the rope is efficient… *shrug*

And if you don’t like it, it’s open source and you’ll be able to remove the call in your local copy of the software.

to post comments

New system calls: pidfd_open() and close_range()

Posted May 28, 2019 3:56 UTC (Tue) by sbaugh (guest, #103291) [Link] (3 responses)

>Except it’s in the Korn Shell’s definition that only explicitly passed fds are passed to processes.

Yes, the Korn shell (and mksh) are wrong here, I'm afraid. Thankfully most shells don't have that particular bad behavior.

>Except that sometimes you *do* want to close all other fds (sometimes even all fds, before reopening /dev/null as fd 0 and duping it to 1 and 2) for security reasons.

The "security reasons" argument here applies identically to environment variables. Indeed, I think it's sound to clear the environment and close all fds when you really want to harden something - in setuid environments, for example. But most programs shouldn't be clearing their environment, and most programs shouldn't be closing all fds.

>Programmers will shoot themselves into the foot, but if the rope is efficient… *shrug*
>And if you don’t like it, it’s open source and you’ll be able to remove the call in your local copy of the software.

This doesn't make any sense. Again, we shouldn't add syscalls to speed up operations which should not be done in the first place. That has nothing to do with open source choice. If you think this operation is good, then say that.

New system calls: pidfd_open() and close_range()

Posted May 28, 2019 6:58 UTC (Tue) by roc (subscriber, #30627) [Link] (2 responses)

> Again, we shouldn't add syscalls to speed up operations which should not be done in the first place.

But many programs do want hardening --- e.g. Firefox and Chrome need to close all fds in sandboxed child processes --- and probably that trend is to be encouraged. Why shouldn't they have an efficient way to do it?

Plus, it seems to me that leaking internal file descriptors into spawned subprocesses is unhygenic, asking for trouble, and should not be the default.

New system calls: pidfd_open() and close_range()

Posted May 28, 2019 12:57 UTC (Tue) by sbaugh (guest, #103291) [Link] (1 responses)

>But many programs do want hardening --- e.g. Firefox and Chrome need to close all fds in sandboxed child processes --- and probably that trend is to be encouraged. Why shouldn't they have an efficient way to do it?

Primarily: because they don't need an efficient way to do it. They can close file descriptors once at startup and thereafter make sure to use CLOEXEC to prevent file descriptor leakage. That works fine and doesn't encourage bad practices in the rest of userspace. But more generally...

It's obviously hard to argue against "we should do more sandboxing". But I fall back to the analogy to environment variables: If we shouldn't clear the environment before running the program, then we shouldn't close all file descriptors before running it. Browser Javascript sandboxes are totally closed off from the rest of the system - they certainly don't need environment variables, and they wouldn't benefit from file descriptors either. So it's fine to clear the environment and close all fds before running them.

Certainly I think we should move towards a world where processes can't access things they haven't somehow been given access to. But I don't think we should make every process like a browser Javascript sandbox, and be totally closed off from the system. There are many things that are implicitly inherited in Linux - the root directory, the current working directory, all the namespaces, tons of things. Most of those should be removed or reworked, because they're easy to mess up and can't easily be controlled, and most of them can't even be changed without privileges. But many parts of Unix are still useful, and shouldn't be removed. Environment variables shouldn't be removed, and the possibility of implicit inheritance of file descriptors shouldn't be removed. Otherwise we'll inevitably end up reinventing those, slowly and painfully.

>Plus, it seems to me that leaking internal file descriptors into spawned subprocesses is unhygenic, asking for trouble, and should not be the default.

I agree! Thankfully, there is already a way to prevent this: CLOEXEC. You don't need close_range to avoid leaking file descriptors into spawned subprocesses.

As I said in my original comment: CLOEXEC is the right way to stop to stop implicit inheritance of file descriptors, and I think it should be the default. Almost all file descriptors shouldn't be implicitly inherited into children - that would be massive resource leakage. But sometimes you *do* want to implicitly inherit a file descriptor and CLOEXEC gives you that option, because you can turn it off and inherit a file descriptor without having to explicitly tell your child that you're doing it. closefrom is wrong because there's no way to turn it off when some random glue program in the middle of the tree calls it, so it completely prevents implicit inheritance of file descriptors.

New system calls: pidfd_open() and close_range()

Posted May 30, 2019 12:26 UTC (Thu) by roc (subscriber, #30627) [Link]

> They can close file descriptors once at startup and thereafter make sure to use CLOEXEC to prevent file descriptor leakage. That works fine and doesn't encourage bad practices in the rest of userspace. But more generally...

That would mean a bug in a third-party library that creates a non-CLOEXEC file descriptor, even for a moment, creates a security hole for the sandbox. That's not really acceptable.

> If we shouldn't clear the environment before running the program, then we shouldn't close all file descriptors before running it.

I don't buy that argument. Reading the environment can't usually affect other processes. Reading or writing leaked file descriptors can, sometimes in very subtle ways.