Closed Bug 1328896 Opened 3 years ago Closed 2 years ago

Remove or restrict fcntl in desktop content processes


(Core :: Security: Process Sandboxing, defect, P2)




Tracking Status
firefox53 --- affected
firefox58 --- fixed


(Reporter: jld, Assigned: jld)



(Whiteboard: sb+)


(1 file)

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.
Whiteboard: sb+
Assignee: nobody → jld
Priority: -- → P2
See Also: → 1397753
See Also: → 1408438
Comment on attachment 8919575 [details]
Bug 1328896 - Restrict fcntl() in sandboxed content processes.
Attachment #8919575 - Flags: review?(gpascutto) → review+
Pushed by
Restrict fcntl() in sandboxed content processes. r=gcp
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.