Authorized clients

[Martin Peres]

Le 10/01/2014 16:44, Maarten Baert a écrit :
> On 10/01/14 14:56, Martin Peres wrote:
>> Please provide a detailed explanation for that and tell me how likely 
>> it is to ever end up upstream.
> 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).

And who would manage the sandboxes? Systemd won't be able to because it 
is user applications.
>
>> Until such sandboxing mechanism exists, what are we supposed to do then?
> Only install and run applications we trust, and hope that our 
> decisions are correct. Sadly that's the best strategy we have right now.

I guess we'll need to educate users if we go this way.
>
>> 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.
> I hadn't heard of LSM actually, but I think it's exactly what we 
> should do.

LSM just defines hooks, not the decision engine.
>
>> 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.
> Or we create 'Wayland Security Modules' and provide a default module, 
> which can then be replaced later if needed.

That makes perfect sense and it was something we have been wondering 
since 2012 :)

>
>> 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?
> 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.
>
>> It could take a decade. LD_PRELOAD would be much faster to get rid of 
>> in the mean time. '
> 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 ...

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 ;)

As for OpenGL recording, you won't need that anymore, will you?
>
>> 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.
> 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.

What if you missed it? libnotify can be added to make it more obvious, 
but a sticky icon should always be visible on screen.
>
>> 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.
> Sounds much better :).
>
>> 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.
> 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?

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.

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

Agreed, sw encoders should still work (I said so in the very sentence 
you quote).
>
>> Fair point. We don't have a system like that right now though.
> 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 :).

Agreed.
>
>> 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.
> 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?

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.

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).
>
>> I want a protocol that is as secure as possible without sandboxing, 
>> yeah.
> And I believe that the best thing we will ever be able to achieve 
> without sandboxing is a false sense of security.

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.
>
>> My goal here is to restrict how much we need to trust "privileged" 
>> applications. Sandboxing is just another (very effective) way of 
>> doing so.
> 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.

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

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".
>
>> 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. 
> 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.
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel