Authorized clients

[Maarten Baert]

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140110/5a9fdb6c/attachment-0001.html>