Re: Proxying Wayland for security
Hi Carsten, thanks for the detailed reply. Carsten Haitzler writes: > On Tue, 27 Jul 2021 19:29:45 + Alyssa Ross said: > >> Hi! I'm Alyssa and I'm working on Spectrum[1], which is a project >> aiming to create a compartmentalized desktop Linux system, with high >> levels of isolation between applications. >> >> One big issue for us is protecting the system against potentially >> malicious Wayland clients. It's important that a compartmentalized >> application can't read from the clipboard or take a screenshot of the >> whole desktop without user consent. (The latter is possible in >> wlroots compositors with wlr-screencopy.) >> >> So an idea I had was to was to write a proxy program that would sit >> in front of the compositor, and receive connections from clients. If >> a client sent a wl_data_offer::receive, for example, the proxy could >> ask for user confirmation before forwarding that to the compositor. > > The above is intended to be the job of the compositor. I would expect > compositors to implement this. The only decisions to be made is which clients > do they "lock down" and ask questions for (eg like allow copy yes/no) and > which > they do not. The compositor has a socket to the client and can use that to > figure out all about the client that it wants to. > >> I could just implement this stuff in a compositor, but doing it with a >> proxy would mean that a known subset of the protocol could be used >> with any compositor, with appropriate access controls. It would also >> be a reusable component that could be customised to have different >> access control policy depending on the needs of a distributor or user. > > You could - but then the compositor thinks your proxy is the client, not the > actual client. This leads to lots of un-fun like if a compositor uses the > client socket to query what PID and then what executable etc. that is and does > things like shows icons based on the executable found (what desktop file that > maps to) etc. ... If the compositor implements some kind of load balancing of > rendering/updates based on PID. e.g. it may renice the PID of the client based > on if its on a visible virtual desktop or not. I can go on... Hmm, yes, that would be a shame. In general, I saw the proxy as a way to move some policy decisions out of the compositor. It would still technically be possible to do those sorts of things by having the compositor asking the proxy to do it, but that would require buy-in from compositors. It's frustrating that there's no way to implement this sort of thing, which doesn't feel particularly compositor-dependent, without implementing it seperately for every compositor my users might want to use. Especially when it's likely not upstreamable to at least some of them -- e.g. I doubt Sway, which AIUI aims to avoid adding features beyond what's needed for i3 compatibility, would be interested in it. But I understand that that ship has probably sailed, and there's not really anything I can do about it without breaking the expectations of other things in the ecosystem. >> Which brings me to the reason I'm bringing this all up on >> wayland-devel. I'd be grateful for any input about this idea, >> especially: >> >> * Is this a sensible idea? Is there something I haven't considered >>which would make this unworkable, and force me to do a >>compositor-specific implementation instead? > > See above. I can come up with more things that will be problematic. Sure. it > *CAN* be done. In some cases like a "vnc proxy" whose job it is to display > remote clients it deals with over vnc to a local wayland compositor... it's > pretty much necessary. The above socket -> pid -> exe etc. isn't going to be > valid/useful and you can't really do that due to the real client being "off > machine". But for the vast vast majority of cases, they will be real local > clients with real PIDs etc. > >> * Is this something that would be likely to be generally useful, >>outside of our project? Would it make sense as something to >>collaborate on / have as a freedesktop.org project? > > What I think would be of value is a standardized method to decide which > wayland > clients should be locked down and which should not be. This is currently > "undecided". Something a compositor can easily look up given the client socket > and then decide which protocol requests it will handle in which way. Do I understand correctly that you're saying you'd like there to be some sort of oracle, outside of the compositor, that the compositor could ask what restrictions should be applied to a client? >> [1]: https://spectrum-os.org/ signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Carsten Haitzler writes: > On Tue, 27 Jul 2021 19:29:45 + Alyssa Ross said: > >> Hi! I'm Alyssa and I'm working on Spectrum[1], which is a project >> aiming to create a compartmentalized desktop Linux system, with high >> levels of isolation between applications. >> >> One big issue for us is protecting the system against potentially >> malicious Wayland clients. It's important that a compartmentalized >> application can't read from the clipboard or take a screenshot of the >> whole desktop without user consent. (The latter is possible in >> wlroots compositors with wlr-screencopy.) >> >> So an idea I had was to was to write a proxy program that would sit >> in front of the compositor, and receive connections from clients. If >> a client sent a wl_data_offer::receive, for example, the proxy could >> ask for user confirmation before forwarding that to the compositor. > > The above is intended to be the job of the compositor. I would expect > compositors to implement this. The only decisions to be made is which clients > do they "lock down" and ask questions for (eg like allow copy yes/no) and > which > they do not. The compositor has a socket to the client and can use that to > figure out all about the client that it wants to. > >> I could just implement this stuff in a compositor, but doing it with a >> proxy would mean that a known subset of the protocol could be used >> with any compositor, with appropriate access controls. It would also >> be a reusable component that could be customised to have different >> access control policy depending on the needs of a distributor or user. > > You could - but then the compositor thinks your proxy is the client, not the > actual client. This leads to lots of un-fun like if a compositor uses the > client socket to query what PID and then what executable etc. that is and does > things like shows icons based on the executable found (what desktop file that > maps to) etc. ... If the compositor implements some kind of load balancing of > rendering/updates based on PID. e.g. it may renice the PID of the client based > on if its on a visible virtual desktop or not. I can go on... > >> Which brings me to the reason I'm bringing this all up on >> wayland-devel. I'd be grateful for any input about this idea, >> especially: >> >> * Is this a sensible idea? Is there something I haven't considered >>which would make this unworkable, and force me to do a >>compositor-specific implementation instead? > > See above. I can come up with more things that will be problematic. Sure. it > *CAN* be done. In some cases like a "vnc proxy" whose job it is to display > remote clients it deals with over vnc to a local wayland compositor... it's > pretty much necessary. The above socket -> pid -> exe etc. isn't going to be > valid/useful and you can't really do that due to the real client being "off > machine". But for the vast vast majority of cases, they will be real local > clients with real PIDs etc. A further thought I've just had -- the pid lookup is generally done through libwayland-server's wl_client_get_credentials(), right? So if libwayland-server could be taught about the proxy, and the proxy could communicate the pid/uid/gid to libwayland-server somehow, that could make this possible after all, right? (Assuming that the small amount of extra complexity in libwayland-server was judged to be worth it to allow this degree of compositor-independent add-on functionality, of course.) signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wednesday, July 28th, 2021 at 11:17, Alyssa Ross wrote: > A further thought I've just had -- the pid lookup is generally done > through libwayland-server's wl_client_get_credentials(), right? So if > libwayland-server could be taught about the proxy, and the proxy could > communicate the pid/uid/gid to libwayland-server somehow, that could > make this possible after all, right? I'm not sure a proxy is a good idea, because proxying Wayland protocols isn't straightforward and introduces latency. That said, allowing sandboxes to feed back security context metadata to the compositor is something I believe would be useful in many scenarios. Maybe have a look at [1]? [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 09:08:03 + Alyssa Ross said: > Hi Carsten, thanks for the detailed reply. > > Carsten Haitzler writes: > > > On Tue, 27 Jul 2021 19:29:45 + Alyssa Ross said: > > > >> Hi! I'm Alyssa and I'm working on Spectrum[1], which is a project > >> aiming to create a compartmentalized desktop Linux system, with high > >> levels of isolation between applications. > >> > >> One big issue for us is protecting the system against potentially > >> malicious Wayland clients. It's important that a compartmentalized > >> application can't read from the clipboard or take a screenshot of the > >> whole desktop without user consent. (The latter is possible in > >> wlroots compositors with wlr-screencopy.) > >> > >> So an idea I had was to was to write a proxy program that would sit > >> in front of the compositor, and receive connections from clients. If > >> a client sent a wl_data_offer::receive, for example, the proxy could > >> ask for user confirmation before forwarding that to the compositor. > > > > The above is intended to be the job of the compositor. I would expect > > compositors to implement this. The only decisions to be made is which > > clients do they "lock down" and ask questions for (eg like allow copy > > yes/no) and which they do not. The compositor has a socket to the client > > and can use that to figure out all about the client that it wants to. > > > >> I could just implement this stuff in a compositor, but doing it with a > >> proxy would mean that a known subset of the protocol could be used > >> with any compositor, with appropriate access controls. It would also > >> be a reusable component that could be customised to have different > >> access control policy depending on the needs of a distributor or user. > > > > You could - but then the compositor thinks your proxy is the client, not the > > actual client. This leads to lots of un-fun like if a compositor uses the > > client socket to query what PID and then what executable etc. that is and > > does things like shows icons based on the executable found (what desktop > > file that maps to) etc. ... If the compositor implements some kind of load > > balancing of rendering/updates based on PID. e.g. it may renice the PID of > > the client based on if its on a visible virtual desktop or not. I can go > > on... > > Hmm, yes, that would be a shame. In general, I saw the proxy as a way > to move some policy decisions out of the compositor. It would still > technically be possible to do those sorts of things by having the > compositor asking the proxy to do it, but that would require buy-in from > compositors. > > It's frustrating that there's no way to implement this sort of thing, > which doesn't feel particularly compositor-dependent, without > implementing it seperately for every compositor my users might want to > use. Especially when it's likely not upstreamable to at least some of > them -- e.g. I doubt Sway, which AIUI aims to avoid adding features > beyond what's needed for i3 compatibility, would be interested in it. > But I understand that that ship has probably sailed, and there's not > really anything I can do about it without breaking the expectations of > other things in the ecosystem. > > >> Which brings me to the reason I'm bringing this all up on > >> wayland-devel. I'd be grateful for any input about this idea, > >> especially: > >> > >> * Is this a sensible idea? Is there something I haven't considered > >>which would make this unworkable, and force me to do a > >>compositor-specific implementation instead? > > > > See above. I can come up with more things that will be problematic. Sure. it > > *CAN* be done. In some cases like a "vnc proxy" whose job it is to display > > remote clients it deals with over vnc to a local wayland compositor... it's > > pretty much necessary. The above socket -> pid -> exe etc. isn't going to be > > valid/useful and you can't really do that due to the real client being "off > > machine". But for the vast vast majority of cases, they will be real local > > clients with real PIDs etc. > > > >> * Is this something that would be likely to be generally useful, > >>outside of our project? Would it make sense as something to > >>collaborate on / have as a freedesktop.org project? > > > > What I think would be of value is a standardized method to decide which > > wayland clients should be locked down and which should not be. This is > > currently "undecided". Something a compositor can easily look up given the > > client socket and then decide which protocol requests it will handle in > > which way. > > Do I understand correctly that you're saying you'd like there to be some > sort of oracle, outside of the compositor, that the compositor could ask > what restrictions should be applied to a client? Yes. or more specifically I'd like it to be as simple and basic as possible. E.g. a file in /etc/wayland/security/securityinfo.cfg - imagine this
Re: Proxying Wayland for security
Please read the (lengthy) discussion at [1]. [1]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206 In particular, the "get_credentials → PID → executable path" lookup is racy. PID re-use allows a malicious process to be recognized as another executable. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 09:51:53 + Simon Ser said: > Please read the (lengthy) discussion at [1]. > > [1]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206 > > In particular, the "get_credentials → PID → executable path" lookup is > racy. PID re-use allows a malicious process to be recognized as another > executable. That is true - but only at cusp points - e.g. PID has exited, but socket has not been detected as dead yet and PID was recycled. I you do the lookup then, it'd be a problem. If you do the lookup first on initial connect, then ensure you do at least one round-trip to client (send something, it sends back a reply), then that lookup would be valid (and continue to be valid for the duration of that connection) because the PID lookup is sandwiched between a connect and an active round-trip (thus the socket didn't die with the process). The round trip does need to be some kind of ping that the compositor sends some UUID it generates with random content and the reply is a pong with that UUID back - thus it can't be spoofed. Indeed using systemd to get cgroup info from a client fd is also possible. The point does remain that adding a proxy in becomes problematic. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Simon Ser writes: > On Wednesday, July 28th, 2021 at 11:17, Alyssa Ross wrote: > >> A further thought I've just had -- the pid lookup is generally done >> through libwayland-server's wl_client_get_credentials(), right? So if >> libwayland-server could be taught about the proxy, and the proxy could >> communicate the pid/uid/gid to libwayland-server somehow, that could >> make this possible after all, right? > > I'm not sure a proxy is a good idea, because proxying Wayland protocols > isn't straightforward and introduces latency. > > That said, allowing sandboxes to feed back security context metadata to > the compositor is something I believe would be useful in many scenarios. > Maybe have a look at [1]? > > [1]: > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68 Thanks for the link! That looks very useful indeed. I've read through that and the Weston discussion it links to. We're using Virtio Wayland from Chromium OS, and I think it would be very straightforward to implement security context protocol in that. Dynamic permissions are important to us, so if I'm understanding correctly, with this model the compositor would be responsible for asking the user before taking an action in response to a client request, yes? And that would have to be implemented per compositor? (But there's definitely value to static policy as well, if only so that dynamic requests don't have to be repeated for every use of e.g. a screenshot app, and the compositor doesn't have to somehow persist them.) signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Carsten Haitzler writes: > On Wed, 28 Jul 2021 09:51:53 + Simon Ser said: > >> Please read the (lengthy) discussion at [1]. >> >> [1]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206 >> >> In particular, the "get_credentials → PID → executable path" lookup is >> racy. PID re-use allows a malicious process to be recognized as another >> executable. > > That is true - but only at cusp points - e.g. PID has exited, but socket has > not been detected as dead yet and PID was recycled. I you do the lookup then, > it'd be a problem. > > If you do the lookup first on initial connect, then ensure you do at least one > round-trip to client (send something, it sends back a reply), then that lookup > would be valid (and continue to be valid for the duration of that connection) > because the PID lookup is sandwiched between a connect and an active > round-trip > (thus the socket didn't die with the process). The round trip does need to be > some kind of ping that the compositor sends some UUID it generates with random > content and the reply is a pong with that UUID back - thus it can't be > spoofed. Hmm, I'm having trouble squaring this with Simon's proof of concept attack[1]. In particular, as that PoC demonstrates, there's guarantee that the socket will die when the process does, right? (Because the fd could be shared with other processes.) > Indeed using systemd to get cgroup info from a client fd is also possible. The > point does remain that adding a proxy in becomes problematic. [1]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206#note_176699 signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Hi Alyssa, On Tue, 27 Jul 2021 at 20:30, Alyssa Ross wrote: > Hi! I'm Alyssa and I'm working on Spectrum[1], which is a project > aiming to create a compartmentalized desktop Linux system, with high > levels of isolation between applications. I've seen, it's neat! > One big issue for us is protecting the system against potentially > malicious Wayland clients. It's important that a compartmentalized > application can't read from the clipboard or take a screenshot of the > whole desktop without user consent. (The latter is possible in > wlroots compositors with wlr-screencopy.) > > So an idea I had was to was to write a proxy program that would sit > in front of the compositor, and receive connections from clients. If > a client sent a wl_data_offer::receive, for example, the proxy could > ask for user confirmation before forwarding that to the compositor. As you've noted, the core protocol doesn't offer any way to scrape these contents without additional extension protocols, which are not implemented by all compositors. Generally speaking, GNOME's Mutter and Weston tend not to implement these protocols, and wlroots-based compositors tend to implement them. > I could just implement this stuff in a compositor, but doing it with a > proxy would mean that a known subset of the protocol could be used > with any compositor, with appropriate access controls. It would also > be a reusable component that could be customised to have different > access control policy depending on the needs of a distributor or user. I think you'd be better off dealing with the problem at source. libwayland-server already has a 'global filter' mechanism which allows an arbitrary hook to decide which clients can and cannot see which interfaces. This is used to advertise private protocols to trusted clients: for example, Weston's UI and screenshot support are handled by external clients, but we use the filter to ensure that _only_ those clients can access those protocols, not arbitrary clients. Implementing a proxy just shifts this problem rather than solving it once; every time someone adds a new protocol, you have to plumb it through the proxy and add some kind of policy mechanism. But the compositors themselves probably have their own policy mechanism, so why not just reuse that? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Carsten Haitzler writes: >> > What I think would be of value is a standardized method to decide which >> > wayland clients should be locked down and which should not be. This is >> > currently "undecided". Something a compositor can easily look up given the >> > client socket and then decide which protocol requests it will handle in >> > which way. >> >> Do I understand correctly that you're saying you'd like there to be some >> sort of oracle, outside of the compositor, that the compositor could ask >> what restrictions should be applied to a client? > > Yes. or more specifically I'd like it to be as simple and basic as possible. > E.g. a file in /etc/wayland/security/securityinfo.cfg - imagine this is a .ini > file format much like .desktop files so we can re-use parsers that most things > have to eventually implement (how do you display sensible application info > e.g. > while alt-tab switching and icons for apps without doing some kind of .desktop > file handling at some point? You can choose to never do this but then you may > then not bother with more security either). > > Imagine there are 1 or more files that perhaps describe black or white lists > in > a fairly simple way that allow the compositor to limit functions. > > Personally, if I was going to lock security down 9have not gotten there yet - > have other things to do before then). I'd be happy to support something like > the above, but before that I'd do some of the following: > > 1 query UID/GID of the remote client. If it's not UID 0 and not UID of user > running the compositor, auto-lock-down anything like copy & paste (eg behind > such "are you sure" dialogs). We already do not support the screenshot > protocol > as it can be abused .. and the compositor has it's own ability to do > screenshots and save them out to disk anyway. If we did support it, then it'd > also do a "are you sure" thing too if UID/GID are not approved. I'd consider > adding extensions to query SMACK label too if that was more widely used (or > accept patches). > > 2. I'd also then after this add a custom "for my compositor only" white and > black list of executable paths (probably a simple text file with a list of > file > globs per line like: > > deny /usr/bin/firefox > deny /usr/bin/zoom > allow /bin/screenshoot-tool > allow /usr/bin/* > allow /usr/local/bin/* > deny /* > > So simple walk the list from top to bottom finding first rule that matches. > this is simple allow/deny but could make these custom rules like: > > rule allow=cnp,screenshot > rule deny= > rule allow-cnp=cnp > > Then use allow-cnp to allow clients to just do cnp. Of course this would just > be me - but it's simple to maintain and reason about and flexible enough to do > what is needed. Would have this file per user for sure (e.g. > ~/.config/mycompositor/security/rules.cfg). The user local file parsed first > for > allow/deny rules then parse the system file for a master list for the whole > system). Yes - it is coarse and only allows approval based on fill file paths. > Yes - a binary could be written to /tmp/ or $HOME/ then deleted or renamed > (vector of attack) which is why I'd have the last rule be a deny /* > (everything) unless explicitly allowed and only explicitly allow known good > directories of tools which have other system controls to limit abuse (writing > of trojans there -= eg /usr/bin will be limited to root to write to). > > I am sure you spend far more time on all of this than I do and are more aware > of the problem space, so I think you are much better positioned to create > standards that are both simple to implement and powerful and secure. If all > compositors agreed on the same ruleset to load and even used the same simple > small security library to do this (e.g. you make a small lib that can be given > a socket fd and then return a list of allowed actions - eg cnp,screenshot, > ...) > this would go a long way to perhaps having a standard everyone agrees on and > is minimal effort to implement. This sort of thing sounds good to me, especially paired with Simon's secure context proposal[1]. I think it would be important to have it be a little more complex than an allow/deny file, because it would be good to give the user the ability to grant one-off permissions. But from the compositor's perspective, it wouldn't really matter how the library came to its determination. And users could switch between compatible compositors while using the same authorization system. The library could, for example, put up a graphical dialog asking the user what to do. Actually, is this starting to sound a lot like polkit? I don't know a lot about polkit, but maybe I should start looking into whether there could be an integration there. > As per your example - if some compositors choose not to do this, then they > would be less "secure" and users should be aware of this. That's up to them > and > the compositor developers to deal with. > > You get where I'm coming from. :
Re: Proxying Wayland for security
On Wednesday, July 28th, 2021 at 12:30, Carsten Haitzler wrote: > On Wed, 28 Jul 2021 09:51:53 + Simon Ser cont...@emersion.fr said: > > > Please read the (lengthy) discussion at 1. > > In particular, the "get_credentials → PID → executable path" lookup is > > racy. PID re-use allows a malicious process to be recognized as another > > executable. > > That is true - but only at cusp points - e.g. PID has exited, but socket has > not been detected as dead yet and PID was recycled. I you do the lookup then, > it'd be a problem. > > If you do the lookup first on initial connect, then ensure you do at least one > round-trip to client (send something, it sends back a reply), then that lookup > would be valid Nope. The PID returned by libwayland is the one that bound the socket. So if you create the socket, fork, bind it in the child, exit the child, then on the compositor side you'll see a socket which belongs to a PID which no longer exists. Wait until a privileged client re-uses that PID, and boom. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Daniel Stone writes: >> One big issue for us is protecting the system against potentially >> malicious Wayland clients. It's important that a compartmentalized >> application can't read from the clipboard or take a screenshot of the >> whole desktop without user consent. (The latter is possible in >> wlroots compositors with wlr-screencopy.) >> >> So an idea I had was to was to write a proxy program that would sit >> in front of the compositor, and receive connections from clients. If >> a client sent a wl_data_offer::receive, for example, the proxy could >> ask for user confirmation before forwarding that to the compositor. > > As you've noted, the core protocol doesn't offer any way to scrape > these contents without additional extension protocols, which are not > implemented by all compositors. Generally speaking, GNOME's Mutter and > Weston tend not to implement these protocols, and wlroots-based > compositors tend to implement them. That's true for screenshots, but it's not true for clipboard contents, right? As I understand it, any application can paste, with the only restriction being that it has to be in the foreground at the time, and wl-clipboard[1] seems to demonstrate that it's possible to fulfill that requirement without being visible to the user at all. [1]: https://github.com/bugaevc/wl-clipboard/ >> I could just implement this stuff in a compositor, but doing it with a >> proxy would mean that a known subset of the protocol could be used >> with any compositor, with appropriate access controls. It would also >> be a reusable component that could be customised to have different >> access control policy depending on the needs of a distributor or user. > > I think you'd be better off dealing with the problem at source. > libwayland-server already has a 'global filter' mechanism which allows > an arbitrary hook to decide which clients can and cannot see which > interfaces. This is used to advertise private protocols to trusted > clients: for example, Weston's UI and screenshot support are handled > by external clients, but we use the filter to ensure that _only_ those > clients can access those protocols, not arbitrary clients. > > Implementing a proxy just shifts this problem rather than solving it > once; every time someone adds a new protocol, you have to plumb it > through the proxy and add some kind of policy mechanism. But the > compositors themselves probably have their own policy mechanism, so > why not just reuse that? Because that requires work for every compositor, whereas a proxy would have allowed it to be done just once, and then to work with all compositors. But Carsten's mail convinced me that a proxy is indeed probably not a good idea, and I should instead pursue integrating these existing policy mechanisms with some sort of compositor-independent policy decision maker. > Cheers, > Daniel signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wednesday 2021-07-28 12:30, Carsten Haitzler wrote: > >> Please read the (lengthy) discussion at [1]. >> >> [1]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206 >> >> In particular, the "get_credentials → PID → executable path" lookup is >> racy. PID re-use allows a malicious process to be recognized as another >> executable. > >That is true - but only at cusp points - e.g. PID has exited, but socket has >not been detected as dead yet and PID was recycled. I you do the lookup then, >it'd be a problem. Only at cusp points? What if you pass the fd from P1 to P2 via the AF_LOCAL peercred mechanism (thus keeping it alive), have P1 exit, then spawn P3 with a PID suitable for the attack. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, Jul 28, 2021 at 11:06:43AM +, Alyssa Ross wrote: > Daniel Stone writes: > > >> One big issue for us is protecting the system against potentially > >> malicious Wayland clients. It's important that a compartmentalized > >> application can't read from the clipboard or take a screenshot of the > >> whole desktop without user consent. (The latter is possible in > >> wlroots compositors with wlr-screencopy.) > >> > >> So an idea I had was to was to write a proxy program that would sit > >> in front of the compositor, and receive connections from clients. If > >> a client sent a wl_data_offer::receive, for example, the proxy could > >> ask for user confirmation before forwarding that to the compositor. > > > > As you've noted, the core protocol doesn't offer any way to scrape > > these contents without additional extension protocols, which are not > > implemented by all compositors. Generally speaking, GNOME's Mutter and > > Weston tend not to implement these protocols, and wlroots-based > > compositors tend to implement them. > > That's true for screenshots, but it's not true for clipboard contents, > right? As I understand it, any application can paste, with the only > restriction being that it has to be in the foreground at the time, and > wl-clipboard[1] seems to demonstrate that it's possible to fulfill that > requirement without being visible to the user at all. Getting things from the clipboard is generally supposed to require an interaction of some sort, e.g. a button press, key press, touch down, etc, but it might be not properly implemented here and there. wl-clipboard relies on this not being done good enough, and will eventally stop working, unless there exist some global state like clipboard manager protocol that bypasses any content restrictions that wl_data_device and friends apply. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Jonas Ådahl writes: > On Wed, Jul 28, 2021 at 11:06:43AM +, Alyssa Ross wrote: >> Daniel Stone writes: >> >> >> One big issue for us is protecting the system against potentially >> >> malicious Wayland clients. It's important that a compartmentalized >> >> application can't read from the clipboard or take a screenshot of the >> >> whole desktop without user consent. (The latter is possible in >> >> wlroots compositors with wlr-screencopy.) >> >> >> >> So an idea I had was to was to write a proxy program that would sit >> >> in front of the compositor, and receive connections from clients. If >> >> a client sent a wl_data_offer::receive, for example, the proxy could >> >> ask for user confirmation before forwarding that to the compositor. >> > >> > As you've noted, the core protocol doesn't offer any way to scrape >> > these contents without additional extension protocols, which are not >> > implemented by all compositors. Generally speaking, GNOME's Mutter and >> > Weston tend not to implement these protocols, and wlroots-based >> > compositors tend to implement them. >> >> That's true for screenshots, but it's not true for clipboard contents, >> right? As I understand it, any application can paste, with the only >> restriction being that it has to be in the foreground at the time, and >> wl-clipboard[1] seems to demonstrate that it's possible to fulfill that >> requirement without being visible to the user at all. > > Getting things from the clipboard is generally supposed to require an > interaction of some sort, e.g. a button press, key press, touch down, > etc, but it might be not properly implemented here and there. > wl-clipboard relies on this not being done good enough, and will > eventally stop working, unless there exist some global state like > clipboard manager protocol that bypasses any content restrictions that > wl_data_device and friends apply. That's good to know, but even so, there's no way for the compositor to know that the interaction corresponds to a user intent to paste. So an application could still abuse a mouseover, or just some unrelated typing in its window, to read the clipboard contents when the user wasn't expecting it to. signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wednesday, July 28th, 2021 at 13:06, Alyssa Ross wrote: > That's true for screenshots, but it's not true for clipboard contents, > right? As I understand it, any application can paste, with the only > restriction being that it has to be in the foreground at the time, and > wl-clipboard[1] seems to demonstrate that it's possible to fulfill that > requirement without being visible to the user at all. wl-clipboard can do so because nowadays' compositors will give focus to new toplevels. That said: - Some compositors (e.g. Sway) can be configured to not give focus to new toplevels. Comes with a usability trade-off, so it's not the default. - In the future, compositors should be able to require a valid xdg-activation token before giving focus to a new toplevel. If most Wayland clients adopt xdg-activation, this could be made the default without too much of a usability concern. Note, it's difficult to detect whether a buffer is completely or mostly transparent. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wednesday, July 28th, 2021 at 15:36, Alyssa Ross wrote: > That's good to know, but even so, there's no way for the compositor to > know that the interaction corresponds to a user intent to paste. So an > application could still abuse a mouseover, or just some unrelated typing > in its window, to read the clipboard contents when the user wasn't > expecting it to. A mouse-over shouldn't be enough. Typing events shouldn't be relayed to the malicious client if it doesn't have focus. So the user would really need to manually give focus to the malicious client for it to be able to read the clipboard. Yes, a wide transparent window can fool the user into doing this. Compositor-side toplevel decorations can mitigate this a bit. Also clicks captured by the malicious client won't go through so the user _should_ notice. I agree it's still not that great, but compositors can implement more checks as they see fit, and we're not 50% of the way there anyways. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 11:06:43 + Alyssa Ross wrote: > Daniel Stone writes: > > >> One big issue for us is protecting the system against potentially > >> malicious Wayland clients. It's important that a compartmentalized > >> application can't read from the clipboard or take a screenshot of the > >> whole desktop without user consent. (The latter is possible in > >> wlroots compositors with wlr-screencopy.) > >> > >> So an idea I had was to was to write a proxy program that would sit > >> in front of the compositor, and receive connections from clients. If > >> a client sent a wl_data_offer::receive, for example, the proxy could > >> ask for user confirmation before forwarding that to the compositor. > > > > As you've noted, the core protocol doesn't offer any way to scrape > > these contents without additional extension protocols, which are not > > implemented by all compositors. Generally speaking, GNOME's Mutter and > > Weston tend not to implement these protocols, and wlroots-based > > compositors tend to implement them. > > That's true for screenshots, but it's not true for clipboard contents, > right? As I understand it, any application can paste, with the only > restriction being that it has to be in the foreground at the time, and > wl-clipboard[1] seems to demonstrate that it's possible to fulfill that > requirement without being visible to the user at all. > > [1]: https://github.com/bugaevc/wl-clipboard/ Hi, I believe wl-clipboard only works, because we suck at implementing what we intended in compositors. Once compositors get fixed to correctly track and check input event serials, pasting will not be possible without the client in question getting an explicit input event. Furthermore, as sending input events from Wayland clients is generally not possible, the input must come from a source the compositor trusts - mostly likely from the human user. You can't get input events with legit serials without a visible window. Merely getting window (keyboard) focus should not be enough, there needs to be a proper input event like button, key or touch down. Pointer motion does not count either, nor do keys already down when gaining keyboard focus. I don't recall what the story for setting clipboard contents is. > >> I could just implement this stuff in a compositor, but doing it with a > >> proxy would mean that a known subset of the protocol could be used > >> with any compositor, with appropriate access controls. It would also > >> be a reusable component that could be customised to have different > >> access control policy depending on the needs of a distributor or user. > > > > I think you'd be better off dealing with the problem at source. > > libwayland-server already has a 'global filter' mechanism which allows > > an arbitrary hook to decide which clients can and cannot see which > > interfaces. This is used to advertise private protocols to trusted > > clients: for example, Weston's UI and screenshot support are handled > > by external clients, but we use the filter to ensure that _only_ those > > clients can access those protocols, not arbitrary clients. Btw. Weston doesn't actually use wl_display_set_global_filter(). Weston creates an authorized Wayland connection and then forks the trusted helper process giving the client end of the connection to the new process. Unauthorized clients do see the privileged interfaces, but if they try to bind, Weston disconnects them. > > > > Implementing a proxy just shifts this problem rather than solving it > > once; every time someone adds a new protocol, you have to plumb it > > through the proxy and add some kind of policy mechanism. But the > > compositors themselves probably have their own policy mechanism, so > > why not just reuse that? > > Because that requires work for every compositor, whereas a proxy would > have allowed it to be done just once, and then to work with all > compositors. But Carsten's mail convinced me that a proxy is indeed > probably not a good idea, and I should instead pursue integrating these > existing policy mechanisms with some sort of compositor-independent > policy decision maker. Did you check https://github.com/mupuf/libwsm ? That was linked from the Weston issue. I don't know if it applies, and as you can see, it never took off and has been dormant for years. Thanks, pq pgp8HnWfkyzyp.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, Jul 28, 2021 at 01:36:54PM +, Alyssa Ross wrote: > Jonas Ådahl writes: > > > On Wed, Jul 28, 2021 at 11:06:43AM +, Alyssa Ross wrote: > >> Daniel Stone writes: > >> > >> >> One big issue for us is protecting the system against potentially > >> >> malicious Wayland clients. It's important that a compartmentalized > >> >> application can't read from the clipboard or take a screenshot of the > >> >> whole desktop without user consent. (The latter is possible in > >> >> wlroots compositors with wlr-screencopy.) > >> >> > >> >> So an idea I had was to was to write a proxy program that would sit > >> >> in front of the compositor, and receive connections from clients. If > >> >> a client sent a wl_data_offer::receive, for example, the proxy could > >> >> ask for user confirmation before forwarding that to the compositor. > >> > > >> > As you've noted, the core protocol doesn't offer any way to scrape > >> > these contents without additional extension protocols, which are not > >> > implemented by all compositors. Generally speaking, GNOME's Mutter and > >> > Weston tend not to implement these protocols, and wlroots-based > >> > compositors tend to implement them. > >> > >> That's true for screenshots, but it's not true for clipboard contents, > >> right? As I understand it, any application can paste, with the only > >> restriction being that it has to be in the foreground at the time, and > >> wl-clipboard[1] seems to demonstrate that it's possible to fulfill that > >> requirement without being visible to the user at all. > > > > Getting things from the clipboard is generally supposed to require an > > interaction of some sort, e.g. a button press, key press, touch down, > > etc, but it might be not properly implemented here and there. > > wl-clipboard relies on this not being done good enough, and will > > eventally stop working, unless there exist some global state like > > clipboard manager protocol that bypasses any content restrictions that > > wl_data_device and friends apply. > > That's good to know, but even so, there's no way for the compositor to > know that the interaction corresponds to a user intent to paste. So an > application could still abuse a mouseover, or just some unrelated typing > in its window, to read the clipboard contents when the user wasn't > expecting it to. That is indeed not possible, and likely very hard to get right. E.g. a simple click or arbitrary key press might mean intent to paste, e.g. press a "Paste" button. It's far from only related to Ctrl+V. Only solution I see is only allow clipboard for sandboxed clients, and explicitly grant access on a per application basis via some dialog querying the user, similar to how audio/camera/... is granted in Flatpak. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Pekka Paalanen writes: > On Wed, 28 Jul 2021 11:06:43 + > Alyssa Ross wrote: > >> Daniel Stone writes: >> >> >> One big issue for us is protecting the system against potentially >> >> malicious Wayland clients. It's important that a compartmentalized >> >> application can't read from the clipboard or take a screenshot of the >> >> whole desktop without user consent. (The latter is possible in >> >> wlroots compositors with wlr-screencopy.) >> >> >> >> So an idea I had was to was to write a proxy program that would sit >> >> in front of the compositor, and receive connections from clients. If >> >> a client sent a wl_data_offer::receive, for example, the proxy could >> >> ask for user confirmation before forwarding that to the compositor. >> > >> > As you've noted, the core protocol doesn't offer any way to scrape >> > these contents without additional extension protocols, which are not >> > implemented by all compositors. Generally speaking, GNOME's Mutter and >> > Weston tend not to implement these protocols, and wlroots-based >> > compositors tend to implement them. >> >> That's true for screenshots, but it's not true for clipboard contents, >> right? As I understand it, any application can paste, with the only >> restriction being that it has to be in the foreground at the time, and >> wl-clipboard[1] seems to demonstrate that it's possible to fulfill that >> requirement without being visible to the user at all. >> >> [1]: https://github.com/bugaevc/wl-clipboard/ > > Hi, > > I believe wl-clipboard only works, because we suck at implementing what > we intended in compositors. Once compositors get fixed to correctly > track and check input event serials, pasting will not be possible > without the client in question getting an explicit input event. > Furthermore, as sending input events from Wayland clients is generally > not possible, the input must come from a source the compositor trusts - > mostly likely from the human user. > > You can't get input events with legit serials without a visible window. > > Merely getting window (keyboard) focus should not be enough, there > needs to be a proper input event like button, key or touch down. > Pointer motion does not count either, nor do keys already down when > gaining keyboard focus. > > I don't recall what the story for setting clipboard contents is. Thank you for the correction. Tt's still the case, though, that even with a strict implementation, interacting with an application through a mouse click or keyboard input would give it access to clipboard contents. That's not at all obvious to users, and I don't think it's something I could justify in a security-focused system, so I do still need to do something about it. >> >> I could just implement this stuff in a compositor, but doing it with a >> >> proxy would mean that a known subset of the protocol could be used >> >> with any compositor, with appropriate access controls. It would also >> >> be a reusable component that could be customised to have different >> >> access control policy depending on the needs of a distributor or user. >> > >> > I think you'd be better off dealing with the problem at source. >> > libwayland-server already has a 'global filter' mechanism which allows >> > an arbitrary hook to decide which clients can and cannot see which >> > interfaces. This is used to advertise private protocols to trusted >> > clients: for example, Weston's UI and screenshot support are handled >> > by external clients, but we use the filter to ensure that _only_ those >> > clients can access those protocols, not arbitrary clients. > > Btw. Weston doesn't actually use wl_display_set_global_filter(). Weston > creates an authorized Wayland connection and then forks the trusted > helper process giving the client end of the connection to the new > process. Unauthorized clients do see the privileged interfaces, but if > they try to bind, Weston disconnects them. > >> > >> > Implementing a proxy just shifts this problem rather than solving it >> > once; every time someone adds a new protocol, you have to plumb it >> > through the proxy and add some kind of policy mechanism. But the >> > compositors themselves probably have their own policy mechanism, so >> > why not just reuse that? >> >> Because that requires work for every compositor, whereas a proxy would >> have allowed it to be done just once, and then to work with all >> compositors. But Carsten's mail convinced me that a proxy is indeed >> probably not a good idea, and I should instead pursue integrating these >> existing policy mechanisms with some sort of compositor-independent >> policy decision maker. > > Did you check > https://github.com/mupuf/libwsm ? > > That was linked from the Weston issue. I don't know if it applies, and > as you can see, it never took off and has been dormant for years. I only just saw it -- thanks for bringing it to my attention. It looks like it could do the job, but it also looks like it wo
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 11:05:11 + Simon Ser said: > On Wednesday, July 28th, 2021 at 12:30, Carsten Haitzler > wrote: > > > On Wed, 28 Jul 2021 09:51:53 + Simon Ser cont...@emersion.fr said: > > > > > Please read the (lengthy) discussion at 1. > > > In particular, the "get_credentials → PID → executable path" lookup is > > > racy. PID re-use allows a malicious process to be recognized as another > > > executable. > > > > That is true - but only at cusp points - e.g. PID has exited, but socket has > > not been detected as dead yet and PID was recycled. I you do the lookup > > then, it'd be a problem. > > > > If you do the lookup first on initial connect, then ensure you do at least > > one round-trip to client (send something, it sends back a reply), then that > > lookup would be valid > > Nope. The PID returned by libwayland is the one that bound the socket. > So if you create the socket, fork, bind it in the child, exit the > child, then on the compositor side you'll see a socket which belongs to > a PID which no longer exists. Wait until a privileged client re-uses > that PID, and boom. oooh i see. the rogue process waits for a lucky pid replace. it can set this up. i was going to say "forking and keeping your fd alive is madness and unless you have a very funky thing you generally close the fd before passing it off to any child eg between fork and the exec". but yes - this can be abused to wait for ANOTHER unrelated privileged client to slide into that pid slot. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 10:56:40 + Alyssa Ross said: > Carsten Haitzler writes: > > >> > What I think would be of value is a standardized method to decide which > >> > wayland clients should be locked down and which should not be. This is > >> > currently "undecided". Something a compositor can easily look up given > >> > the client socket and then decide which protocol requests it will handle > >> > in which way. > >> > >> Do I understand correctly that you're saying you'd like there to be some > >> sort of oracle, outside of the compositor, that the compositor could ask > >> what restrictions should be applied to a client? > > > > Yes. or more specifically I'd like it to be as simple and basic as possible. > > E.g. a file in /etc/wayland/security/securityinfo.cfg - imagine this is > > a .ini file format much like .desktop files so we can re-use parsers that > > most things have to eventually implement (how do you display sensible > > application info e.g. while alt-tab switching and icons for apps without > > doing some kind of .desktop file handling at some point? You can choose to > > never do this but then you may then not bother with more security either). > > > > Imagine there are 1 or more files that perhaps describe black or white > > lists in a fairly simple way that allow the compositor to limit functions. > > > > Personally, if I was going to lock security down 9have not gotten there yet > > - have other things to do before then). I'd be happy to support something > > like the above, but before that I'd do some of the following: > > > > 1 query UID/GID of the remote client. If it's not UID 0 and not UID of user > > running the compositor, auto-lock-down anything like copy & paste (eg behind > > such "are you sure" dialogs). We already do not support the screenshot > > protocol as it can be abused .. and the compositor has it's own ability to > > do screenshots and save them out to disk anyway. If we did support it, then > > it'd also do a "are you sure" thing too if UID/GID are not approved. I'd > > consider adding extensions to query SMACK label too if that was more widely > > used (or accept patches). > > > > 2. I'd also then after this add a custom "for my compositor only" white and > > black list of executable paths (probably a simple text file with a list of > > file globs per line like: > > > > deny /usr/bin/firefox > > deny /usr/bin/zoom > > allow /bin/screenshoot-tool > > allow /usr/bin/* > > allow /usr/local/bin/* > > deny /* > > > > So simple walk the list from top to bottom finding first rule that matches. > > this is simple allow/deny but could make these custom rules like: > > > > rule allow=cnp,screenshot > > rule deny= > > rule allow-cnp=cnp > > > > Then use allow-cnp to allow clients to just do cnp. Of course this would > > just be me - but it's simple to maintain and reason about and flexible > > enough to do what is needed. Would have this file per user for sure (e.g. > > ~/.config/mycompositor/security/rules.cfg). The user local file parsed > > first for allow/deny rules then parse the system file for a master list for > > the whole system). Yes - it is coarse and only allows approval based on > > fill file paths. Yes - a binary could be written to /tmp/ or $HOME/ then > > deleted or renamed (vector of attack) which is why I'd have the last rule > > be a deny /* (everything) unless explicitly allowed and only explicitly > > allow known good directories of tools which have other system controls to > > limit abuse (writing of trojans there -= eg /usr/bin will be limited to > > root to write to). > > > > I am sure you spend far more time on all of this than I do and are more > > aware of the problem space, so I think you are much better positioned to > > create standards that are both simple to implement and powerful and secure. > > If all compositors agreed on the same ruleset to load and even used the > > same simple small security library to do this (e.g. you make a small lib > > that can be given a socket fd and then return a list of allowed actions - > > eg cnp,screenshot, ...) this would go a long way to perhaps having a > > standard everyone agrees on and is minimal effort to implement. > > This sort of thing sounds good to me, especially paired with Simon's > secure context proposal[1]. I think it would be important to have it be > a little more complex than an allow/deny file, because it would be good > to give the user the ability to grant one-off permissions. But from the > compositor's perspective, it wouldn't really matter how the library came > to its determination. And users could switch between compatible > compositors while using the same authorization system. Forget then looking up exe from PID unless we have some kernel mechanism to lock this down (ie reliably report a fd or path to the exe that created the socket). this does indeed have issues as per gitlab thread with interpreted langauges... as this would always report the interpreter... > The
Re: Proxying Wayland for security
On Wednesday, July 28th, 2021 at 19:22, Carsten Haitzler wrote: > On Wed, 28 Jul 2021 10:56:40 + Alyssa Ross h...@alyssa.is said: > > > Carsten Haitzler ras...@rasterman.com writes: > > > > > > > What I think would be of value is a standardized method to decide > > > > > which > > > > > > > > > > wayland clients should be locked down and which should not be. This is > > > > > > > > > > currently "undecided". Something a compositor can easily look up given > > > > > > > > > > the client socket and then decide which protocol requests it will > > > > > handle > > > > > > > > > > in which way. > > > > > > > > Do I understand correctly that you're saying you'd like there to be some > > > > > > > > sort of oracle, outside of the compositor, that the compositor could ask > > > > > > > > what restrictions should be applied to a client? > > > > > > Yes. or more specifically I'd like it to be as simple and basic as > > > possible. > > > > > > E.g. a file in /etc/wayland/security/securityinfo.cfg - imagine this is > > > > > > a .ini file format much like .desktop files so we can re-use parsers that > > > > > > most things have to eventually implement (how do you display sensible > > > > > > application info e.g. while alt-tab switching and icons for apps without > > > > > > doing some kind of .desktop file handling at some point? You can choose to > > > > > > never do this but then you may then not bother with more security either). > > > > > > Imagine there are 1 or more files that perhaps describe black or white > > > > > > lists in a fairly simple way that allow the compositor to limit functions. > > > > > > Personally, if I was going to lock security down 9have not gotten there > > > yet > > > > > > - have other things to do before then). I'd be happy to support > > > something > > > > > > like the above, but before that I'd do some of the following: > > > > > > 1 query UID/GID of the remote client. If it's not UID 0 and not UID of > > > user > > > > > > running the compositor, auto-lock-down anything like copy & paste (eg > > > behind > > > > > > such "are you sure" dialogs). We already do not support the screenshot > > > > > > protocol as it can be abused .. and the compositor has it's own ability to > > > > > > do screenshots and save them out to disk anyway. If we did support it, > > > then > > > > > > it'd also do a "are you sure" thing too if UID/GID are not approved. I'd > > > > > > consider adding extensions to query SMACK label too if that was more > > > widely > > > > > > used (or accept patches). > > > > > > 2. I'd also then after this add a custom "for my compositor only" white > > > and > > > > > > black list of executable paths (probably a simple text file with a > > > list of > > > > > > file globs per line like: > > > > > > deny /usr/bin/firefox > > > > > > deny /usr/bin/zoom > > > > > > allow /bin/screenshoot-tool > > > > > > allow /usr/bin/* > > > > > > allow /usr/local/bin/* > > > > > > deny /* > > > > > > So simple walk the list from top to bottom finding first rule that > > > matches. > > > > > > this is simple allow/deny but could make these custom rules like: > > > > > > rule allow=cnp,screenshot > > > > > > rule deny= > > > > > > rule allow-cnp=cnp > > > > > > Then use allow-cnp to allow clients to just do cnp. Of course this would > > > > > > just be me - but it's simple to maintain and reason about and flexible > > > > > > enough to do what is needed. Would have this file per user for sure (e.g. > > > > > > ~/.config/mycompositor/security/rules.cfg). The user local file parsed > > > > > > first for allow/deny rules then parse the system file for a master list > > > for > > > > > > the whole system). Yes - it is coarse and only allows approval based on > > > > > > fill file paths. Yes - a binary could be written to /tmp/ or $HOME/ then > > > > > > deleted or renamed (vector of attack) which is why I'd have the last rule > > > > > > be a deny /* (everything) unless explicitly allowed and only explicitly > > > > > > allow known good directories of tools which have other system controls to > > > > > > limit abuse (writing of trojans there -= eg /usr/bin will be limited to > > > > > > root to write to). > > > > > > I am sure you spend far more time on all of this than I do and are more > > > > > > aware of the problem space, so I think you are much better positioned to > > > > > > create standards that are both simple to implement and powerful and > > > secure. > > > > > > If all compositors agreed on the same ruleset to load and even used the > > > > > > same simple small security library to do this (e.g. you make a small lib > > > > > > that can be given a socket fd and then return a list of allowed actions - > > > > > > eg cnp,screenshot, ...) this would go a long way to perhaps having a > > > > > > standard everyone agrees on and is minimal effort to implement. > > > > This sort of thing sounds good to me, especially paired with Simon's > > > > secure c
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 at 18:22:55 +0100, Carsten Haitzler wrote: > but in the end almost everyone wants some way to differentiate what clients > can > and cannot do based on some kind of sandboxing and rules. Before that can happen, you need a concept of identity: you can't say anything about what a client can or cannot do unless you can say which client it is. D-Bus, X11 and other AF_UNIX protocols have the same problem. You can get the euid from Linux SO_PEERCRED or SCM_CREDENTIALS, or other OSs' equivalents. D-Bus, X11 and Wayland already do this. Each OS does this differently but there's fairly wide coverage. You can get the primary egid (but only the primary one!) from Linux SO_PEERCRED or SCM_CREDENTIALS, or most other OSs' equivalents. D-Bus, X11 and Wayland already do this. You can get the supplementary groups from Linux SO_PEERGROUPS. At least D-Bus already does this. I am not aware of non-Linux implementations, but maybe some of the BSDs have a corresponding feature. On Linux systems with some LSMs (SELinux, SMACK, or AppArmor with Ubuntu's (non-upstreamed?) kernel patches) you can get the LSM security context from SO_PEERSEC, but this only helps if your apps all have unique LSM labels. D-Bus does this too. Linux SO_PEERCGROUP and SO_PEERPIDFD have been proposed, but as far as I know they are not in the upstream Linux kernel. As noted elsewhere in this thread, process IDs can be retrieved reliably from the same mechanisms as the euid, but reading extra information from /proc/$pid/ is prone to race conditions and cannot (in general) be done safely. SO_PEERPIDFD might defeat those attacks. Flatpak deals with these attacks in D-Bus by using a separate, trusted proxy process per Flatpak app, which is not under the control of the Flatpak app, but has a marking (/proc/$pid/root/.flatpak-info) that can be used to identify which Flatpak app it is acting on behalf of. Because the proxy is not under the control of the Flatpak app, the Flatpak app cannot force it to do what is needed to carry out the pid-reuse attacks[0]. Similarly, Flatpak apps are sandboxed with seccomp, mount namespaces and NO_NEW_PRIVS to make it difficult (hopefully impossible) for them to alter their /.flatpak-info. This is all Linux-specific and concerningly subtle, but probably good enough until the kernel provides the building blocks to make something better implementable. The approach typically used in e.g. GNOME is that Flatpak apps are treated as semi-untrusted, but apps that are not in a container (in the main OS) are treated as essentially part of the TCB[1], because in practice they have the ability to subvert trusted processes (e.g. overwriting ~/.bashrc, or dconf settings, or the login session's LD_PRELOAD or LD_LIBRARY_PATH, and using that access to execute arbitrary code). Ubuntu does a similar thing with AppArmor, treating typical end-user applications (and in particular many Snap apps) as untrusted, but treating things like an interactive terminal as part of the TCB. smcv [0] assuming the Flatpak app's permissions are not broad enough to allow arbitrary code execution / sandbox escapes; if they are, then you have already lost [1] https://en.wikipedia.org/wiki/Trusted_computing_base; for more useful terms, see also a design document I wrote for an automotive OS that has the same multiple layers of security boundary as a typical Linux desktop with e.g. Flatpak or Snap, namely: * security boundary between the OS/system services and all users; * security between one user and another * security between two apps owned by the same user https://www.apertis.org/concepts/security/#security-boundaries-and-threat-model ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
