Authorized clients

[Martin Peres]

Le 10/01/2014 19:37, Maarten Baert a écrit :
> On 10/01/14 18:13, Martin Peres wrote:
>> And who would manage the sandboxes? Systemd won't be able to because
>> it is user applications.
> I don't know how this will be done in the future, I can't predict that.
> I suppose there will be some kind of sandbox manager just like we have
> virtual machine managers today.
>
>> I guess we'll need to educate users if we go this way.
> We need to do that anyway ;).
>
>> LSM just defines hooks, not the decision engine.
>>> 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 :)
> Okay, so why don't we do this?
>
> I realize that Sebastian Wick already suggested using PolKit for the
> same reason, but I think PolKit is already too specific. It wasn't
> really created with sandboxes in mind. PolKit is a good choice now but
> it may be replaced in the future, so compositors and applications
> shouldn't depend on it too much.

Sure, and WSM (good name) can be linked to polkit or our
own implementation of the policy afterwards.
>> 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?
> Ideally, if we can get all compositors to implement a screen capturing
> protocol, and we extend it to 'window capturing' as well (more on that
> in the other thread), and they all implement it in a way that works
> well, then I won't need it anymore. But that will take time.
>
> The nice thing about my current OpenGL recording implementation is that
> it doesn't have to depend on anything. It can work with X11 or Wayland,
> GLX or EGL, OpenGL or OpenGL ES and it doesn't require one specific
> window manager. It also allows me to add my own rate control logic and
> other complex things to the application that is being recorded. For
> example, I can artificially reduce the game frame rate so it matches the
> frame rate I want (this isn't speculation, this feature actually exists
> and it works great for most games). So it's always nice to have it as an
> alternative, even though it isn't perfect.
>
>> What if you missed it? libnotify can be added to make it more obvious,
>> but a sticky icon should always be visible on screen.
> Yes, I think both should be used.
Ok, great. We'll need to write a guide for compositors to follow in
order to be secure.
>> 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".
> I would prefer that solution (I wouldn't even use the launch hotkey
> anymore, actually). I don't thing recording apps (or screenshot apps, or
> any other app that needs access to restricted APIs) should be treated as
> a special thing by the compositor. The compositor just knows that key X
> launches application Y with permissions Z. The user can use it for any
> application they want. I'm sure there will be many other use cases for
> this authentication API, such as accessibility apps.

I agree but we really need to make sure compositors do implement
exactly what we tell them to :)
>> 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.
> Okay, if this can be done with a dialog that is easy to understand,
> that's fine. I just don't want to end up in a situation where I have to
> provide DE-specific instructions about how the user should go to their
> control panel and set up my application so it can be launched by a
> hotkey with additional permissions. If the user tries to launch the
> application the normal way (from the menu), and it doesn't work, then
> he/she should understand why that happened and how it can be changed.
Yes, it will need to be explicit and short.
>> 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).
> The screenshot apps most people use are part of their desktop
> environment. I don't think they are unmaintained, they just work so
> no-one sees any need to change it. But I assume that the
> GNOME/KDE/XFCE/LXDE developers do know what they are doing and wouldn't
> allow features that would compromise the security of their desktop.
>
> Anyway, it doesn't really matter that much if there's a good dialog that
> tells the user what's going on and what he/she should do.
As long as it cannot be bypassed and shows up _*every*_ time there is a
screenshot, then it is acceptable, yes.
>>> 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.
> IMHO that's the wrong way to look at security, but I suppose we will
> just have to agree to disagree on this one point ;).
I more than agree with you, it is needed. I just don't think the Wayland ML
is the place for 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".
> Okay, that's fine. It won't stop users from complaining though, but I
> suppose I will just redirect them to whatever desktop environment the
> user is using :P.
And if they don't want this warning, they should launch your app with
the hot key! It should be explained in the warning.