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