1445003 - RenderDoc's networking conflicts with sandboxing

Status: RESOLVED FIXED

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

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

RenderDoc (https://renderdoc.org/) seems to work by having the process that's using GL accept socket connections from the tools; this uses the Internet domain on desktop Linux.  (On Android it uses Unix-domain abstract addresses, which I assume is because an app without Internet permissions on Android can't create Internet-domain sockets, but that would have the same problems.)

The socket is created/bound early in startup, before the seccomp-bpf policy is applied, but (1) the policy doesn't allow accept/accept4, and (2) on distributions that allow it, the process is already in a separate network namespace at that point, which means nothing could connect to the socket anyway.

It should be enough to detect it via env vars and lower the sandbox level.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Better idea: allow accept() — which needs to be handled specially anyway because it's not allowed at levels 1-3 in the aftermath of bug 1358647 and bug 1362537 — and don't unshare the network namespace (like for remote X11), but otherwise leave the network/socket restrictions intact (no outbound connections, no new listening sockets, etc.).

This seems to work: RenderDoc can connect to child processes and determine whether they're using GL.  However, it can't capture, apparently because we're rendering to an offscreen surface so it doesn't know what the start/end of a frame is; this is not affected by sandboxing, but if capturing WebGL would fail on 60 anyway, then there's not much point in uplifting this.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Bug 1445003 - Detect RenderDoc and adjust the sandbox policy so it can work.

RenderDoc, a graphics debugging tool, uses a preload library that
creates a listening socket (Internet-domain) early in startup and
accepts connections from the frontend.  If it's detected (via env vars),
we allow accept/accept4 (but not socket/bind/listen), and remain in
the parent process's network namespace so that other processes can
connect to the socket.

This doesn't change the sandbox policy if not running under RenderDoc.

Review commit: https://reviewboard.mozilla.org/r/227576/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/227576/

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 8958659 [details]
Bug 1445003 - Detect RenderDoc and adjust the sandbox policy so it can work.

https://reviewboard.mozilla.org/r/227576/#review233416

::: security/sandbox/common/SandboxSettings.cpp:13
(Diff revision 1)
>  
>  #include "mozilla/ModuleUtils.h"
>  #include "mozilla/Preferences.h"
>  
>  #include "prenv.h"
> +#include <stdio.h>

Debugging leftover?

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Comment on attachment 8958659 [details]
Bug 1445003 - Detect RenderDoc and adjust the sandbox policy so it can work.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/227576/diff/1-2/

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Comment on attachment 8958659 [details]
Bug 1445003 - Detect RenderDoc and adjust the sandbox policy so it can work.

https://reviewboard.mozilla.org/r/227576/#review233516

::: security/sandbox/common/SandboxSettings.cpp:13
(Diff revision 1)
>  
>  #include "mozilla/ModuleUtils.h"
>  #include "mozilla/Preferences.h"
>  
>  #include "prenv.h"
> +#include <stdio.h>

Yes; thanks for spotting that.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0b8d58958178
Detect RenderDoc and adjust the sandbox policy so it can work. r=gcp

Comment 7

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/0b8d58958178