Authorized clients

[Jasper St. Pierre]

On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres <martin.peres at free.fr> wrote:

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

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.


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



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140110/9f0fdb05/attachment-0001.html>