fcntl is somewhat dangerous, and we're currently allowing it with no restrictions for content processes. Specifically: F_SETFL with the O_ASYNC flag set causes the process to be sent SIGIO whenever I/O is possible on the file descriptor, F_SETSIG can change which signal is sent, and F_SETOWN can retarget that signal to another process (or, using the Linux extension F_SETOWN_EX, a specific thread in another process). In other words, currently it's equivalent to unrestricted tgkill. (fcntl isn't allowed at all in the GMP policy, and this is why.) pid namespace isolation (bug 1151624) would mitigate that, but we don't even have code for that, and being able to use it will depend on unprivileged user namespaces *and* seccomp tsync. Also, just from skimming the fcntl man page, locks and leases allow interactions we'd like to avoid, and in general it exposes a bunch of attack surface we probably mostly don't need. So, we should restrict fcntl as much as feasible, ideally with a default deny policy, but the usual problems with system libraries apply. At the very least we should be able to block all the components of the signal send gadget.

Comment on attachment 8919575 [details] Bug 1328896 - Restrict fcntl() in sandboxed content processes. https://reviewboard.mozilla.org/r/190414/#review196392

Pushed by jedavis@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ff9088972319 Restrict fcntl() in sandboxed content processes. r=gcp