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