pid namespace isolation for sandboxed Linux child processes
Categories
(Core :: Security: Process Sandboxing, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox40 | --- | affected |
People
(Reporter: jld, Assigned: jld)
References
(Blocks 2 open bugs)
Details
(Whiteboard: sblc5)
Attachments
(3 obsolete files)
Assignee | ||
Updated•9 years ago
|
Assignee | ||
Comment 1•9 years ago
|
||
Assignee | ||
Comment 2•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Updated•9 years ago
|
Comment 3•8 years ago
|
||
Assignee | ||
Updated•8 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Assignee | ||
Comment 4•7 years ago
|
||
Assignee | ||
Updated•7 years ago
|
Assignee | ||
Comment 6•6 years ago
|
||
Assignee | ||
Comment 7•6 years ago
|
||
Assignee | ||
Comment 8•4 years ago
|
||
Interposing getpid
may not be the best idea — we've recently encountered code in Mesa that uses kcmp
and needs the real getpid
, and there may be other uses of similar APIs by system libraries that we aren't aware of or that may be added in the future.
I think this should instead add a function in MFBT or somewhere central like that, for use in cases that need the globally meaningful pid (IPC, log messages, etc.)
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 9•2 years ago
|
||
In addition to auditing users of getpid()
(or base::GetCurrentProcId()
) and fixing them as previously described, there's also the crash reporter: when it determines which thread is the crashing one, that thread ID is given by the crashing process and in the wrong namespace, so it won't match the thread IDs that the reporter gets from procfs. (I think; I haven't tried this recently.) One possible fix is to read the NSpid
fields from /proc/{pid}/task/{tid}/status
when iterating the threads, but that was added in 4.1 and it would be nice to have something more backwards compatible if possible. Chromium's use of Breakpad with pid namespaces predates that, so it would have had to have a solution for this (maybe it matches threads by stack pointer value?) which could maybe be adapted; I haven't investigated yet.
It would be nice if the crashing process could use an explicitly sent SCM_CREDENTIALS
with the tid, because that will map them into the recipient's namespaces, but that doesn't work: if the sending process has CAP_SYS_ADMIN
within the namespace then it can send any pid/tid in that namespace, but otherwise it can send only its own pid and we don't want the process to have capabilities (even within an unprivileged user namespace) while sandboxed in order to reduce kernel attack surface. (Also, capabilities are automatically dropped on exec
.) This limitation is intentional.
Updated•2 years ago
|
Description
•