Authorized clients

[Martin Peres]

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