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