Authorized clients
Maarten Baert
maarten-baert at hotmail.com
Fri Jan 10 10:37:09 PST 2014
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.
> 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.
> 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.
> 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.
> 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.
>> 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 ;).
> 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.
More information about the wayland-devel
mailing list