<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 10/01/14 14:56, Martin Peres wrote: <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite">Please provide a detailed explanation for that and tell me how likely it is to ever end up upstream. </blockquote> If by 'upstream' you mean the kernel: I don't think anything new is needed, actually. Create a separate directory in /run/user/1000 for each application, use cgroups to restrict applications to their own folder (assuming that's possible, I didn't check it). <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite">Until such sandboxing mechanism exists, what are we supposed to do then? </blockquote> Only install and run applications we trust, and hope that our decisions are correct. Sadly that's the best strategy we have right now. <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite">That's a fair goal, indeed. That means you want to leave the authentication out of the protocol as much as possible so as you can plug whatever decision-making system you would want. That's kind of LSM for user applications. </blockquote> I hadn't heard of LSM actually, but I think it's exactly what we should do. <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite"> I am interested in this and also think this is the future. In the mean time, we should define a way that doesn't require any such system. </blockquote> Or we create 'Wayland Security Modules' and provide a default module, which can then be replaced later if needed. <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite"> This conflicts just like SELinux and DAC conflict. Ever heard of DAC override? We would just need the same system to be able to bypass the current authentication scheme if using a later system. Is that satisfying? </blockquote> Only if this can be done without changing every single client application. Let's say we go ahead and implement the system you proposed. This essentially forces all clients to launch themselves through the compositor, and register global bindings, and pass serials from those bindings in order to take a screenshot. That's already a huge nuisance for application developers, but let's ignore that. Now sandboxing appears, and all these old requirements make no sense with the new security model, in fact it makes things much harder because now the application, in its sandbox, will try to launch something through the compositor, outside that sandbox. The compositor now has to figure out how this sandboxing system works and put the newly launched application back in the same sandbox. Now the application tries to create a global binding, but are sandboxed applications even allowed to do that? There's a very real risk that requirements that make sense today will actually make things far worse in the future. <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite">It could take a decade. LD_PRELOAD would be much faster to get rid of in the mean time. ' </blockquote> There are valid use cases. Some debugging tools depend on it. OpenGL recording in my app depends on it. Even Steam depends on it for their 'community integration' system. It won't be removed any time soon ... <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite">The reason I think it is important to avoid applications from not using the video feed directly is because of the notification needed for the user. If he runs the application then tries to quit it then he will wrongly assume he is out of the danger zone. If we mandate the application to start recording straight away, then the user could check if the notification (most likely a red record icon in the systray) is gone. If the application didn't really quit and starts recording later on, the user may not notice that the record notification appears. </blockquote> Then the notification should be more obvious! If the user doesn't notice that it appears, then he may also fail to notice that it doesn't disappear when he closes the application. Even more so because human vision is very sensitive to changes but not very sensitive to things that stay the same. We already have a notification system that's universally accepted: libnotify. Just show a notification whenever that systray icon appears or disappears. <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite"> However, now that I think of it, the notification could indicate an application has the rights to do the recording. This way, we don't waste ressources and the user still is able to tell if he is out of the danger zone. In this case, you should be able to start and stop the video recording. </blockquote> Sounds much better :). <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite">Just tell your users they need to select your application as the screen recorder and press the right hotkey to run it. No need for 2 applications to communicate. </blockquote> That's only doable now that you've dropped the requirement to start the recording right when the application is launched ;). I still don't like that the user now needs to remember another hotkey, it would be much simpler if the user could just start the application using his favourite launcher. If there is already a clear warning icon in the system tray (and probably a nice big notification as well), then why is this restriction still needed? <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite"> And there won't be transferring gigabytes of data because the goal here is to design an interface that doesn't use the CPU at all for screen recording. Weston already has an example of that. Of course, the CPU should be able to access the buffers from the GPU to do sw encoding, but that should be fallback, not the normal path. </blockquote> AFAIK there is no hardware encoder that comes anywhere close to the quality/bitrate ratio that x264 provides. I'm not dealing with a noisy 15fps 640x480 webcam, I'm dealing with 30fps 1080p video and often higher. A decent encoder is not a luxury but a requirement for live streaming at that quality. Hardware encoding is currently only feasible for recording to a file (that will hopefully be re-encoded later with a better encoder). So for me, hardware encoding is a minor feature that some gamers will like (because it leaves more CPU power for the game itself), but it can't replace software encoders yet. <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite"> Fair point. We don't have a system like that right now though. </blockquote> I think the compositor will need one anyway at some point. Just let the compositor keep track of security settings in a root-owned file specific to that user. The file doesn't need to be owned by the user just because it applies to that user :). <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite"> Yeah, but this is your app warning, not the operating system. I don't want apps to do anything like that in the users' back. </blockquote> How does that make a difference? If you trust that the application is responsible enough to do screen recording, then why wouldn't it be responsible enough to show that warning message? <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite">I want a protocol that is as secure as possible without sandboxing, yeah. </blockquote> And I believe that the best thing we will ever be able to achieve without sandboxing is a false sense of security. <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite">My goal here is to restrict how much we need to trust "privileged" applications. Sandboxing is just another (very effective) way of doing so. </blockquote> So you're saying that you're okay with the risk that any application can read all your files, but not with the risk that they could take screenshots? I really don't understand that. <blockquote cite="mid:52CFFBFC.3030601@free.fr" type="cite"> Anyway, I keep telling we all mostly agree. The thing you don't agree with is requiring a direct user input before giving the privileges. In the future, the sandboxing technique could override that if needed. In the meantime, I want it. </blockquote> I suppose I can live with the limitation that my application can't be launched from the menu like all the other ones, for now at least. But I'm 100% sure that I will get complaints about it, and I expect that some users will disable the restriction completely to get around that. <blockquote type="cite">As I said in the security presentation a friend of mine and I gave at XDC2012, full screen apps grabbing all keys are an availability hazard too. </blockquote> Easy to fix, the compositor can simply add a special key that makes the window normal again (and removes its ability to go fullscreen for some time). I'm more worried about the potential social engineering attacks. Actually, any access to OpenGL allows denial of service attacks, because GPUs are not pre-emptive (it never stops a task before it's done). This is also a big issue with WebGL. GL_ARB_robustness tries to mitigate this somewhat but it's really just a band-aid. But in practice, it seems that attackers aren't very interested in denial of service attacks, because it isn't actually being abused. </body> </html>