* Proxying Wayland for untrusted clients @ 2021-05-22 13:05 Alyssa Ross 2021-05-22 13:45 ` Michael Raskin 2021-05-22 17:13 ` Jean-Philippe Ouellet 0 siblings, 2 replies; 11+ messages in thread From: Alyssa Ross @ 2021-05-22 13:05 UTC (permalink / raw) To: discuss; +Cc: Aaron Janse, Puck Meerburg, Thomas Leonard [-- Attachment #1: Type: text/plain, Size: 2922 bytes --] I've been thinking a lot about this for a while, thanks to conversations with Thomas and Puck, CCed here. I think it's time to put it into words properly and start working towards making it happen. One of the benefits that Wayland is supposed to have over X11 is security. A Wayland application isn't supposed to be able to record the screen without user permission, for example. But in most compositors, it can, with no restrictions. Existing Wayland compositors are monolithic, and each one would have to implement its own access controls. (Mutter already does this to some extent, at least for screen sharing, I believe.) The popular Wayland compositors are largely focused on being feature-complete reimplementations of their X11 equivalents, and so taking advantage of the security features and access controls the Wayland protocol makes possible hasn't been a priority for them. Additionally, every popular Wayland compositor is written in a memory-unsafe language, and this combined with the complexity of the Wayland protocol, with all the extensions involved, presents a serious concern to applications of Wayland that involve untrusted clients. To solve these problems, I propose a proxy program that sits between Wayland clients and the compositor, in the same privelege domain as the compositor. The proxy would decode and re-encode every Wayland request (client->compositor message), and would discard any request it didn't understand. This would mitigate the problem of a large, privileged program written in a memory-unsafe language being exposed to untrusted inputs. Additionally, the proxy would support a plugin interface, through which the user of the proxy (or their distributor) could configure custom behaviour. This could be used to prompt the user for confirmation before allowing a screen capture request, or even to implement a similar thing for e.g. clipboard access, for which there is no support in the Wayland protocol. It could even be used to modify surfaces, to implement things like Qubes-style unspoofable coloured window borders. This approach would allow permissions systems and other custom Wayland behaviour to be implemented in a compositor-independent manner. Distributions which suppor tseveral compositors could implement customisations in a single place, and users of compositors which lack security features and the assurances memory-safety can provide against untrusted input would gain access to those things. I'd like to hear feedback here, but I think early in the life of this idea we should also reach out to the broader Wayland community. I think there's a lot of potential for this idea beyond Spectrum, and it would be great if it could be something developed with input from a big breadth of Wayland users. If we can do that, it might be sensible for it to live at freedesktop.org? I'm not sure how that works. Let me know what you all think. :) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Proxying Wayland for untrusted clients 2021-05-22 13:05 Proxying Wayland for untrusted clients Alyssa Ross @ 2021-05-22 13:45 ` Michael Raskin 2021-05-22 15:08 ` Alyssa Ross 2021-05-22 16:18 ` Michael Raskin 2021-05-22 17:13 ` Jean-Philippe Ouellet 1 sibling, 2 replies; 11+ messages in thread From: Michael Raskin @ 2021-05-22 13:45 UTC (permalink / raw) To: hi, discuss; +Cc: aaron, puck, talex5 >One of the benefits that Wayland is supposed to have over X11 is >security. A Wayland application isn't supposed to be able to record the >screen without user permission, for example. But in most compositors, >it can, with no restrictions. Existing Wayland compositors are … and theoretically, an X server could feed empty capture to a client it does not like … (of course with literal decades of actual backwards compatibility, X11 protocol has accumulated enough extensions that assigning permissions to all of them might be somewhat painful) >monolithic, and each one would have to implement its own access >controls. (Mutter already does this to some extent, at least for screen >sharing, I believe.) The popular Wayland compositors are largely >focused on being feature-complete reimplementations of their X11 >equivalents, and so taking advantage of the security features and access >controls the Wayland protocol makes possible hasn't been a priority for … unsurprisingly, as these are typically WM teams who are now deprived of what Xorg server did for everyone. >To solve these problems, I propose a proxy program that sits between >Wayland clients and the compositor, in the same privelege domain as the >compositor. The proxy would decode and re-encode every Wayland request >(client->compositor message), and would discard any request it didn't >understand. This would mitigate the problem of a large, privileged >program written in a memory-unsafe language being exposed to untrusted Presumably, also validating that the shared memory buffers passed around have the same size and protection as promised? >inputs. Additionally, the proxy would support a plugin interface, >through which the user of the proxy (or their distributor) could >configure custom behaviour. This could be used to prompt the user for >confirmation before allowing a screen capture request, or even to >implement a similar thing for e.g. clipboard access, for which there is >no support in the Wayland protocol. It could even be used to modify >surfaces, to implement things like Qubes-style unspoofable coloured >window borders. I am tempted to ask how close it will be to providing a socket for WM and window decorator implementation (with some suitably limited compositor as the backend behind the proxy). (So basically, defining a scope will be hard, and defining a scope in a usefully extensible way might be even harder) >This approach would allow permissions systems and other custom Wayland >behaviour to be implemented in a compositor-independent manner. >Distributions which suppor tseveral compositors could implement >customisations in a single place, and users of compositors which lack >security features and the assurances memory-safety can provide against >untrusted input would gain access to those things. That surely sounds good… ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients 2021-05-22 13:45 ` Michael Raskin @ 2021-05-22 15:08 ` Alyssa Ross 2021-05-22 16:18 ` Michael Raskin 1 sibling, 0 replies; 11+ messages in thread From: Alyssa Ross @ 2021-05-22 15:08 UTC (permalink / raw) To: 7c6f434c, discuss; +Cc: aaron, puck, talex5 [-- Attachment #1: Type: text/plain, Size: 4162 bytes --] Michael Raskin <7c6f434c@mail.ru> writes: >>One of the benefits that Wayland is supposed to have over X11 is >>security. A Wayland application isn't supposed to be able to record the >>screen without user permission, for example. But in most compositors, >>it can, with no restrictions. Existing Wayland compositors are > > … and theoretically, an X server could feed empty capture to a client it > does not like … > > (of course with literal decades of actual backwards compatibility, X11 > protocol has accumulated enough extensions that assigning permissions > to all of them might be somewhat painful) Considering that the world has convered on a single X server implementation, and it's apparently pretty horrible to maintain, I'm not sure I feel very positive about the idea of a custom one! And yeah, with Wayland clients are already expecting to have to ask for permission. (I've just learned that this is actually done over DBus, so the proxy would have to implement that as well, ugh.) I suspect X11 clients wouldn't be very happy if it took them seconds to get the result of their attempted screen capture, and users wouldn't be very happy if screen sharing was just a blank box by default, rather than a permission request. (I'm not sure which of those would be possible with X11.) >>monolithic, and each one would have to implement its own access >>controls. (Mutter already does this to some extent, at least for screen >>sharing, I believe.) The popular Wayland compositors are largely >>focused on being feature-complete reimplementations of their X11 >>equivalents, and so taking advantage of the security features and access >>controls the Wayland protocol makes possible hasn't been a priority for > > … unsurprisingly, as these are typically WM teams who are now deprived > of what Xorg server did for everyone. Only the ones that don't use wlroots, I think. wlroots has its own problems, but in large part those are the problems we're trying to mitigate here. >>To solve these problems, I propose a proxy program that sits between >>Wayland clients and the compositor, in the same privelege domain as the >>compositor. The proxy would decode and re-encode every Wayland request >>(client->compositor message), and would discard any request it didn't >>understand. This would mitigate the problem of a large, privileged >>program written in a memory-unsafe language being exposed to untrusted > > Presumably, also validating that the shared memory buffers passed around > have the same size and protection as promised? Aren't shared memory buffers usually handed out by the compositor, to the client? IIRC this was the reason virtio wayland can work when it only supports shared memory that was allocated by the host. >>inputs. Additionally, the proxy would support a plugin interface, >>through which the user of the proxy (or their distributor) could >>configure custom behaviour. This could be used to prompt the user for >>confirmation before allowing a screen capture request, or even to >>implement a similar thing for e.g. clipboard access, for which there is >>no support in the Wayland protocol. It could even be used to modify >>surfaces, to implement things like Qubes-style unspoofable coloured >>window borders. > > I am tempted to ask how close it will be to providing a socket for WM > and window decorator implementation (with some suitably limited > compositor as the backend behind the proxy). > > (So basically, defining a scope will be hard, and defining a scope in > a usefully extensible way might be even harder) I don't understand this point. Can you rephrase / expand? >>This approach would allow permissions systems and other custom Wayland >>behaviour to be implemented in a compositor-independent manner. >>Distributions which suppor tseveral compositors could implement >>customisations in a single place, and users of compositors which lack >>security features and the assurances memory-safety can provide against >>untrusted input would gain access to those things. > > That surely sounds good… [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients 2021-05-22 13:45 ` Michael Raskin 2021-05-22 15:08 ` Alyssa Ross @ 2021-05-22 16:18 ` Michael Raskin 2021-05-22 17:22 ` Alyssa Ross 2021-05-22 20:00 ` Michael Raskin 1 sibling, 2 replies; 11+ messages in thread From: Michael Raskin @ 2021-05-22 16:18 UTC (permalink / raw) To: hi, discuss; +Cc: aaron, puck, talex5 >>>One of the benefits that Wayland is supposed to have over X11 is >>>security. A Wayland application isn't supposed to be able to record the >>>screen without user permission, for example. But in most compositors, >>>it can, with no restrictions. Existing Wayland compositors are >> >> … and theoretically, an X server could feed empty capture to a client it >> does not like … >> >> (of course with literal decades of actual backwards compatibility, X11 >> protocol has accumulated enough extensions that assigning permissions >> to all of them might be somewhat painful) > >Considering that the world has convered on a single X server >implementation, and it's apparently pretty horrible to maintain, I'm not >sure I feel very positive about the idea of a custom one! Considering how much works fine in Xvnc which kind of lacks half the extensions, and considering that all the bad hardware stuff now needs to be handled in each compositor, it is unclear how much worse it would actually be. So OpenGL-first design sounds like the real reason for all the mess. >And yeah, with Wayland clients are already expecting to have to ask for >permission. (I've just learned that this is actually done over DBus, so >the proxy would have to implement that as well, ugh.) I suspect X11 >clients wouldn't be very happy if it took them seconds to get the result >of their attempted screen capture, and users wouldn't be very happy if >screen sharing was just a blank box by default, rather than a permission >request. (I'm not sure which of those would be possible with X11.) Assuming the client does not use the protocol extensions to control the request, presumably black rectangle immediately and a permission dialog from WM to the user, then the capture suddenly getting real data. Single-window capture depends on whether the client can handle capture resize, if yes, no problem (capture the generic «window» in the client, get black box while the user picks the true target). Otherwise there might be some juggling indeed. >> … unsurprisingly, as these are typically WM teams who are now deprived >> of what Xorg server did for everyone. > >Only the ones that don't use wlroots, I think. wlroots has its own >problems, but in large part those are the problems we're trying to >mitigate here. Yes, but it seems memory-unsafe even by the «careful C» standards, and it seems to crash noticeably often with reasonably well-behaved clients, so just a protocol compliance filter would not be enough. >>>To solve these problems, I propose a proxy program that sits between >>>Wayland clients and the compositor, in the same privelege domain as the >>>compositor. The proxy would decode and re-encode every Wayland request >>>(client->compositor message), and would discard any request it didn't >>>understand. This would mitigate the problem of a large, privileged >>>program written in a memory-unsafe language being exposed to untrusted >> >> Presumably, also validating that the shared memory buffers passed around >> have the same size and protection as promised? > >Aren't shared memory buffers usually handed out by the compositor, to >the client? IIRC this was the reason virtio wayland can work when it >only supports shared memory that was allocated by the host. Looks like for wl_shm the client creates and shm object and sends FD to the server, then both sides mmap from there. Given that one could cook an FD with approximately arbitrary combination of properties, I guess some care should be taken about this, too. >>>no support in the Wayland protocol. It could even be used to modify >>>surfaces, to implement things like Qubes-style unspoofable coloured >>>window borders. >> >> I am tempted to ask how close it will be to providing a socket for WM >> and window decorator implementation (with some suitably limited >> compositor as the backend behind the proxy). >> >> (So basically, defining a scope will be hard, and defining a scope in >> a usefully extensible way might be even harder) > >I don't understand this point. Can you rephrase / expand? Well, you start describing a proxy that is basically «only valid messages pass» and that's it, then add that it could also implement some more functionality. Then you say plugins for policy-heavy functionality. (I guess at that point the natural next step is a socket so that safety-handling and user logic could be in different processes) This sounds like a recipe for scope creep, although it might also be good as a single well-vetted Thing being safety-critical and a lot of policy decisions being pushed to restartable and functionality-restricted separate processes is actually better than the current recommended approach to Wayland compositors. If you want to try pushing the project to freedesktop, I suspect it is a good idea to define how much scope you want to include into the pitch. Although apparently they don't have any objections to hosting software with heavy scope creep, when reaching for a high profile, it is a good idea to set internal expectations before having to manage external ones. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients 2021-05-22 16:18 ` Michael Raskin @ 2021-05-22 17:22 ` Alyssa Ross 2021-05-22 18:48 ` Aaron Janse 2021-05-22 20:00 ` Michael Raskin 1 sibling, 1 reply; 11+ messages in thread From: Alyssa Ross @ 2021-05-22 17:22 UTC (permalink / raw) To: 7c6f434c, discuss; +Cc: aaron, puck, talex5 [-- Attachment #1: Type: text/plain, Size: 5357 bytes --] Michael Raskin <7c6f434c@mail.ru> writes: >>>>One of the benefits that Wayland is supposed to have over X11 is >>>>security. A Wayland application isn't supposed to be able to record the >>>>screen without user permission, for example. But in most compositors, >>>>it can, with no restrictions. Existing Wayland compositors are >>> >>> … and theoretically, an X server could feed empty capture to a client it >>> does not like … >>> >>> (of course with literal decades of actual backwards compatibility, X11 >>> protocol has accumulated enough extensions that assigning permissions >>> to all of them might be somewhat painful) >> >>Considering that the world has convered on a single X server >>implementation, and it's apparently pretty horrible to maintain, I'm not >>sure I feel very positive about the idea of a custom one! > > Considering how much works fine in Xvnc which kind of lacks half the > extensions, and considering that all the bad hardware stuff now needs to > be handled in each compositor, it is unclear how much worse it would > actually be. > > So OpenGL-first design sounds like the real reason for all the mess. What do you mean by bad hardware stuff? Most hardware should be handled by KMS and libinput, shouldn't it? >>> … unsurprisingly, as these are typically WM teams who are now deprived >>> of what Xorg server did for everyone. >> >>Only the ones that don't use wlroots, I think. wlroots has its own >>problems, but in large part those are the problems we're trying to >>mitigate here. > > Yes, but it seems memory-unsafe even by the «careful C» standards, and > it seems to crash noticeably often with reasonably well-behaved clients, > so just a protocol compliance filter would not be enough. My experience with wlroots has been that when it crashes, it's because of quirks with monitor state and stuff, not anything from the Wayland protocol. Have you had a different experience? Another thing the proxy would be really cool for that I didn't mention before is debugging. Potentially you could even record and replay Wayland messages, which would help with any crash that was from Wayland. >>>>To solve these problems, I propose a proxy program that sits between >>>>Wayland clients and the compositor, in the same privelege domain as the >>>>compositor. The proxy would decode and re-encode every Wayland request >>>>(client->compositor message), and would discard any request it didn't >>>>understand. This would mitigate the problem of a large, privileged >>>>program written in a memory-unsafe language being exposed to untrusted >>> >>> Presumably, also validating that the shared memory buffers passed around >>> have the same size and protection as promised? >> >>Aren't shared memory buffers usually handed out by the compositor, to >>the client? IIRC this was the reason virtio wayland can work when it >>only supports shared memory that was allocated by the host. > > Looks like for wl_shm the client creates and shm object and sends FD to > the server, then both sides mmap from there. Given that one could cook > an FD with approximately arbitrary combination of properties, I guess > some care should be taken about this, too. Hmm, yes, looks like you're right. I wonder how virtio wayland can work the way it does, then... But yes, that is something we could validate. >>>>no support in the Wayland protocol. It could even be used to modify >>>>surfaces, to implement things like Qubes-style unspoofable coloured >>>>window borders. >>> >>> I am tempted to ask how close it will be to providing a socket for WM >>> and window decorator implementation (with some suitably limited >>> compositor as the backend behind the proxy). >>> >>> (So basically, defining a scope will be hard, and defining a scope in >>> a usefully extensible way might be even harder) >> >>I don't understand this point. Can you rephrase / expand? > > Well, you start describing a proxy that is basically «only valid > messages pass» and that's it, then add that it could also implement some > more functionality. Then you say plugins for policy-heavy functionality. > (I guess at that point the natural next step is a socket so that > safety-handling and user logic could be in different processes) > > This sounds like a recipe for scope creep, although it might also be > good as a single well-vetted Thing being safety-critical and a lot of > policy decisions being pushed to restartable and > functionality-restricted separate processes is actually better than the > current recommended approach to Wayland compositors. > > If you want to try pushing the project to freedesktop, I suspect it is > a good idea to define how much scope you want to include into the pitch. > Although apparently they don't have any objections to hosting software > with heavy scope creep, when reaching for a high profile, it is a good > idea to set internal expectations before having to manage external ones. I actually think the scope is fairly limited? 1. Receive request 2. Validate request 3. Asynchronously run request through plugins (you're right that external processes are probably a better idea, although I worry about complexity and performance). 4. Forward request to compositor [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients 2021-05-22 17:22 ` Alyssa Ross @ 2021-05-22 18:48 ` Aaron Janse 0 siblings, 0 replies; 11+ messages in thread From: Aaron Janse @ 2021-05-22 18:48 UTC (permalink / raw) To: Alyssa Ross, 7c6f434c, discuss; +Cc: puck, talex5 > This proposal turns the overall system of policy enforcement from what > is currently a nice single centralized component (the compositor) with > global observation, total visibility, total control, and nice > non-distributed-system guarantees on message ordering, delivery, etc. > into a decentralized and distributed system without those guarantees, > subject to all manner of race conditions, etc. This makes it much > harder to guarantee that intended policies are indeed enforced in the manner expected. How would the new system be distributed? My understanding is that it would just be a single process alongside the compositor. > I actually think the scope is fairly limited? Agreed, and I don't see a way to implement Spectrum without something like this. At a bare minimum we'd need a proxy for window decorations, unless we feel comfortable forking an existing window compositor. I'm on mobile so I can't quote easily (I also have trouble reading hard-wrapped emails here), but we do have to place trust somewhere, and writing our own compositor would be too difficult, so it makes sense to have a simple parse/encode system if only to prevent special extensions that we don't recognize. - Aaron On Sat, May 22, 2021, at 10:22 AM, Alyssa Ross wrote: > Michael Raskin <7c6f434c@mail.ru> writes: > > >>>>One of the benefits that Wayland is supposed to have over X11 is > >>>>security. A Wayland application isn't supposed to be able to record the > >>>>screen without user permission, for example. But in most compositors, > >>>>it can, with no restrictions. Existing Wayland compositors are > >>> > >>> … and theoretically, an X server could feed empty capture to a client it > >>> does not like … > >>> > >>> (of course with literal decades of actual backwards compatibility, X11 > >>> protocol has accumulated enough extensions that assigning permissions > >>> to all of them might be somewhat painful) > >> > >>Considering that the world has convered on a single X server > >>implementation, and it's apparently pretty horrible to maintain, I'm not > >>sure I feel very positive about the idea of a custom one! > > > > Considering how much works fine in Xvnc which kind of lacks half the > > extensions, and considering that all the bad hardware stuff now needs to > > be handled in each compositor, it is unclear how much worse it would > > actually be. > > > > So OpenGL-first design sounds like the real reason for all the mess. > > What do you mean by bad hardware stuff? Most hardware should be handled > by KMS and libinput, shouldn't it? > > >>> … unsurprisingly, as these are typically WM teams who are now deprived > >>> of what Xorg server did for everyone. > >> > >>Only the ones that don't use wlroots, I think. wlroots has its own > >>problems, but in large part those are the problems we're trying to > >>mitigate here. > > > > Yes, but it seems memory-unsafe even by the «careful C» standards, and > > it seems to crash noticeably often with reasonably well-behaved clients, > > so just a protocol compliance filter would not be enough. > > My experience with wlroots has been that when it crashes, it's because > of quirks with monitor state and stuff, not anything from the Wayland > protocol. Have you had a different experience? > > Another thing the proxy would be really cool for that I didn't mention > before is debugging. Potentially you could even record and replay > Wayland messages, which would help with any crash that was from Wayland. > > >>>>To solve these problems, I propose a proxy program that sits between > >>>>Wayland clients and the compositor, in the same privelege domain as the > >>>>compositor. The proxy would decode and re-encode every Wayland request > >>>>(client->compositor message), and would discard any request it didn't > >>>>understand. This would mitigate the problem of a large, privileged > >>>>program written in a memory-unsafe language being exposed to untrusted > >>> > >>> Presumably, also validating that the shared memory buffers passed around > >>> have the same size and protection as promised? > >> > >>Aren't shared memory buffers usually handed out by the compositor, to > >>the client? IIRC this was the reason virtio wayland can work when it > >>only supports shared memory that was allocated by the host. > > > > Looks like for wl_shm the client creates and shm object and sends FD to > > the server, then both sides mmap from there. Given that one could cook > > an FD with approximately arbitrary combination of properties, I guess > > some care should be taken about this, too. > > Hmm, yes, looks like you're right. I wonder how virtio wayland can work > the way it does, then... But yes, that is something we could validate. > > >>>>no support in the Wayland protocol. It could even be used to modify > >>>>surfaces, to implement things like Qubes-style unspoofable coloured > >>>>window borders. > >>> > >>> I am tempted to ask how close it will be to providing a socket for WM > >>> and window decorator implementation (with some suitably limited > >>> compositor as the backend behind the proxy). > >>> > >>> (So basically, defining a scope will be hard, and defining a scope in > >>> a usefully extensible way might be even harder) > >> > >>I don't understand this point. Can you rephrase / expand? > > > > Well, you start describing a proxy that is basically «only valid > > messages pass» and that's it, then add that it could also implement some > > more functionality. Then you say plugins for policy-heavy functionality. > > (I guess at that point the natural next step is a socket so that > > safety-handling and user logic could be in different processes) > > > > This sounds like a recipe for scope creep, although it might also be > > good as a single well-vetted Thing being safety-critical and a lot of > > policy decisions being pushed to restartable and > > functionality-restricted separate processes is actually better than the > > current recommended approach to Wayland compositors. > > > > If you want to try pushing the project to freedesktop, I suspect it is > > a good idea to define how much scope you want to include into the pitch. > > Although apparently they don't have any objections to hosting software > > with heavy scope creep, when reaching for a high profile, it is a good > > idea to set internal expectations before having to manage external ones. > > I actually think the scope is fairly limited? > > 1. Receive request > 2. Validate request > 3. Asynchronously run request through plugins (you're right that > external processes are probably a better idea, although I worry about > complexity and performance). > 4. Forward request to compositor > > Attachments: > * signature.asc ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients 2021-05-22 16:18 ` Michael Raskin 2021-05-22 17:22 ` Alyssa Ross @ 2021-05-22 20:00 ` Michael Raskin 1 sibling, 0 replies; 11+ messages in thread From: Michael Raskin @ 2021-05-22 20:00 UTC (permalink / raw) To: hi, discuss; +Cc: aaron, puck, talex5 >> Considering how much works fine in Xvnc which kind of lacks half the >> extensions, and considering that all the bad hardware stuff now needs to >> be handled in each compositor, it is unclear how much worse it would >> actually be. >> >> So OpenGL-first design sounds like the real reason for all the mess. > >What do you mean by bad hardware stuff? Most hardware should be handled >by KMS and libinput, shouldn't it? I think there is somehow still some buffer-management code which is not fully indifferent to the GPU used, and apparently that goes beyond proprietary drivers. Has it been completely cleaned up for nouveau? >>>> … unsurprisingly, as these are typically WM teams who are now deprived >>>> of what Xorg server did for everyone. >>> >>>Only the ones that don't use wlroots, I think. wlroots has its own >>>problems, but in large part those are the problems we're trying to >>>mitigate here. >> >> Yes, but it seems memory-unsafe even by the «careful C» standards, and >> it seems to crash noticeably often with reasonably well-behaved clients, >> so just a protocol compliance filter would not be enough. > >My experience with wlroots has been that when it crashes, it's because >of quirks with monitor state and stuff, not anything from the Wayland >protocol. Have you had a different experience? I still avoid Wayland because it would be too much of a drop in features compared to my X11 setup. I have just checked segmentation fault bugs in the tracker… Of course you do not get many crashes due to Wayland protocol quirks, if only because your applications are not going out of their way to crash wl_roots. >Another thing the proxy would be really cool for that I didn't mention >before is debugging. Potentially you could even record and replay >Wayland messages, which would help with any crash that was from Wayland. Indeed. Then if we have a good proxy codebase, yet another proxy might even help some («good, clean») applications shrug off a compositor crash. >>>Aren't shared memory buffers usually handed out by the compositor, to >>>the client? IIRC this was the reason virtio wayland can work when it >>>only supports shared memory that was allocated by the host. >> >> Looks like for wl_shm the client creates and shm object and sends FD to >> the server, then both sides mmap from there. Given that one could cook >> an FD with approximately arbitrary combination of properties, I guess >> some care should be taken about this, too. > >Hmm, yes, looks like you're right. I wonder how virtio wayland can work >the way it does, then... But yes, that is something we could validate. Wait, I remember you explaining a pretty complicated dance to make some buffer host-allocated from the VM point of view but client-managed from the Wayland point of view. Am I misremembering? >>>>>no support in the Wayland protocol. It could even be used to modify >>>>>surfaces, to implement things like Qubes-style unspoofable coloured >>>>>window borders. >>>> >>>> I am tempted to ask how close it will be to providing a socket for WM >>>> and window decorator implementation (with some suitably limited >>>> compositor as the backend behind the proxy). >>>> >>>> (So basically, defining a scope will be hard, and defining a scope in >>>> a usefully extensible way might be even harder) >>> >>>I don't understand this point. Can you rephrase / expand? >> >> Well, you start describing a proxy that is basically «only valid >> messages pass» and that's it, then add that it could also implement some >> more functionality. Then you say plugins for policy-heavy functionality. >> (I guess at that point the natural next step is a socket so that >> safety-handling and user logic could be in different processes) >> >> This sounds like a recipe for scope creep, although it might also be >> good as a single well-vetted Thing being safety-critical and a lot of >> policy decisions being pushed to restartable and >> functionality-restricted separate processes is actually better than the >> current recommended approach to Wayland compositors. >> >> If you want to try pushing the project to freedesktop, I suspect it is >> a good idea to define how much scope you want to include into the pitch. >> Although apparently they don't have any objections to hosting software >> with heavy scope creep, when reaching for a high profile, it is a good >> idea to set internal expectations before having to manage external ones. > >I actually think the scope is fairly limited? > >1. Receive request >2. Validate request This alone could become interesting really quickly. >3. Asynchronously run request through plugins (you're right that > external processes are probably a better idea, although I worry about > complexity and performance). And then it all depends on what we want the plugins and external processes to do, as this functionality needs interfaces. (Re: performance — I guess «simple but high-volume» and «complicated but with small request and response» need to be separated, policy vs. mechanism, and all that) >4. Forward request to compositor Re-serialise more than forward, I really hope. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients 2021-05-22 13:05 Proxying Wayland for untrusted clients Alyssa Ross 2021-05-22 13:45 ` Michael Raskin @ 2021-05-22 17:13 ` Jean-Philippe Ouellet 2021-05-25 11:40 ` Alyssa Ross 1 sibling, 1 reply; 11+ messages in thread From: Jean-Philippe Ouellet @ 2021-05-22 17:13 UTC (permalink / raw) To: Alyssa Ross; +Cc: discuss, Aaron Janse, Puck Meerburg, Thomas Leonard Glad to see this taking form! First of all, in case the points of technical feedback further down might be interpreted to suggest otherwise, I *am* in favor of exploration of this idea. I do believe it to be worthwhile to implement, just is perhaps not the ultimate nor sole solution one might want, at least in the form currently conceived. On Sat, May 22, 2021 at 9:06 AM Alyssa Ross <hi@alyssa.is> wrote: > [...] I propose a proxy program that sits between > Wayland clients and the compositor, in the same privelege domain as the > compositor. The proxy would decode and re-encode every Wayland request > (client->compositor message), and would discard any request it didn't > understand. > > This would mitigate the problem of a large, privileged > program written in a memory-unsafe language being exposed to untrusted > inputs. As attractive as this approach sounds at first, I do not believe it mitigates the problem in a manner which I would be comfortable placing a large degree of trust in. I see two fundamental weaknesses: 1. Opening pandora's box of distributed systems. This proposal turns the overall system of policy enforcement from what is currently a nice single centralized component (the compositor) with global observation, total visibility, total control, and nice non-distributed-system guarantees on message ordering, delivery, etc. into a decentralized and distributed system without those guarantees, subject to all manner of race conditions, etc. This makes it much harder to guarantee that intended policies are indeed enforced in the manner expected. There are endless examples from the distributed systems literature of how this can go wrong, but as a very relevant example from the same application domain, I would like to bring attention to subtle race conditions in the implementation of the Qubes clipboard-handling logic which manifested in QSB #013 [1]. Refer to the linked advisory for background and details. To summarize with additional context and considerations as I see them applying here: The way the Qubes GUI stack works is somewhat similar to what you describe, with two parts, a "vmside" "agent" [2] (in the untrusted VM whose contents are to be displayed) and an "xside" "daemon" [3] (in the semi-trusted GUI VM running the window manager, traditionally dom0). The "vmside" (gui-agent) implements a minimal X window manager, analogous to sommelier [4], whereas the "xside" (so-called gui-daemon) implements what is effectively analogous to the proxy you propose here living on the compositor-side of the VM trust boundary. For each VM, a separate vm-side gui-agent and x-side gui-daemon pair is created. A (possibly outdated) version of the overall scheme and protocol is documented here [5]. Things like safe clipboard handling is implemented via these X11 proxies. Where things get a little... difficult... is the fact that we do not have a single trusted arbiter with global visibility and synchronous ordering guarantees, but rather a bunch of these GUI daemon processes (which I posit should be viewed as a distributed system) which must somehow successfully coordinate and synchronize to enforce security guarantees. This is hard, and in the case of QSB #013, corner cases were overlooked wherein an adversary could cause states to be reached which violate user expectations in unsafe ways. In hindsight, the fact that something was overlooked should not be a surprising result, given the difficulty of the nature of the problem, and that no formal methods had been applied (at the time of the advisory) to attempt to verify the implementation. [1]: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt [2]: https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/gui-agent/vmside.c [3]: https://github.com/QubesOS/qubes-gui-daemon/blob/master/gui-daemon/xside.c [4]: https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/vm_tools/sommelier/README.md I see a couple ways to address weakness 1: a) exhaustively enumerate what interactions between these proxies carry security concerns, formalize the security properties of the protocols involved, and attempt to somehow verify that the implementations correctly follow the protocols (I propose this mostly as a straw man to illustrate the comparative apparent simplicity of the following approach, though, again, I do not wish to discourage anyone who might wish to try anyway -- for example I very much appreciate [5], but we'd still need a bunch more work like it to have meaningful coverage of the higher-level protocols like the clipboard handling (which exists on top of the gui protocol, which might also need a parallel model of the window manager for certain properties), and then once completed initially, it still requires uncommon skill sets to maintain in sync as the software it models evolves) [5]: https://roscidus.com/blog/blog/2019/01/01/using-tla-plus-to-understand-xen-vchan/ b) avoid the class of distributed systems issues altogether, by avoiding ay need to coordinate among proxies, by instead embedding the relevant decision logic at a single point which already has total ordering and global visibility, such as within the logical boundary of the compositor (note "logical boundary" -- which needn't necessarily mean "within the a single memory-unsafe monolith with guest-reachable attack surface" -- there's likely a middle ground of compositor disaggregation and privilege separation which does not also turn authorization logic into a distributed system) This point alone is not an argument against having a safer parser in front, but rather suggests that a proxy seems unlikely to be the best place for authorization logic, especially when said proxies need to coordinate, and rather that such logic seems better suited for being embedded within the compositor. 2. State-synchronization issues, protocol interpretation differences, "the WAF problem". Introducing a proxy introduces another implementation of a parser, data model, and any applicable retained state. All of this has various opportunities to become desynchronized at various layers. I suspect matters may be made more complicated by messages potentially being only contextually legal. It might not be a sufficient condition for safety for a message to be merely structurally well-formed, but rather, it may only be legal depending on some state retained by the compositor which now must be somehow duplicated in the proxy. (For example, does this target have focus? Are we in some particular mode?) The parser and the compositor could become desynchronized at the parsing layer, for example (e.g. malformed messages interpreted differently, possibly leading to different interpretations of framing boundaries, and each interpreting subsequent data in the stream as different messages entirely). They might become desynchronized by having different data models -- a field being added, or possible values changing. For decisions which require acting on state, the proxy must somehow shadow the state of the compositor, and this state must be constructed and mutated in the same way, lest they potentially become desynchronized. If any desynchronization happens at any layer, a message which is determined by the proxy to be safe, may be interpreted by the proxy to mean something which is safe, yet have a different and potentially unsafe effect on the compositor. This is rather similar to the fundamental problems plaguing all so-called "web application firewalls", which have the perilous goal of trying to determine what input might be safe / unsafe to some "too big to be safe" giant ball of complexity behind it. To really know for sure with accuracy would mean a crazy amount of state replication or introspection into how the machine behind the proxy would interpret the data, to the point that the complexity of the analysis in front would exceed the thing it's trying to protect, at which point... what's the point. The best one can hope for is stopping the least-common-denominator attacks using heuristics, which is surely not what one should aim for in this case. From a theoretical perspective, this has analogues in something like the halting problem. From a langsec perspective, Wayland is a weird machine, and a guest's messages to it can be thought of as the "input program". The proxy's objective is then to compute a partial function over the wayland input program to resolve "is this sequence of wayland protocol messages safe?" (rephrased: "does this wayland-lang program terminate?"), which may be undecidable, (though perhaps not in the specific case) depending on the power (complexity class, effective grammar) of the "safe" subset of the instructions exposed by the wayland weird-machine. > Additionally, the proxy would support a plugin interface, > through which the user of the proxy (or their distributor) could > configure custom behaviour. This could be used to prompt the user for > confirmation before allowing a screen capture request, or even to > implement a similar thing for e.g. clipboard access, for which there is > no support in the Wayland protocol. It could even be used to modify > surfaces, to implement things like Qubes-style unspoofable coloured > window borders. > > This approach would allow permissions systems and other custom Wayland > behaviour to be implemented in a compositor-independent manner. > Distributions which suppor tseveral compositors could implement > customisations in a single place, and users of compositors which lack > security features and the assurances memory-safety can provide against > untrusted input would gain access to those things. For the reasons above, I wonder if implementing this as a library providing hardened (memory-safe, etc.) wayland protocol parsers and additional hooks for authorization (ebpf-like?), as a library to be used by compositors (possibly also leveraging some internal privilege separation for the more complex components -- something like [6] comes to mind) might be a preferable approach. [6]: https://github.com/google/sandboxed-api > I'd like to hear feedback here, but I think early in the life of this > idea we should also reach out to the broader Wayland community. I think > there's a lot of potential for this idea beyond Spectrum, and it would > be great if it could be something developed with input from a big > breadth of Wayland users. Completely agree. Others in the broader secure desktops community who may be interested that come to mind: 1. Qubes OS (wayland has been on the to-do list for far too long) 2. OpenXT (similar boat to qubes) 3. Flatpak (separating out permissions besides "whatever your compositor lets you do" seems a logical evolution of their permissions model) 4. Subgraph OS (less dead than it once seemed?) 5. Chromium OS (possibly? idk) 6. Genode (having a general interest in secure GUI architectures -- [7] and much since) 7. wlroots folks 8. mutter/gnome folks (possibly? if the embedding-into-compositor route is taken) [7]: https://genode-labs.com/publications/nitpicker-secure-gui-2005.pdf Cheers, Jean-Philippe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients 2021-05-22 17:13 ` Jean-Philippe Ouellet @ 2021-05-25 11:40 ` Alyssa Ross 0 siblings, 0 replies; 11+ messages in thread From: Alyssa Ross @ 2021-05-25 11:40 UTC (permalink / raw) To: Jean-Philippe Ouellet; +Cc: discuss, Aaron Janse, Puck Meerburg, Thomas Leonard [-- Attachment #1: Type: text/plain, Size: 13290 bytes --] On Sat, May 22, 2021 at 01:13:38PM -0400, Jean-Philippe Ouellet wrote: > Glad to see this taking form! > > First of all, in case the points of technical feedback further down > might be interpreted to suggest otherwise, I *am* in favor of > exploration of this idea. I do believe it to be worthwhile to > implement, just is perhaps not the ultimate nor sole solution one > might want, at least in the form currently conceived. > > On Sat, May 22, 2021 at 9:06 AM Alyssa Ross <hi@alyssa.is> wrote: > > [...] I propose a proxy program that sits between > > Wayland clients and the compositor, in the same privelege domain as the > > compositor. The proxy would decode and re-encode every Wayland request > > (client->compositor message), and would discard any request it didn't > > understand. > > > > This would mitigate the problem of a large, privileged > > program written in a memory-unsafe language being exposed to untrusted > > inputs. > > As attractive as this approach sounds at first, I do not believe it > mitigates the problem in a manner which I would be comfortable placing > a large degree of trust in. > > I see two fundamental weaknesses: > > 1. Opening pandora's box of distributed systems. > > This proposal turns the overall system of policy enforcement from what > is currently a nice single centralized component (the compositor) with > global observation, total visibility, total control, and nice > non-distributed-system guarantees on message ordering, delivery, etc. > into a decentralized and distributed system without those guarantees, > subject to all manner of race conditions, etc. This makes it much > harder to guarantee that intended policies are indeed enforced in the > manner expected. > > There are endless examples from the distributed systems literature of > how this can go wrong, but as a very relevant example from the same > application domain, I would like to bring attention to subtle race > conditions in the implementation of the Qubes clipboard-handling logic > which manifested in QSB #013 [1]. Refer to the linked advisory for > background and details. To summarize with additional context and > considerations as I see them applying here: The way the Qubes GUI > stack works is somewhat similar to what you describe, with two parts, > a "vmside" "agent" [2] (in the untrusted VM whose contents are to be > displayed) and an "xside" "daemon" [3] (in the semi-trusted GUI VM > running the window manager, traditionally dom0). The "vmside" > (gui-agent) implements a minimal X window manager, analogous to > sommelier [4], whereas the "xside" (so-called gui-daemon) implements > what is effectively analogous to the proxy you propose here living on > the compositor-side of the VM trust boundary. For each VM, a separate > vm-side gui-agent and x-side gui-daemon pair is created. A (possibly > outdated) version of the overall scheme and protocol is documented > here [5]. Things like safe clipboard handling is implemented via these > X11 proxies. Where things get a little... difficult... is the fact > that we do not have a single trusted arbiter with global visibility > and synchronous ordering guarantees, but rather a bunch of these GUI > daemon processes (which I posit should be viewed as a distributed > system) which must somehow successfully coordinate and synchronize to > enforce security guarantees. This is hard, and in the case of QSB > #013, corner cases were overlooked wherein an adversary could cause > states to be reached which violate user expectations in unsafe ways. > In hindsight, the fact that something was overlooked should not be a > surprising result, given the difficulty of the nature of the problem, > and that no formal methods had been applied (at the time of the > advisory) to attempt to verify the implementation. > > [1]: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt > [2]: https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/gui-agent/vmside.c > [3]: https://github.com/QubesOS/qubes-gui-daemon/blob/master/gui-daemon/xside.c > [4]: https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/vm_tools/sommelier/README.md > > I see a couple ways to address weakness 1: > > a) exhaustively enumerate what interactions between these proxies > carry security concerns, formalize the security properties of the > protocols involved, and attempt to somehow verify that the > implementations correctly follow the protocols (I propose this mostly > as a straw man to illustrate the comparative apparent simplicity of > the following approach, though, again, I do not wish to discourage > anyone who might wish to try anyway -- for example I very much > appreciate [5], but we'd still need a bunch more work like it to have > meaningful coverage of the higher-level protocols like the clipboard > handling (which exists on top of the gui protocol, which might also > need a parallel model of the window manager for certain properties), > and then once completed initially, it still requires uncommon skill > sets to maintain in sync as the software it models evolves) > > [5]: https://roscidus.com/blog/blog/2019/01/01/using-tla-plus-to-understand-xen-vchan/ > > b) avoid the class of distributed systems issues altogether, by > avoiding ay need to coordinate among proxies, by instead embedding the > relevant decision logic at a single point which already has total > ordering and global visibility, such as within the logical boundary of > the compositor (note "logical boundary" -- which needn't necessarily > mean "within the a single memory-unsafe monolith with guest-reachable > attack surface" -- there's likely a middle ground of compositor > disaggregation and privilege separation which does not also turn > authorization logic into a distributed system) > > This point alone is not an argument against having a safer parser in > front, but rather suggests that a proxy seems unlikely to be the best > place for authorization logic, especially when said proxies need to > coordinate, and rather that such logic seems better suited for being > embedded within the compositor. Did you interpret my proposal as being about one proxy per client? Just to clarify: I imagine a single proxy, running in front of a single Wayland compositor, that all clients connect to (via Sommelier). I envisage the proxy having a complete view of the world, and presenting that view to the compositor (your next point notwithstanding). One change that would probably make sense to reinforce this is limiting an instance of the proxy to using a single plugin, so that that plugin doesn't have to worry about state that may be tracked anywhere else (except for the compositor). This would still allow users/distributors to provide custom policies without having to patch the proxy or compositor, but would mitigate the issues you've described here. > 2. State-synchronization issues, protocol interpretation differences, > "the WAF problem". > > Introducing a proxy introduces another implementation of a parser, > data model, and any applicable retained state. All of this has various > opportunities to become desynchronized at various layers. > > I suspect matters may be made more complicated by messages potentially > being only contextually legal. It might not be a sufficient condition > for safety for a message to be merely structurally well-formed, but > rather, it may only be legal depending on some state retained by the > compositor which now must be somehow duplicated in the proxy. (For > example, does this target have focus? Are we in some particular mode?) > > The parser and the compositor could become desynchronized at the > parsing layer, for example (e.g. malformed messages interpreted > differently, possibly leading to different interpretations of framing > boundaries, and each interpreting subsequent data in the stream as > different messages entirely). > > They might become desynchronized by having different data models -- a > field being added, or possible values changing. > > For decisions which require acting on state, the proxy must somehow > shadow the state of the compositor, and this state must be constructed > and mutated in the same way, lest they potentially become > desynchronized. > > If any desynchronization happens at any layer, a message which is > determined by the proxy to be safe, may be interpreted by the proxy to > mean something which is safe, yet have a different and potentially > unsafe effect on the compositor. > > This is rather similar to the fundamental problems plaguing all > so-called "web application firewalls", which have the perilous goal of > trying to determine what input might be safe / unsafe to some "too big > to be safe" giant ball of complexity behind it. To really know for > sure with accuracy would mean a crazy amount of state replication or > introspection into how the machine behind the proxy would interpret > the data, to the point that the complexity of the analysis in front > would exceed the thing it's trying to protect, at which point... > what's the point. The best one can hope for is stopping the > least-common-denominator attacks using heuristics, which is surely not > what one should aim for in this case. > > From a theoretical perspective, this has analogues in something like > the halting problem. From a langsec perspective, Wayland is a weird > machine, and a guest's messages to it can be thought of as the "input > program". The proxy's objective is then to compute a partial function > over the wayland input program to resolve "is this sequence of wayland > protocol messages safe?" (rephrased: "does this wayland-lang program > terminate?"), which may be undecidable, (though perhaps not in the > specific case) depending on the power (complexity class, effective > grammar) of the "safe" subset of the instructions exposed by the > wayland weird-machine. > > > Additionally, the proxy would support a plugin interface, > > through which the user of the proxy (or their distributor) could > > configure custom behaviour. This could be used to prompt the user for > > confirmation before allowing a screen capture request, or even to > > implement a similar thing for e.g. clipboard access, for which there is > > no support in the Wayland protocol. It could even be used to modify > > surfaces, to implement things like Qubes-style unspoofable coloured > > window borders. > > > > This approach would allow permissions systems and other custom Wayland > > behaviour to be implemented in a compositor-independent manner. > > Distributions which suppor tseveral compositors could implement > > customisations in a single place, and users of compositors which lack > > security features and the assurances memory-safety can provide against > > untrusted input would gain access to those things. > > For the reasons above, I wonder if implementing this as a library > providing hardened (memory-safe, etc.) wayland protocol parsers and > additional hooks for authorization (ebpf-like?), as a library to be > used by compositors (possibly also leveraging some internal privilege > separation for the more complex components -- something like [6] comes > to mind) might be a preferable approach. > > [6]: https://github.com/google/sandboxed-api I think pushing for a solution that has to be adopted by compositors isn't really something that Spectrum is in a place to do. The proxy idea was exciting because it required no special support from compositors, and that meant that we wouldn't have to pick a compositor, which I'm not willing to do at this point in Spectrum's life, because of how quickly the Wayland compositor ecosystem is moving. If the proxy won't get us the required level of security (and your WAF parallel here is very convincing) then the right thing to do is probably just wait until things have progressed a bit more, pick a compositor already written in a memory-safe language (anvil[1]?) and implement security features we want from there. An additional downside here is that I worry about the reaction from users when they can't choose to bring the compositor they already like with them to Spectrum. [1]: https://github.com/Smithay/smithay#anvil > > I'd like to hear feedback here, but I think early in the life of this > > idea we should also reach out to the broader Wayland community. I think > > there's a lot of potential for this idea beyond Spectrum, and it would > > be great if it could be something developed with input from a big > > breadth of Wayland users. > > Completely agree. > > Others in the broader secure desktops community who may be interested > that come to mind: > 1. Qubes OS (wayland has been on the to-do list for far too long) > 2. OpenXT (similar boat to qubes) > 3. Flatpak (separating out permissions besides "whatever your > compositor lets you do" seems a logical evolution of their permissions > model) > 4. Subgraph OS (less dead than it once seemed?) > 5. Chromium OS (possibly? idk) > 6. Genode (having a general interest in secure GUI architectures -- > [7] and much since) > 7. wlroots folks > 8. mutter/gnome folks (possibly? if the embedding-into-compositor > route is taken) > > [7]: https://genode-labs.com/publications/nitpicker-secure-gui-2005.pdf > > Cheers, > Jean-Philippe [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients @ 2021-05-22 17:52 Josh DuBois 2021-05-22 20:05 ` Michael Raskin 0 siblings, 1 reply; 11+ messages in thread From: Josh DuBois @ 2021-05-22 17:52 UTC (permalink / raw) To: discuss On May 22, 2021, at 8:05 AM, Alyssa Ross <hi@alyssa.is> wrote: > > One of the benefits that Wayland is supposed to have over X11 is > security. A Wayland application isn't supposed to be able to record the > screen without user permission, for example. But in most compositors, > it can, with no restrictions. <snip> > > To solve these problems, I propose a proxy program that sits between > Wayland clients and the compositor, in the same privelege domain as the > compositor. <snip> > If we can do that, it might be sensible for > it to live at freedesktop.org? I'm not sure how that works. I am curious, if you have time, to hear more on why the approach of a proxy vs picking a compositor and implementing security there. If the problem is that the Wayland community so far has not considered security a priority, it seems that a security proxy may suffer from those same forces. Basically, will it be easier to attract developers or gain widespread adoption of a proxy as opposed to getting buy-in to do security directly in a compositor? You mention writing in a memory safe language and having a compositor neutral solution as technical advantages. Do you think a proxy is a good choice primarily because it can achieve a better technical result, or is the choice of a new component more a matter of difficulty getting community buy-in from a popular compositor and doing security there? How would you weigh the upsides of a new project against the difficulties of getting a new thing off the ground and adopted? (This is really just curiosity on my part and my $0.02 from the outside. You may have already had a lot of discussions about that, or even already tried talking to compositor folk and not gotten traction. Seems worth some explicit consideration.) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Proxying Wayland for untrusted clients 2021-05-22 17:52 Josh DuBois @ 2021-05-22 20:05 ` Michael Raskin 0 siblings, 0 replies; 11+ messages in thread From: Michael Raskin @ 2021-05-22 20:05 UTC (permalink / raw) To: josh, discuss >On May 22, 2021, at 8:05 AM, Alyssa Ross <hi@alyssa.is> wrote: >> >> One of the benefits that Wayland is supposed to have over X11 is >> security. A Wayland application isn't supposed to be able to record the >> screen without user permission, for example. But in most compositors, >> it can, with no restrictions. ><snip> >> >> To solve these problems, I propose a proxy program that sits between >> Wayland clients and the compositor, in the same privelege domain as the >> compositor. ><snip> >> If we can do that, it might be sensible for >> it to live at freedesktop.org? I'm not sure how that works. > >I am curious, if you have time, to hear more on why the approach of a proxy vs picking a compositor and implementing security there. > >If the problem is that the Wayland community so far has not considered security a priority, it seems that a security proxy may suffer from those same forces. Basically, will it be easier to attract developers or gain widespread adoption of a proxy as opposed to getting buy-in to do security directly in a compositor? You mention writing in a memory safe language and having a compositor neutral solution as technical advantages. > >Do you think a proxy is a good choice primarily because it can achieve a better technical result, or is the choice of a new component more a matter of difficulty getting community buy-in from a popular compositor and doing security there? How would you weigh the upsides of a new project against the difficulties of getting a new thing off the ground and adopted? > >(This is really just curiosity on my part and my $0.02 from the outside. You may have already had a lot of discussions about that, or even already tried talking to compositor folk and not gotten traction. Seems worth some explicit consideration.) Most programs do zero things right, especially popular ones. With an effort, you could get one thing right. Two things (like handling graphics hot-reconfiguration and complicated policy filtering) done right in the same program require either heroical effort, or huge resources, or something like that. Of from less jaded and more technical point of view, hijacking a compositor means that you need to make sure changes forced from driver side do not break security side and people could forget. A «I am just a client» proxy could have that nice property that breaking compatibility with it usually comes together with breaking compatibility with Firefox (on server side) or Plasma (on client side); and breaking safety properties it expects also increases the risk of crashes in the mainstream usage, too. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-05-25 11:41 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-22 13:05 Proxying Wayland for untrusted clients Alyssa Ross 2021-05-22 13:45 ` Michael Raskin 2021-05-22 15:08 ` Alyssa Ross 2021-05-22 16:18 ` Michael Raskin 2021-05-22 17:22 ` Alyssa Ross 2021-05-22 18:48 ` Aaron Janse 2021-05-22 20:00 ` Michael Raskin 2021-05-22 17:13 ` Jean-Philippe Ouellet 2021-05-25 11:40 ` Alyssa Ross 2021-05-22 17:52 Josh DuBois 2021-05-22 20:05 ` Michael Raskin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).