1134747 - Investigate possibility of proxying/filtering X11 traffic from Linux desktop content processes

Status: RESOLVED WONTFIX

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

Description

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

If we can't change the graphics subsystem's dependency on being able to send requests to the X11 server, then perhaps we could intercept them and try to restrict them to operating only on resources (drawables?) that it owns.

At the moment, I have no idea how much effort this might require.  It would be helpful to have some data — for example, by intercepting the traffic and logging information about the requests (opcodes used, values of certain fields, etc.).

The machine-readable protocol descriptions in the xcb-proto project (git://anongit.freedesktop.org/git/xcb/proto) may be helpful here.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

http://xtrace.alioth.debian.org/ should be able to give you the logging that you need.

Comment 2

[Julian Hector [:tedd] [:jhector]]

Moving to sblc4 which deals with this issue.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Attachment: Log of Content commands to X server

This is even without opening a proper content tab.

Comment 4

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

Mentioning this because it'll probably be annoying to debug if it matters: X11 can do fd-passing, so the proxy may need to receive and forward SCM_RIGHTS.  See also: https://keithp.com/blogs/fd-passing/

Comment 5

[Gian-Carlo Pascutto [:gcp]]

This got complex rather quickly: the proxy needs to inspect both ends of the connection flow to properly map X protocol extension ids, or extend it's side channel from the parent process to receive that mapping. Given that we are removing all toolkit/graphics stuff from content to achieve win32k lockdown, effort is probably better spent there. We currently are no longer pursuing this approach.