<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 10/01/14 01:05, Martin Peres wrote: <div class="moz-cite-prefix"> <blockquote type="cite"> <blockquote type="cite"> 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. </blockquote> Out of scope ;) </blockquote> 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? </div> <blockquote cite="mid:52CF3962.9040504@free.fr" type="cite"> <blockquote type="cite">- The attacker has installed something like wayland-keylogger <a class="moz-txt-link-rfc2396E" href="https://github.com/MaartenBaert/wayland-keylogger"><https://github.com/MaartenBaert/wayland-keylogger></a> that sends him a list of all keys you pressed. </blockquote> 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 ;) </blockquote> ... 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?? <blockquote cite="mid:52CF3962.9040504@free.fr" type="cite"> <blockquote type="cite">- 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. </blockquote> 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! </blockquote> 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. <blockquote cite="mid:52CF3962.9040504@free.fr" type="cite"> 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.</blockquote> 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. <blockquote cite="mid:52CF3962.9040504@free.fr" type="cite">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. </blockquote> 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. <blockquote cite="mid:52CF3962.9040504@free.fr" type="cite">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. </blockquote> 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. <blockquote type="cite">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. </blockquote> 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 (<a href="http://www.maartenbaert.be/simplescreenrecorder/">SimpleScreenRecorder</a>)? 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. <blockquote type="cite">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? </blockquote> 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. <blockquote type="cite"> Can you guarantee apps will all require user input in order to operate? No offence, but I think you only think about your application. </blockquote> 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). <blockquote type="cite">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. </blockquote> 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. <blockquote type="cite">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. </blockquote> 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. <blockquote type="cite">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. </blockquote> 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 </body> </html>