 Thank you. So this year my typical Wayland talk is not really a Wayland talk, but more a desktop security talk So while porting Quinn to Wayland I came into the situation that I had to look at security because Quinn takes over lots of functionality from X and we finally have the possibility to make that secure and then I started to look at it and try to make it secure and Realize it's not possible because the foundations are broken are not secure at all So with this talk I want to Show a little bit where we have problems for the security of the whole stack what we need to do to improve that I will start a little bit this showing this Typical problems you have on x11 and then show what wayland changes what wayland doesn't change and Then present some ideas how we as a community can improve the Security of the Linux desktop So I'll start with x11 and I'll start with the typical thing Which is known for x11 and that is the key logger. So Getting all key events as part of the protocol Up until a month ago. I thought it's possible to protect against by Using the crap keyboard command, but then I noticed that since x input to one or later You get all raw key press and raw key release events Even if an application crap the keyboard So even if the screen is locked another application can monitor all key events that are native key codes So you still need to translate them you send them through Licks xkb common and then you can do great things with it for example in plasma 5.8 We have modifier only shortcuts like you press the meta key and it will open the The start menu that is based on exactly that I'm listening for all raw key presses and all key release events send it through xkb common to figure out whether I am Modifier is pressed whether another key is pressed in addition and then can decide whether only the modifier key was pressed So that has valid use cases, but it also means that You can easily build a key logger with it now You might think that key lockers just don't matter to you But with the key logger you can do very very evil things if you get all key events Imagine you open console the key logger knows that you just typed in console and open that Then you do SSH to your server it knows that you did SSH and then you type in your passphrase So it has the passphrase it's running as your user and it also has access to your SSH key So it can do the same thing It can listen for when you do see or see do it can listen when you get to your bank account and add your Number and PIN it gets your Facebook password your GPG passphrase your SSE key Passphrase whatever you want it will have everything you do every thought you type into your computer is Available to a key logger now KDE's vision is that we improve the Privacy of the of the user on the computer system So this is really a fundamental aspect of what KDE wants to solve Keyloggers are preventing to have a private system. It's just not possible with an architecture Which allows keyloggers now we kind of with x11 do all the other wonderful things like doing the opposite Injecting key events. This is now in Demonstration I sent to the dolphin and Kate mailing list in the beginning of this year. It's Actually not a vulnerability in dolphin or in Kate It's just making use of what the core x11 protocol allows you to do so what I did is I Had a small application Listening to all windows which gets opened then looking whether it's a whether it's a dolphin Looking whether it's running as route and then starting to inject key events the key in one to open the embedded console Which is f4 and then I couldn't type any command. I wanted as route just because dolphin was running as route And that can be done with pretty much everything you get all the state in x11 and Yes, so what can you as an application developer do to protect again that if you know that you could be abused if you run as route and Someone does something evil with you. Well, the most important thing is to never run graphical applications as route We have been telling that to use us for a long time, but it doesn't help. They still do it They think they have to do it So what I suggest applications to do is to add a check before creating the you GUI application and Check whether you run as route and just quit with an error message shown to the console Maximum print line don't open an X window don't open any window if you're open and window you're owned. It's too late Now obviously there are valid use cases to do things as route But that doesn't mean that your GUI application needs to run as route That that means that if you open a route shell in a console you are equally vulnerable, right? Kind of yes Only if you combine it with other things like if you if a key logger is running then yes but console actually also has other problems, but The fun has fixed will the one Harold reported. Yeah, it's fixing console It's we still have to fix it in in jacquak, but there is a warning saying you will be pwned But at least there's a warning good enough But yeah, it's it's a yeah, what you say it's it's quite true It's a fundamental problem that as soon as you switch to route and other applications Notice that you can do evil stuff with that on x11 Valen will fix that But anyway, what I would suggest is two applications if you want to do something as route use things like polkit use things like chaos to Delegate the actual task to a small helper binary, which is secure, which doesn't need a windowing system That would help a lot It's not actually enough to not use the windowing system because as soon as you fire up a q-core application You also download you also allow the loading of plugins, which is automatic So you also need to unset a huge swathe of environment. I will come to that later on So then on x11 we have more things we can do like we can get a notification whenever a window Changes its visual contents and then redirect that to an xpix map and use that to get the texture from it and then you render To a special window and that replaces all the content of x now That doesn't x11 compositing window manager, but it allows to record everything you do You can replace the compositing manager and you have no chance to really see that you can render the desktop in different ways Remove a window add another window You have no control about what really gets shown. It just replaces for Co-functionality of x11 and if we combine that we can do Interesting things like a phishing attacks that was something I had seen presented at xdc so you basically just get a screenshot of a firefox or another browser and You put another x window on top of it at the exact same position at the address bar And then you start to inject key runs to the real firefox Send that to evilbank.com and you render that you are back at bank.com with a nice green Log symbol so everything will look perfect, but you have no chance to notice that you are actually on Evilbank.com and of course a mainland will fix it Well, no it won't So the protocol is sane and it fixes many aspects, especially the key logging aspect We don't get window informations. We don't know which windows are there. We cannot inject input events We have no way to screenshot. We cannot position windows manually We have the clip but not broadcasted to all applications So that is already a very sane and secure protocol, but it doesn't really help us as we will see later on So first of all, it's not fixed in Quinvalent because we added additional protocols, which currently everybody could use so We allow injecting input events currently only mouse and touch events That was added for KDE connect because we KDE connect have this wonderful remote Feature and I wanted to use that on valent So I came up with a small protocol to be able to inject mouse events so that I could use that again We have information about about windows exposed to plasma. That's something we need for the task manager. It's also Yeah, mostly needed for the task manager also needed by K-Runner a few other things and Especially for plasma we allow Windows to position themselves. We want the panel to be at the position plasma tells us So with that it's pretty much possible to do most of the things I just presented as well We don't get screenshots. So that is currently not possible and you don't get a key logger through the protocol There are other ways for that So we can fix the protocols. We can choose introduce a security layer Their ideas for that for quite some times. I had been thinking a lot about it There's a valent security model. There was a suggestion for an authentication protocol we could just look at the PAD UAD group ID and By that decide who is allowed to do what? That would fix the protocol issue, but it doesn't fix the overall issue. It would move the Trust issue just one level down. So then Quinn trusts plasma But how can plasma trust the plasmoids it loads those content is not signed But even if it's signed, how can we trust that it doesn't do evil stuff? So Yes, we will fix the protocols because it's important to do that But we have to do more just by having a secure valent protocol we don't have a secure system and The root problem in my opinion is that we have lived in a mantra which is if it runs, it's trusted I've heard it like that very often that if an application is already running on your system You screwed you don't have to protect against it anymore because it's Connected to exit can do so many evil things. You don't have to protect against other things if it runs it has to be considered trusted and Yeah, but how did we get there? Why did we not start to protect our application against each other? And I think the main problem here is that x11 has to be too broken From a security perspective Why should for example the accessibility extension through debas protect against the key logger if you have a key logger in x11 built in there was just no need for that and That is a typical thing. So we have always the things like why protect console if you can Against executing commands when you also could inject key events Just through x11. So with x11, it's just not possible to have a secure system and then I also think that we concentrated on the wrong areas we Had the few that we need to protect the applications to get on the system on the first place so Yeah, you're screwed when you when the system when software is on your system So we protect again that getting in but we cannot protect to get it in that's something we see In the web space with how many security issues get constantly fixed in the browsers Also, what we always thought about was we need to prevent malicious applications to become rude So if it's running at the you as a user, it's not that bad because it's not true, but that's not true if you are Just because you're not true it does not mean that you cannot do evil things if I'm an Evil application running as your user it can do very very evil things but not install additional software Which is also not true with flat pack and snappy and things like that But we'll all be possible to install as a user. So yeah, why be rude? It's not what you are aiming for So now how can we get malware into the system and For that I think we as the Linux community don't take Security really serious and I've selected a few quotes here, which I From the last two years So for one thing we had we were of hacked Isis if you downloaded Linux Mint on February 20th. So the the Isis Provided by Linux Mint were exchanged with an hacked version Then we have one gyro forgot to upgrade the SSL certificate such as users get around it by changing the system clock That's how reddit spin it, but it was correct That was if you click the link you got in warning that they forgot to upgrade They are SSL certificate and suggested the users to just set back the system clock to be able to connect to their website again From the webkit department we have we regularly receive bug reports from users with very old versions of webkit Who trust that distributions to handle security for them and might not even realize they are running ancient unsafe versions of webkit That's a huge problem related to that from devion Therefore browsers built upon the webkit cute webkit and khdml engines are included in jessie But not covered by security support. These browsers should not be used against untrusted websites I have two questions to the deviant project. First of all, what is a trusted website? Second, how should a user know that he uses an application with khdml? But not let's not look at Other project that look at us at the cute and kde community So how does cute web engine look like we have currently 5.7 based on chromium 49 with security backpots up to 51 since then we did not have an update So the 571 was not yet released so what about the 48 security issues fixed in chromium 52 and Seriously, I bought them all they're not critical. So we haven't had an emergency release and How do I know that where can I find that you can't because we make no guarantees? I Think you just proof my point But I don't wanted to blame cute web engine here It was just a nice example because I actually looked for it and didn't find the information We also have other engines like cute webkit, which is no finally Perhaps getting an update and we still have khdml I don't want to know how many security issues are in khdml because nobody looks at it but why are we still releasing it and Then I asked myself can we trust our own software our distributed software? We don't get a tag. We don't sign our get tax not all of them Some are some are not our turbos are not signed and our info page on download kde.org Does not use HTTPS So how should I as a user figure out whether I'm using the software I'm supposed to do at runtime? It's not much different our K package system. They don't The the packages are not signed. So we don't have the possibility to verify whether it's correct Also the content of the package gets loaded at runtime without any integrity check so you can overwrite the package content which is Root-owned in your local home directory by just putting very different file for it. So that's a huge problem On our side we go and that also means that we cannot make currently with the bailout protocols plasma secure Because it does not have signed packages That's something we have to introduce in our infrastructure to have a secure desktop and Now I come to The environment variables. So how to exploit the system in the best way so the idea thing is you get a drive by download vulnerability in a browser and There or in any other application exposed to the internet doesn't really matter and then you just write into Glorified file like profile bash or see config auto start pump environment That are all wonderful files to write into and all you need to do is to set up a few environment variables best as LD preload And then you can take over the system Don't forget that now you can do local user models for system the inside the dot config dot the std So you can start basically everything that I didn't even know So our startup process Sources the shell script the environment variables are and then set for all processes and what's really Bad is that it gets sourced before we start our session start up so they get sourced by the login manager they get sourced by palm and Overall it means that our session might be owned before the first plasma script binary is executed So I was naive enough to think I can reorder the startup script for Quinn Wayland To make sure that all these variables are unset and then David Edmondson told me it's pointless Look at that. Yeah so What can you do if? You own the session you could for example install a key logger into Quinn Wayland Example code for that is on git kde.org and my personal clone So I thought well, I don't wait for others to write the key logger against Quinn I do it myself and it was easy. It took me 10 minutes You could and that using old code nowadays it would be even easier You could replace the polkit KDE authentication agent and wait till Polkit request the password You can ptrace applications to get the secrets or you can just listen on debuts. That's also always very good So, yeah, could we fix some mess? Yes, we can but it will break workflows, especially our developer workflows We have the Linux security modules We have a Burma as a linux libs.com and we can use that to protect our applications a little bit by disallowing Wide access disallow network access if it doesn't need it With app armor, we can even disallow Certain debuts calls if your application doesn't need it and that's something I want at least in case greenlock and Quinn to add lipsec.com to just Restrict what's allowed to do that you can be sure that Quinn just cannot write out stuff to files Then we can disallow ptrace which we did so all of the applications listed here. We adjusted to Not being able to be ptraced Many distributions That's a type of it should say many applications many distributions do that by default For example, Ubuntu does it by default But nevertheless, we should do it in Our own applications as well if your security relevant at the ptrace disallow flick We need to change our startup We just need to make sure that all the Scripts are no longer sourced and that we have verified startup process that we know the code which is running and Yes, that will break our workflows Especially if you're everybody who installs to opt and then has the environment variables adjusted to have pass loaded correctly and Yeah, we have a wonderful new technology coming up That's flat pecs and snap and that gives us a new possibility to also partly secure Aspects of the abster you because it allows us to disallow ride to home And we can easily disallow ride to all these evil environment variables files and config files We can with that limit access to debas We can use the file system portal to have the file open dialogue outside of this of the container and There's also a wonderful project by Ubuntu to have one X server pay X application It's nice way to secure X for it breaks X IPC mechanism Which may which for me means that it's also destroying an important aspect So I'm not convinced. That's a good idea, but from a security perspective. It is and We need to bring back the trust into our Software we need to get to where we can say if it runs. It's really trusted Which means that we need to introduce signing of K packages We need to make security relevant interfaces only available for the signed Packages if a package is not signed. It should not be able to be a task manager We should our get our applications to run in a sandbox sandboxes don't protect completely But it makes it more difficult. It makes it it gives another Level of defense. So that's something which we should do Um, we should think about whether we can authenticate our applications to the to the user a typical example is Is it the lock screen or is it just an application which looks like the lock screen and that was something we had been thinking around Also with the VDG How can we make that? How can we have a shared secret between the user and the lock screen? We could have things like the dedicated key combo as we know used to have or something like user account control It's ideas. It all has drawbacks. It all has nice things, but it's in possibility and One thing I had been thinking about was to improve the password asking experience so normal application which needs a password it can be P traced and Or the focus can be stolen from the window because the window manager doesn't know that this window is currently Asking for a password and that the focus should not be stolen from it or that windows taking order changes stuff like that So if we would have a password Asking service then the window manager would know that this is now Asking for a password and we could make sure that while the password is being asked the focus cannot be stolen and we can make sure that this password is entered in a secure way and Yeah, last but not least I want to say that Rayland gives us the possibility to have a secure desktop But we still need to do work and I would say we should do it to give our users a secure desktop and Give them the privacy they need and should have Can you say what you meant with having API like the task manager secure because I can still look into a prog pit, right? That was more like for plasma internally like the task manager has library exposed with all the new informations and That our plus points are not allowed to exit that So it's for manage good Yeah, okay, it's a mirror as a mirror and me and me stated up the download that Katie that work Do you do you have any any ideas of securing that only the Downloads that Katie the org main website, but also providing the providing them the Providing the way for securing also that the mirror sites of the download that Katie Katie that org Sorry, I think I'm the wrong person to ask that I think that would have to go to the sis at once I only noticed that it doesn't have HTTPS. I Was glad to see on your your slide that you say allow use application to run as a sandbox Yeah, are there any project progress in in making that possible because So far all application the one does sandbox have to have if its own set UI ID change route Tool or had to use anonymous namespace which Deepian has disabled for some reason a news kernel Which makes that right now and use application cannot run in in a sandbox. Are there any work to fix that? I think flat pack is the answer to that It might be restrained by the same problem that there's no general mechanism That would be when a problem for the distribution to solve You didn't mention the K wallet problem Like basically anyone can ask a password saying it's any other application Yeah, I didn't mention that because I There are too many things to talk about but it's part of the asking for password in a secure way thingy but yeah, it's It's a huge problem like that be a little bit So you said that you are adding all these protocols that are not in Wayland, but you are adding them in Queen like for specific apps like Plasma or itself or KD connect or K color chooser or whatever Shouldn't these protocols be part of Wayland because then these apps won't work in genome and the other way around So yes and no For the one which I added to KD connect that might make sense For the ones I added for plasma. No, that is plasma specific that doesn't make sense to you to have shared Unfortunately, we have only time for one more question You mentioned the asking for passwords in a secure way our password fundamentally broken should be replaced by something else sorry I mean Many people think that us watch should be replaced. I think I got it. Yes, but I think that's out of our control. I mean websites ask for passwords and All right, thank you everybody, thank you