<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Le 13/12/2013 18:57, Maarten Baert a écrit : </div> <blockquote cite="mid:BLU0-SMTP443B2572E79A774499B6051E2DF0@phx.gbl" type="cite"> <pre wrap="">On 13/12/13 16:01, Martin Peres wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Okay, then that's not an issue. </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap="">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.</pre> </blockquote> Right, but that's no excuse for making it harder for people who want to control the security of their system. In view of the current events, we should really propose something that is as secure as possible *by default* and make it as easy as possible to improve with simple MAC rules (path- or label-based) for distros who want to focus on security. <blockquote cite="mid:BLU0-SMTP443B2572E79A774499B6051E2DF0@phx.gbl" type="cite"> <pre wrap=""> A rogue application could simply read the firefox profile and steal cookies and passwords.</pre> </blockquote> Right, but we are talking about input here. Users never store their credit card numbers on the computer since they always carry them. Users do not understand other applications can snoop on input or output and it freaks them out when they are told. <blockquote cite="mid:BLU0-SMTP443B2572E79A774499B6051E2DF0@phx.gbl" type="cite"> <pre wrap="">In fact, it could install a fake firefox (or replace 'sudo', or even the wayland server) simply by changing PATH in ~/.profile. </pre> </blockquote> If attackers become root, then all hell breaks loose. Let's not talk about this, it has nothing to do with Wayland. <blockquote cite="mid:BLU0-SMTP443B2572E79A774499B6051E2DF0@phx.gbl" type="cite"> <pre wrap="">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.</pre> </blockquote> This is indeed the only issue in input/output security I want to have in the final system. This problem can be solved by using a different linker or using SELinux (AT_SECURE or simply not allowing applications to read shared library outside of the trusted /usr. In any way, this is a very valid concern, but it is a mistake of the application/packager if it allows loading arbitrary code at run time. <blockquote cite="mid:BLU0-SMTP443B2572E79A774499B6051E2DF0@phx.gbl" type="cite"> <pre wrap="">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.</pre> </blockquote> People are usually aware of the problems you talked about. The PATH issue can be mitigated by having user-writable folders in different partitions and using the mount option noexec to avoid being able to run binaries outside of /usr. The graphics stack is very obscure to almost everyone and I don't want to ask our users to learn how to defend themselves in new ways! What I think is important here, is that no application can perform a snapshot without the user being aware of it. I wonder what compositor-provided visual cue could be a good idea to signal a snapshot has been taken. <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <blockquote cite="mid:BLU0-SMTP443B2572E79A774499B6051E2DF0@phx.gbl" type="cite"> <pre wrap="">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.</pre> </blockquote> Every MAC implementation should be able to work with your proposed solution and it doesn't sound ridiculous to require screenshot applications to have policy written for them. However, we would be leaving the DAC-only users (the VAST majority) out in the cold and I'm not even talking about the un-necessary authentication dance we are so glad to have got rid of in DRM. <blockquote cite="mid:BLU0-SMTP443B2572E79A774499B6051E2DF0@phx.gbl" type="cite"> <pre wrap="">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.</pre> </blockquote> Right, I think we all agree that we need to find a good authentication scheme. Bonus points if it works on all Wayland compositors. What's the hassle of asking users to edit a root-owned file that contains the list of trusted snapshot applications? I don't think this is much hassle for compositors to look for applications in a list. All this code could be part of a library for authenticating privileged clients. A GUI could allow configuration for this if needed. No-one is saying your application shouldn't run on Wayland, we are just saying that we should think *carefully* about the security implication and do the system right instead of racing to add features and end up with a complete mess that would require application to support multiple versions of some protocols because their earlier version was inherently flawed. You should see this as a perfect opportunity to contribute an interface that makes a lot of sense for *everyone* (you included), even if it requires you to stop thinking primarily about your project. I'm sure you agree that 99% of the users use their DE-exported snapshot application which happily accepts having an hardcoded application for snapshots in the compositor. Are you porting SimpleScreenRecorder to Wayland? If so, you are aware that taking screenshots isn't the best possible thing to do to record videos. Being able to use the hw-provided video encoder seems like a good idea but I'm afraid it requires running inside the compositor... Cheers, Martin PS: Thanks for developing SimpleScreenRecorder, I may use it instead of gtk-record-my-desktop next time I need it :) </body> </html>