@crazyloglad: The link in the blog post reminds me: are you planning to interview someone and post the results here? It seems like it’s your turn in the relay :-)
When I checked before asking, I scanned the first page of your submissions but did not think to use https://lobste.rs/t/interview which would have made it easy to spot.
Does the XArcan bridge also work for compositing window managers? Does each X11 Picture map to an Arcan object, letting the X11 WM composite Arcan windows? And get the same security properties (can composite, can’t inspect)?
(back from 38c3) - The ‘rootfull’ mode does, with the caveats covered in the post; the Linux graphics stack is in even more flux right now after they started scrambling to redo their synchronisation model (and recreating what nvidia asked for a decade ago in the process) so things break left and right while still being behind android 4(!). The tactic is to work on other parts waiting for things to stabilise.
What we with rootfull is to have an oracle (hiding inside of the Xserver, but it works equally well with a ‘guest additions’ inside QEmu for other OSes); on-vblank: send a tree of ‘x1,y1,x2,y2,order,id’ for each visible window (https://github.com/letoram/xarcan/blob/master/hw/kdrive/arcan/core.c#L455). This means that we can build a scenegraph of nodes sharing the same backing buffer (which is the root pixmap) and set their texture coordinates to match their x1,y1,x2,y2,order. If the ‘id’ doesn’t correspond to a valid backing pixmap, we know it’s one of ours and can substitute that texture.
For ‘rootless’ (what we call ‘redirected’, i.e. Xarcan -redirect -exec xterm) there is no backing for the root node. Instead the server side backing store of a pixmap is an arcan shmif object taken from a pool (window allocation and resize is cheap in X11, deliberately expensive in arcan).
None of this (except -exec) is novel; xwin did it first, then xquartz. Xwayland is the outlier – and by doing so they made everything else harder for everyone (not the first nor the last time). That’s the linked wayland-mailing list post by the former xorg, former wayland maintainer (ajax) saying outright that their design was, and is, bad.
They could’ve started by defining what their own threat model and security measures actually is.
On the other hand, https://keithp.com/x-ideas/x-security/ “Lots of people have added security mechanisms over the years, and the server is instrumented with access control checks which all turn into no-ops in the default environment. The problem has never been about the low-level details of where access control checks should be placed, but in how to apply them.”
A ‘fun’ exercise is taking that talk Daniel gave 2013 where he mostly just joked around, threw shade on X and then handwaved ‘Wayland fixes all that’ but not saying how or why. Make a list of the claims and compare to the current day situation. Apparently it’s easy to become the things you hate.
@crazyloglad: The link in the blog post reminds me: are you planning to interview someone and post the results here? It seems like it’s your turn in the relay :-)
Did so a while back - https://lobste.rs/s/kde6vl/lobsters_interview_with_frederik_braun
Thanks! I’m surprised I missed that at the time.
When I checked before asking, I scanned the first page of your submissions but did not think to use https://lobste.rs/t/interview which would have made it easy to spot.
Does the XArcan bridge also work for compositing window managers? Does each X11 Picture map to an Arcan object, letting the X11 WM composite Arcan windows? And get the same security properties (can composite, can’t inspect)?
(back from 38c3) - The ‘rootfull’ mode does, with the caveats covered in the post; the Linux graphics stack is in even more flux right now after they started scrambling to redo their synchronisation model (and recreating what nvidia asked for a decade ago in the process) so things break left and right while still being behind android 4(!). The tactic is to work on other parts waiting for things to stabilise.
What we with rootfull is to have an oracle (hiding inside of the Xserver, but it works equally well with a ‘guest additions’ inside QEmu for other OSes); on-vblank: send a tree of ‘x1,y1,x2,y2,order,id’ for each visible window (https://github.com/letoram/xarcan/blob/master/hw/kdrive/arcan/core.c#L455). This means that we can build a scenegraph of nodes sharing the same backing buffer (which is the root pixmap) and set their texture coordinates to match their x1,y1,x2,y2,order. If the ‘id’ doesn’t correspond to a valid backing pixmap, we know it’s one of ours and can substitute that texture.
For ‘rootless’ (what we call ‘redirected’, i.e. Xarcan -redirect -exec xterm) there is no backing for the root node. Instead the server side backing store of a pixmap is an arcan shmif object taken from a pool (window allocation and resize is cheap in X11, deliberately expensive in arcan).
None of this (except -exec) is novel; xwin did it first, then xquartz. Xwayland is the outlier – and by doing so they made everything else harder for everyone (not the first nor the last time). That’s the linked wayland-mailing list post by the former xorg, former wayland maintainer (ajax) saying outright that their design was, and is, bad.
Nice. And a very nice counter to the ‘you can’t fix X11 security’ argument from the Wayland folks.
They could’ve started by defining what their own threat model and security measures actually is.
On the other hand, https://keithp.com/x-ideas/x-security/ “Lots of people have added security mechanisms over the years, and the server is instrumented with access control checks which all turn into no-ops in the default environment. The problem has never been about the low-level details of where access control checks should be placed, but in how to apply them.”
A ‘fun’ exercise is taking that talk Daniel gave 2013 where he mostly just joked around, threw shade on X and then handwaved ‘Wayland fixes all that’ but not saying how or why. Make a list of the claims and compare to the current day situation. Apparently it’s easy to become the things you hate.
[Comment removed by author]