Authorized clients

[Maarten Baert]

On 10/01/14 01:05, Martin Peres wrote:
>> Let me help:
>> - The attacker has installed a Firefox plugin that sends him a copy
>> of all forms that you fill out.
>> - The attacker has messed with your PATH and has installed an
>> infected Firefox binary in a folder you own, and you're running that
>> instead of the real firefox, without realizing it.
>> - The attacker has messed with your init files and you are actually
>> in a chroot that he set up.
>> - The attacker has created a virtual machine that looks just like
>> your real computer, and he configured it to launch automatically, in
>> fullscreen.
> Out of scope ;) 
That's hardly an answer. How do you want to create a secure desktop when
you ignore valid issues because they are out of scope?

>> - The attacker has installed something like wayland-keylogger
>> <https://github.com/MaartenBaert/wayland-keylogger> that sends him a
>> list of all keys you pressed.
> No such thing possible. The wayland compositor gets the input from the
> kernel or from a virtual keyboard it launched itself. Then, it
> dispatchs the input to the right app, not any other app. We had been
> thinking about an app requesting all the keys as hot keys, but
> solutions have been found against that ;)
...
What else do I have to do to convince you? I've created a proof of
concept, I've given you the source code, I have tested it, IT WORKS, yet
you still claim it is not possible??

>> - The attacker is watching /run/user/1000 with inotify so he can
>> quickly open any files that appear there and if he is lucky, he gets
>> access to some SHM buffers.
>> - The attacker has renamed /run/user/1000/wayland-0 to something else
>> and is running his own Wayland proxy that now listens on
>> /run/user/1000/wayland-0. He uses this proxy to do a MITM attack on
>> all Wayland applications.
> These two require MAC, we can't do anything about it. Anyway, this is
> again out of scope. We are talking about not abusing the feature we
> want to add!
And all I'm saying is that the features you already have can already be
abused, and that the fix for those issues will also fix the screenshot
issue. So I think we should focus on that instead.

> If you can craft a VM that looks like the desktop of the person you
> are hacking ... without being able to get visual information for it,
> you are real good.
It's doable because most people do very little customization. Take a
standard Ubuntu desktop, figure out the desktop wallpaper (hardly a
secret), figure out the pinned icons (also hardly a secret), and it will
probably fool enough people to make it worthwhile. An attack doesn't
require a high success rate when you can just target enough people.
That's why those 'nigerian scams' work despite being totally obvious.

> This attack just isn't practical. Stop using fear mongering just so
> people wouldn't mind "a little more". You're obviously smart, so
> instead of denying the problem, we could work on it.
That was never my intention - I am not trying to use fear mongering any
more than you. But since we were discussing theoretical attacks, I
figured it would be useful to mention a few other attacks too.

I am not saying that the screenshot API should be freely accessible nor
that it should be completely blocked. I am saying that it should be made
secure as part of a much larger sandboxing mechanism, rather than
reinventing the wheel and adding new security mechanisms.

> You know, I actually implemented something like that with a research
> team, PIGA-OS. As nice as I think it is, you need to accept this is
> COMPLETELY out of the scope and has nothing to do with Wayland.
> Wayland should be as difficult to abuse as possible. Whatever MAC
> policy or system the future may hold, the protocol we'll be proposing
> should still be good!
>
> If you don't understand that, think about all the languages or
> protocols that sounded ok a while ago and how painful it is to get rid
> of them now to replace them with more secure ones.
That's exactly why I want to integrate this with a proven existing
sandboxing mechanism. I believe systems like cgroups and Android-like
sandboxing will be the future. Some future security researcher will have
to come up with that sandboxing mechanism, and as part of that he will
have to think about all the possible protocols and services that these
sandboxed applications will need, and he will have to check them all one
by one and configure/change them so they are integrated with the
sandbox. This will be a massive task. I think we both agree that this
task will be completely impossible with X11, but it should be possible
with Wayland. So this security researcher will have to configure this
authentication API and integrate it with the sandboxing system he is
designing. I want to make this task as simple as possible - that's my
only goal.

This creates two partially conflicting goals:
- Make Wayland as secure as possible now.
- Make Wayland easy to integrate with future sandboxing systems.

To me it seems that you only care about the first goal, because you
aren't even discussing the second goal at all. My opinion is that the
first goal is irrelevant in practice because the Linux desktop we have
now is inherently totally insecure, and I have already accepted that I
can only install applications I absolutely trust. Because any
application can read my Firefox passwords, and my SSH and PGP keys. So
on my system, there are only applications I trust, because I have no
other choice. Therefore any authentication API in Wayland will be
completely useless for me, because every single application that could
try to access it is trusted, otherwise I wouldn't have installed it in
the first place.

Once this hypothetical future sandboxing system exists, I will be able
to install applications that I don't trust in a sandbox. That will be
great. At that point I will obviously block those applications from
taking screenshots, and I will start caring about this Wayland
authentication API. But as long as that hasn't happened, I just want
something that doesn't get in my way.

To summarize, I believe that we shouldn't treat the authentication API
as something that we need now, but something that we will need at some
point in the future. It should be there, Wayland should be written with
this API in mind, and applications should support it, so that when we
finally have this much-needed sandboxing system, it will work (i.e. we
avoid the UAC disaster). And that means the API should be designed in
such a way that it is as simple as possible to use and integrate with
this future sandboxing system.

> Actually, I don't think this is needed. For video capture, the
> authentication could be white-list based and the application run using
> a hot-key. Do you think it is usable-enough? I certainly think this
> secure-enough for me as long as the compositor gives me an indication
> when the application stops recording that it indeed stopped and won't
> be able to start it again unless I want it to. 
This is something I don't really get. I understand the need to launch
the application from the compositor to guarantee a clean environment
(lacking a sandbox mechanism, but let's not get into that again). I
definitely understand the need for a global binding API, I will
certainly use it. What I don't understand is why the 'start recording'
button should /launch/ the application. Why can't I launch the
application in advance (through the compositor) and start recording
later? Sure, I can work around it by telling the user to press some
button to launch my application, and letting the capture code run at all
times just to keep the compositor happy, but that's just so wasteful and
it's not intuitive for the user at all. It's almost like I'm writing a
jailbreak app that requires various strange user actions in order to
defeat some security mechanism. It's not something that should be
required for a legitimate use case.

Have you ever tried my application (SimpleScreenRecorder
<http://www.maartenbaert.be/simplescreenrecorder/>)? If not, can you
please give it a try or at least look at the 'pages'? I think this
discussion will be a lot easier if you actually know what I am trying to
do ;).

The system you propose completely breaks the workflow I have now and
forces me to either change the workflow (significantly degrading the
usability and usefulness of the application) or split my application
into two separate processes, one just to capture the screen and one for
everything else. The last option is hardly a solution because it only
shifts the problem from the compositor to my application: How am I
supposed to ensure that these two halves of my application can
communicate with each other, transferring gigabytes of data in an
efficient way, ideally zero-copy, all without any interference from
untrusted applications?

It gets even worse when the user is trying to do complex things like
using SimpleScreenRecorder in combination with other JACK applications
to do more advanced sound processing. Streaming over the internet is
also a challenge, these protocols expect the application to behave in a
specific way and I can't just decide to restart my application while a
connection is active, just to comply with some weird compositor
requirement. I have no idea how a full voice-over-IP application like
Skype or Jitsi would have to deal with this.

> Yes, that was pretty stupid of me but the point remains, if you
> administrate multiple computers and some have video_capture/screenshot
> apps and some don't. You would need to remember which ones are which
> in order to know if you are safe or not?
The security should never depend on whether the application is
installed, it should depend on whether the application is whitelisted.
It would be perfectly valid to whitelist the application for one user
but not for another user (or you could use user groups, PolKit allows
this). And it would of course be disabled by default. If you deal with
sensitive information, and you don't need to record anything, then you
would never enable it on your account. Now you can just log in using
your account, on any machine, and you will never be recorded.

I think it's pretty obvious that you shouldn't deal with sensitive
information on the account of someone else, unless you trust them, so
that's not an issue.

> Can you guarantee apps will all require user input in order to
> operate? No offence, but I think you only think about your application. 
Obviously I have no idea what other applications will do. I can only
tell you what's needed for my application and hope that the requirements
for other applications are similar. If there are other application
developers that are interested in this API, I hope they will join the
discussion. But I can't predict what they will want or need. Still,
input from one application developer is better than no input at all,
right? ;)

I can't promise that I will never create a command-line interface, but
if I do, it will definitely be treated as a separate thing that has to
be whitelisted separately. Users should be free to enable the
command-line version if they want, and accept the associated risk. It
will obviously not be the default and I will make sure that there is a
very clear warning message explaining the user why it is risky to enable
it. Just like I am already doing for some other far more risky options,
such as enabling cross-user OpenGL recording (yes, this is useful, in
fact it is even required for SteamOS compatibility).

> I doubt the reason why Linux isn't used on every desktop is clearly
> not a technical reason. I'm sure you know that too, so please focus. 
That's not what I was trying to say, I meant that a system won't be
accepted unless it satisfies /all/ requirements, rather than /most/
requirements. Just like many Windows users claim they can't switch to
Linux because they need this one irreplaceable program that only runs on
Windows. Wayland is very much in the same situation: It is able to run
most GTK3 and Qt5 applications right now, but users will only switch to
Wayland if it supports all the applications they want, not just the most
common ones.

> If users want no security, they can use X11, with DRI3, it should be
> pretty nice and should be comparable to wayland. If they want some,
> they need to agree that they'll have to do things differently from
> X11. That's a fact. 
True. But most users do not /want/ security. They need it, but they
don't realize it, and they will give it up instantly when there is some
reason to do so. Security is not their #1 priority. These users won't
switch to Wayland because it is more secure. They will switch because it
is faster, or because it looks nicer, or because it fixes some
annoyances they had will X11. Or they won't switch at all. That's why so
many things are insecure - it would be possible to make them secure (PGP
is a good example) but most users don't care enough.

> No, we need to design the protocol well. Otherwise, 10 years from now,
> a new wayland will be needed because too many apps are depending on
> stupid ideas people had 10 years ago because security wasn't a concern. 
Exactly! We have the exact same goal but totally different opinions
about how we should get there. I believe sandboxing is the future, and
is required for a secure desktop, so I want a protocol that is
compatible with sandboxing (future-proof, essentially). You want a
protocol that is already secure without sandboxing. And I believe that
such a protocol would be totally impractical and obsolete once
sandboxing is ready.

Let's put it this way: In order to get a secure desktop, we either need
to ensure that every single application we run is trustworthy (what we
try to do now), or we need sandboxing. Do you agree?

Maarten Baert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140110/444163c6/attachment-0001.html>