Closed Bug 1401053 (pid-namespaces-content) Opened 2 years ago Closed 2 years ago

pid namespace isolation for sandboxed Linux content processes

Categories

(Core :: Security: Process Sandboxing, enhancement, P3)

Unspecified
Linux
enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1151624
Tracking Status
firefox57 --- affected

People

(Reporter: jld, Unassigned)

References

(Depends on 2 open bugs)

Details

(Whiteboard: sb+)

Bug 1151624 covers allowing starting child processes in separate pid namespaces, so they can't affect any other processes (independent of what system calls are allowed by seccomp-bpf and what obscure features they might have).  We should be able to immediately apply that protection to media plugins, but content processes will be more difficult.  PulseAudio is known to be a problem (described in more detail in bug 1151624 comment #4), and there may be others.  Therefore, pid isolation for content processes is a separate bug.
Priority: -- → P3
Whiteboard: sb+
There's a minor problem with audioipc's current use of named Unix-domain sockets: it expects that getppid() in the child/client will return the same number as getpid() in the parent/server; but with my pid isolation work-in-progress, getppid() in the content process returns 0, because the parent process is outside the child's pid namespace.  However, audioipc's socket-wrangling is being redone in bug 1405877 to pass the socket fd directly, which will fix this.
Depends on: 1405877, 1394163
I'm going to fold this back into the original pid-namespaces bug; the current plan is to enable it for GMP and content at the same time.  If we run into content-specific regressions, we can pref it off.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: pid-namespaces
You need to log in before you can comment on or make changes to this bug.