Le 10/01/2014 03:27, Maarten Baert a écrit :
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?
Because we aren't trying to create a secure desktop. We are trying to
design protocols that are hard to abuse.
- 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??
Right, that was stupid of mine but again, just because something else is
needed, we shouldn't bail out by just not caring about this. If one
wants a secure desktop, he shouldn't compile applications with the
possibility to use LD_PRELOAD.
Or applications run from the DE should never be run the LD_PRELOAD
environment variable. It should be quite easy to enforce that.
Just because some (most?) users won't do it doesn't mean we shouldn't
create a good interface. How can you even argue with that?
- 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.
Please provide a detailed explanation for that and tell me how likely it
is to ever end up upstream.
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.
Good points, but just because this attack is possible doesn't mean we
should give up on the rest.
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.
Until such sandboxing mechanism exists, what are we supposed to do then?
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.
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 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.
This creates two partially conflicting goals:
- Make Wayland as secure as possible now.
- Make Wayland easy to integrate with future sandboxing systems.
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?
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.
That's indeed a valid view, but I don't think they conflict that much.
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.
It could take a decade. LD_PRELOAD would be much faster to get rid of in
the mean time.
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.
Agreed.
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.
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.
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.
What do you think about it?
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 ;).
Yeah, I checked it out and told you it is a good one. I just don't want
to wayland to be X11, we should do it right even if it means some
applications will have to be different on X11 or wayland.
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?
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.
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.
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.
Yeah, what I told above about the tri-state (no risks, an app can do
video recording, an app is using video recording) notification icon
should be the only thing we can do for those apps.
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.
Fair point. We don't have a system like that right now though.
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? ;)
As I said before, I welcome your input and value it!
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).
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.
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.
Agreed, they expect it but don't want do deal with it.
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.
I want a protocol that is as secure as possible without sandboxing, yeah.
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?
My goal here is to restrict how much we need to trust "privileged"
applications. Sandboxing is just another (very effective) way of doing so.
However, sandboxing using cgroup/LXC or any MAC system shouldn't matter
much to wayland. Of course the compositor should export information
about his internal state and ask for the permission to do some things,
but that's about as far as wayland should rely on these systems.
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.
Cheers,
Martin
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
