Le 08/01/2014 17:20, Sebastian Wick a écrit :
Am 2014-01-07 15:07, schrieb Martin Peres:
Those are extremely rare cases. Users wanting to do that should agree
they give up
confidentiality and should thus be administrators in order to tell the
compositor that.
Why should those people have worse security then others only because
they want a feature you define as non-standard?
That's not what I meant. I meant that if they want what you say you want
to allow,
they will de-facto loose some security (namely, confidentiality if the
screenshot
app is misbehaving).
In this case, we can still restrict access to the interface to a
handful of programs
to lower the risks, but it will still be possible for these
applications to spy on the user
without him knowing and this is something that shouldn't be allowed
by default.
Like I said, we should be able to let polkit decide. You could even
distribute
a .rules file which white-lists an application if we pass the
executable path.
It is indeed something that is good, but insufficient because the
trusted programs
can do whatever they want and the compositor won't be able to tell if
what they
request really is what the user wants. Simple example, you want a CLI
application
to be able to make screenshots and save them to a file.
As an attacker, if I want a screenshot, I'll just run the program and
get the screenshot.
Is that something you think is OK, I definitely think this is not.
This is why I said the compositor shouldn't agree on a screenshot
request if it can't
tell if it was a user-made request or an app-made one. The only
solutions we found
so far have been:
- listen for hot keys from an input device (we have to trust the kernel
for not allowing to forge events)
- require a confirmation of some sort (popup / systray icon / whatever)
The decision making is just what it is, a decision. This is an
implementation detail.
You propose to use polkit for the decision making, why not? But I think
this is overkill since
we only need a file in /etc/wayland/restricted_apps.d/ containing the
full path of the authorized
app and the interfaces that are allowed.
You may be right. I meant for screen grabbing (images or videos), no
idea
what restricted interface could be useful for a wayland compositor.
Any idea?
The GNOME accessibility team need a few restricted protocols. Don't
know about
the details, though.
I would be interesting in knowing what they have been thinking about!
Would it be ok for you if the compositor asked the user to agree for
the program to
do the operation? If so, we can guarantee that this is really the
user's intent and
allow the application. We can also add a security warning with a "Do
not ask again"
checkbox. Would it be satisfactory to you?
If an application has the permission to use an restricted protocol it
already
met all the requirements. You should talk to the polkit dev if you
want such
an feature, I guess.
See, that's where we disagree. An app can get hijacked or used in
conjunction with others
apps to make it around the security policy you want to set.
I used to work in a research security team and one of the project we
used was PIGA which
essentially is a language to define security properties and a compiler
was then responsible
for checking all the ways there was to violate the security property
wanted (with the SELinux
policy as an input of all the allowed operations). There were hundreds
of thousands of ways to
go around trivial security properties such as "do not allow a
user-written file to be executable".
Can you certify all the screenshot apps won't be able to be used in a
malicious way, if not
directly, indirectly? I can't and I think no-one can.
I don't really like mandating compositors to implement that much code,
but that's the only
secure way I see to allow the uses cases you want to allow.
And that's exactly why I don't want to implement the authorization
checking
in the compositor! We can safely let polkit decide in non-obvious cases.
Less code in the compositor, less duplicated code and less security risks
because polkit is designed to do that.
Maybe. It doesn't solve the security issue though ;)
By the way, I asked Peter about the security of input and that should
be good. We then
discussed about visual feedback as a mean to provide some mitigation
and show
some applications are grabbing the screen in the background. That may
be something you
would be interested in, in your case. What do you think?
I'm personally not interested in it but I guess it's a nice feature
for some
people and I don't see why it should not work.
I do see why it shouldn't work. It would not be standardized, users
wouldn't understand,
that would become annoying, users would deactivate it, unaware they are
being spied on.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
