<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres <span dir="ltr"><<a href="mailto:martin.peres@free.fr" target="_blank">martin.peres@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 10/01/2014 16:44, Maarten Baert a écrit :<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/01/14 14:56, Martin Peres wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please provide a detailed explanation for that and tell me how likely it is to ever end up upstream.<br>
</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).<br>

</blockquote>
<br></div>
And who would manage the sandboxes? Systemd won't be able to because it is user applications.<br>
</blockquote><div><br></div><div>systemd and logind both support user-spawned applications. In fact, one of the goals for the 3.12 cycle of GNOME is to work on systemd user sessions.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Until such sandboxing mechanism exists, what are we supposed to do then?<br>
</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.<br>
</blockquote>
<br></div>
I guess we'll need to educate users if we go this way.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote>
I hadn't heard of LSM actually, but I think it's exactly what we should do.<br>
</blockquote>
<br></div>
LSM just defines hooks, not the decision engine.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
Or we create 'Wayland Security Modules' and provide a default module, which can then be replaced later if needed.<br>
</blockquote>
<br></div>
That makes perfect sense and it was something we have been wondering since 2012 :)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</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?<br>

<br>
There's a very real risk that requirements that make sense today will actually make things far worse in the future.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It could take a decade. LD_PRELOAD would be much faster to get rid of in the mean time. '<br>
</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 ...<br>

</blockquote>
<br></div>
Yes, but those apps who really need it should be compiled with it. Almost all the other apps do not need this, especially not the ones we need to trust. Who cares about the confidentiality of games ;)<br>
<br>
As for OpenGL recording, you won't need that anymore, will you?<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

<br>
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.<br>
If the application didn't really quit and starts recording later on, the user may not notice that the record notification appears.<br>
</blockquote></div>
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.<div class="im">
<br>
<br>
We already have a notification system that's universally accepted: libnotify. Just show a notification whenever that systray icon appears or disappears.<br>
</div></blockquote>
<br>
What if you missed it? libnotify can be added to make it more obvious, but a sticky icon should always be visible on screen.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

In this case, you should be able to start and stop the video recording.<br>
</blockquote>
Sounds much better :).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</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?<br>

</blockquote>
<br></div>
Because a clear notification just never exists. People won't see the change unless they look for it. The notification is just here to expose the state of the system.<br>
<br>
What you want is what Sebastian described: The compositor should ask the user if he agrees in the case where an app didn't get launched by the compositor. In this message, it should be doable to remind the user he can get around that message by setting the recording app to "the one he wants" and then press "combinaison of key".<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</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.<br>

</blockquote>
<br></div>
Agreed, sw encoders should still work (I said so in the very sentence you quote).<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Fair point. We don't have a system like that right now though.<br>
</blockquote></div>
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 :).<br>

</blockquote>
<br>
Agreed.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</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?<br>
</blockquote>
<br></div>
Because I foresee how they are going to be used. The user will never give consent or even understand the security implication. Sure, the app has to access the snapshots but let's lower the risks by requiring the user's input ourselves.<br>

<br>
The difference is that there will be 3/4 wayland compositors while there will be tens of screenshot apps. The screenshot apps will mostly be un-maintained and people will add features to fit their needs and screw their security (while we don't have a good sandboxing system).<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I want a protocol that is as secure as possible without sandboxing, yeah.<br>
</blockquote>
And I believe that the best thing we will ever be able to achieve without sandboxing is a false sense of security.<br>
</blockquote>
<br></div>
Output confidentiality is something that is doable without sandboxing. Only screenshot apps are a threat to that and I want that threat to be limited by requiring a clear user action (either press the right hotkey or via a pop up) before allowing screenshots for that app.<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My goal here is to restrict how much we need to trust "privileged" applications. Sandboxing is just another (very effective) way of doing so.<br>
</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.<br>
</blockquote>
<br></div>
I am not, this is the most critical problem on our distros today but it is un-related to wayland, so let's not talk about it.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</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.<br>

</blockquote>
<br></div>
Well, the solution to that is to force the compositor to display a pop up warning if the app was launched without it and the compositor should never allow the user to say "Never ask me again".<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. <br>
</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.<br>

<br>
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.<br>

<br>
<br></div><div class="im">
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>