On Fri, Dec 13, 2013 at 12:57 PM, Maarten Baert <maarten-ba...@hotmail.com>wrote:
> On 13/12/13 16:01, Martin Peres wrote: > > I may be wrong, but other unix users shouldn't be able to > > communicate with another user's compositor unless this > > user specifically allowed that by adding him to his/her group. > Okay, then that's not an issue. > > > Screenshot/screencapture applications are a confidentiality hazard. > > We don't want any application run by the user to be able to > > read the credit card number you are writing in firefox, right? > True, but sadly there are many other ways for applications to steal data > from other programs, if both applications are running as the same user. > A rogue application could simply read the firefox profile and steal > cookies and passwords. In fact, it could install a fake firefox (or > replace 'sudo', or even the wayland server) simply by changing PATH in > ~/.profile. Or it could use LD_PRELOAD to inject a library and override > any system or library function it wants (e.g. wl_keyboard_add_listener). > I can write a proof-of-concept 'Wayland keylogger' to demonstrate it, if > you want. > I'm curious how your rogue program could modify the link-time environment of a running Wayland compositor. I don't think that these things are things that mean we shouldn't give free-roam access to the Weston front-buffer contents. I don't think you think that either, I just want to double-check. Perhaps it makes sense to start thinking about a privileged API system for other users too: the a11y folks want to fake mouse clicks to apps, and that's not something we just want to give out to other apps either. I don't know if Kristian has thought about this at all. But what I think would sell most people would be to make a proof-of-concept that uses whatever security restriction mechanism you like to build your new screenshooter protocol, rather than just saying "security is hard, we shouldn't even try". A simple restriction in Weston is not enough to stop this. Only a system > like SELinux can fix this. With this in mind, I think the ideal > authentication system would be one that integrates well with existing > security/sandboxing mechanisms so that it can be enabled with minimal > hassle in places where it's important, while accepting that local > applications running outside the sandbox simply can't be stopped from > doing bad things. The current solution just gives a false sense of > security IMHO. > > I have no experience with SELinux so I'm not sure how such a mechanism > should work. But it seems that both X11 and PulseAudio use a cookie > mechanism, where they put a random string (e.g. from /dev/urandom) in a > file in the home directory of the user. The file mode is 600 so only the > owner can read it. Wayland could use a similar mechanism, except that > the cookie would only be needed for unsafe actions like taking > screenshots or listening to global hotkeys. SELinux can then block > applications that want to open that file. Since the cookie is simply a > random string, it can be easily transferred to an application that would > otherwise not be allowed to read it. For example, an untrusted > application that isn't allowed to read the cookie directly could run a > trusted application which would show a popup asking the user whether the > untrusted application should be allowed to capture the screen. If the > user accepts, the trusted application will read the cookie and give the > result to the untrusted application. This is only an example of course, > but it shows one big advantage of this approach; it separates the > security/sandboxing mechanism from the compositor, and the only thing > the compositor has to do is write a random string to a file at startup. > The same security/sandboxing mechanism would be compatible with any > wayland compositor that follows this simple protocol. > > In any case, I don't think putting all security-sensitive functionality > in the compositor is the best approach. It would lead to a very bloated > compositor, and as far as I understand that's exactly what Wayland tries > to avoid. I'm also worried that a design like that would simply > encourage users to disable the restrictions completely because they need > to run some application that needs access to the screen, or global > hotkeys, or a similarly sensitive feature. The average user still favors > functionality over security, so any security mechanism that is too much > of a hassle will simply be disabled. > > In this case, the application that I've created is completely useless > without the ability to record the screen, because that's its primary > function. It is not a feature I can drop. It is technically possible to > let the compositor start my application, but that would mean I have to > modify every existing Wayland compositor. If there is no authentication > mechanism, then the only practical thing I can do is tell the users to > completely disable the restrictions of their Wayland compositor, and > that is really something I want to avoid. > > On 13/12/13 16:07, Giulio Camuffo wrote: > > I don't think so, but you don't need to wait anything to start working > > on it. ;) > > [...] > > I think the protocol in weston was made just to showcase the way such > > a protocol would work, the "official" one would allow that. > Okay, so the screenshooter interface is essentially a work-in-progress > that will eventually become part of Wayland? > I don't think there was any intention to allow an official screenshooter protocol. If there was, I think we'd want it out-of-tree for now. > > I think the best solution would be to have a way to configure in the > > shell/compositor the trusted clients, and maybe a way for any client > > to ask the permission to bind to a restricted interface, which would > > pop up a request to the user. > I agree, but I think this should only be done for applications that are > running inside a sandbox. Any application that's not sandboxed can > essentially do whatever it wants, the popup would be useless and just > provide a false sense of security. > > > I see two possible solutions: > > - the screenshooter_shoot request could carry a serial which the done > > event sends back later > > - the screenshooter_shoot returns a screenshoot object which has the > > done event > The first solution is very simple and would be fine for what I need. > However, wouldn't it make more sense to use a wl_callback object? It > sounds like this is exactly what wl_callback is meant for. > Yeah, wl_callback is a generic "I need a 'done' event" thing here. > Maarten Baert > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
