Limitations of Weston's screenshooter / Are there any plans to create an official screenshot protocol?

[Martin Peres]

Le 13/12/2013 18:57, Maarten Baert a écrit :
> On 13/12/13 16:01, Martin Peres wrote:
>> I may be wrong, but other unix users shouldn't be able to
>> communicate with another user's compositor unless this
>> user specifically allowed that by adding him to his/her group.
> Okay, then that's not an issue.
>
>> Screenshot/screencapture applications are a confidentiality hazard.
>> We don't want any application run by the user to be able to
>> read the credit card number you are writing in firefox, right?
> True, but sadly there are many other ways for applications to steal data
> from other programs, if both applications are running as the same user.
Right, but that's no excuse for making it harder for people who want
to control the security of their system. In view of the current events,
we should really propose something that is as secure as possible
*by default* and make it as easy as possible to improve with simple
MAC rules (path- or label-based) for distros who want to focus on
security.

> A rogue application could simply read the firefox profile and steal
> cookies and passwords.
Right, but we are talking about input here. Users never store their
credit card numbers on the computer since they always carry them.

Users do not understand other applications can snoop on input or
output and it freaks them out when they are told.

> In fact, it could install a fake firefox (or
> replace 'sudo', or even the wayland server) simply by changing PATH in
> ~/.profile.

If attackers become root, then all hell breaks loose. Let's not talk
about this, it has nothing to do with Wayland.

> Or it could use LD_PRELOAD to inject a library and override
> any system or library function it wants (e.g. wl_keyboard_add_listener).
> I can write a proof-of-concept 'Wayland keylogger' to demonstrate it, if
> you want.
This is indeed the only issue in input/output security I want to have
in the final system. This problem can be solved by using a different
linker or using SELinux (AT_SECURE or simply not allowing applications
to read shared library outside of the trusted /usr.

In any way, this is a very valid concern, but it is a mistake of the
application/packager if it allows loading arbitrary code at run time.

> A simple restriction in Weston is not enough to stop this. Only a system
> like SELinux can fix this. With this in mind, I think the ideal
> authentication system would be one that integrates well with existing
> security/sandboxing mechanisms so that it can be enabled with minimal
> hassle in places where it's important, while accepting that local
> applications running outside the sandbox simply can't be stopped from
> doing bad things. The current solution just gives a false sense of
> security IMHO.

People are usually aware of the problems you talked about. The PATH
issue can be mitigated by having user-writable folders in different 
partitions
and using the mount option noexec to avoid being able to run binaries
outside of /usr.

The graphics stack is very obscure to almost everyone and I don't want
to ask our users to learn how to defend themselves in new ways!

What I think is important here, is that no application can perform a
snapshot without the user being aware of it. I wonder what
compositor-provided visual cue could be a good idea to signal a snapshot
has been taken.

> I have no experience with SELinux so I'm not sure how such a mechanism
> should work. But it seems that both X11 and PulseAudio use a cookie
> mechanism, where they put a random string (e.g. from /dev/urandom) in a
> file in the home directory of the user. The file mode is 600 so only the
> owner can read it. Wayland could use a similar mechanism, except that
> the cookie would only be needed for unsafe actions like taking
> screenshots or listening to global hotkeys. SELinux can then block
> applications that want to open that file. Since the cookie is simply a
> random string, it can be easily transferred to an application that would
> otherwise not be allowed to read it. For example, an untrusted
> application that isn't allowed to read the cookie directly could run a
> trusted application which would show a popup asking the user whether the
> untrusted application should be allowed to capture the screen. If the
> user accepts, the trusted application will read the cookie and give the
> result to the untrusted application. This is only an example of course,
> but it shows one big advantage of this approach; it separates the
> security/sandboxing mechanism from the compositor, and the only thing
> the compositor has to do is write a random string to a file at startup.
> The same security/sandboxing mechanism would be compatible with any
> wayland compositor that follows this simple protocol.
Every MAC implementation should be able to work with your proposed
solution and it doesn't sound ridiculous to require screenshot applications
to have policy written for them.

However, we would be leaving the DAC-only users (the VAST majority)
out in the cold and I'm not even talking about the un-necessary
authentication dance we are so glad to have got rid of in DRM.

> In any case, I don't think putting all security-sensitive functionality
> in the compositor is the best approach. It would lead to a very bloated
> compositor, and as far as I understand that's exactly what Wayland tries
> to avoid. I'm also worried that a design like that would simply
> encourage users to disable the restrictions completely because they need
> to run some application that needs access to the screen, or global
> hotkeys, or a similarly sensitive feature. The average user still favors
> functionality over security, so any security mechanism that is too much
> of a hassle will simply be disabled.
>
> In this case, the application that I've created is completely useless
> without the ability to record the screen, because that's its primary
> function. It is not a feature I can drop. It is technically possible to
> let the compositor start my application, but that would mean I have to
> modify every existing Wayland compositor. If there is no authentication
> mechanism, then the only practical thing I can do is tell the users to
> completely disable the restrictions of their Wayland compositor, and
> that is really something I want to avoid.

Right, I think we all agree that we need to find a good authentication
scheme. Bonus points if it works on all Wayland compositors.

What's the hassle of asking users to edit a root-owned file that contains
the list of trusted snapshot applications? I don't think this is much hassle
for compositors to look for applications in a list. All this code could 
be part
of a library for authenticating privileged clients. A GUI could allow
configuration for this if needed.

No-one is saying your application shouldn't run on Wayland, we are just
saying that we should think *carefully* about the security implication
and do the system right instead of racing to add features and end up
with a complete mess that would require application to support multiple
versions of some protocols because their earlier version was inherently
flawed. You should see this as a perfect opportunity to contribute an
interface that makes a lot of sense for *everyone* (you included),
even if it requires you to stop thinking primarily about your project.

I'm sure you agree that 99% of the users use their DE-exported snapshot
application which happily accepts having an hardcoded application for
snapshots in the compositor.

Are you porting SimpleScreenRecorder to Wayland? If so, you are aware
that taking screenshots isn't the best possible thing to do to record 
videos.
Being able to use the hw-provided video encoder seems like a good idea but
I'm afraid it requires running inside the compositor...

Cheers,
Martin

PS: Thanks for developing SimpleScreenRecorder, I may use it instead of
gtk-record-my-desktop next time I need it :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131213/7721f064/attachment-0001.html>