Hi all, happy new year! I had a too long Christmas break and spent quite some thinking about how to improve the security situation on Plasma/Wayland and I think I found a solution to address one of the problems.
tldr: we need to sign installed packages and verify the integrity when loading the package. == Attack scenario == A browser has a vulnerability allowing drive-by downloads to $HOME. This allows an attacker to store KPackages (e.g. Plasmoids) which will get loaded by the application using the malicious data. What are the threats of this: 1. Declarative/QML kwin scripts: a declarative kwin script is able to take over rendering of the system and intercept all input events. This is comparable to running an X Server. 2. A Plasmoid is able to render a window thumbnail to a frame buffer object and store/send it somewhere. This is a violation of secure screenshots. Also as Plasma dialogs can place themselves it allows to take over the system in similar ways as on X11. 3. A look'n'feel package can install a key logger into the lock screen. == What I want to solve? == I do not want to prevent the attack vectors outlined above as that's a futile exercise. Thus I want to return to "if it runs it's trusted" in a reliable way. If a user downloads a plasmoid it's trusted, but a drive-by download is not trusted. Thus we need to establish "trust". == How to get there? == My proposal is that while packages get installed the sha-sum of each file gets calculated and written into a shasums file. The shasums file gets cryptographically signed and both the shasums file and the signature get installed as well. On loading a package we traverse the package install location, generate the sha-sum of each found file, check that it exists in the shasums file, verify it's correct. In addition we check that the signature is valid and that all files listed in shasums were found. If any of the checks failed we abort loading the package. == What will this solve? == By verifying the signature we know that the shasums file was not modified. By checking the shasum file of each file we know that those were not modified. By checking that no file was added or removed, we ensure that the integrity matches also in that way. Overall this gives us an integrity check for the package. We know it wasn't tampered with since it got installed. For the attack scenario this means: A drive-by download cannot just install a package or overwrite files. This would break the integrity check and the manipulated package would not be loaded. Similar it would not be able to install a malicious package as it's not able to sign it. == What that means for developer setups? == Generating the shasum and signing the packages must become part of the general package installing. Rolling this out must not affect our own dev setup. Thus also plasmoidviewer should not require a valid signature as that's just not dev friendly. In addition we must make it as easy as possible to allow developers to install their own private cert file and integrate the signing key into kdesrc-build/ cmake, so that just running kdesrc-build signs all packages with the private key. Our signature validation infrastructure must make it possible to have additional certificates installed in a global (not user) location. This should work for common dev setups installing to e.g. /opt as well. E.g. it should honor my /opt/kf5/etc/ location. Overall: for devs it must not be disruptive! And that's possible. == What this means for distributions? == That's where I fear opposition to the plan. We must integrate distributions early enough. Here I think key is that we don't sign our own packages, but let distributions sign them. That way distributions still have control over it, can change packages, add own, etc. The setup for developers should make that possible. Also a possibility is that we sign the distros certificate with our root certificate - but that's an implementation detail. == What this means for 3rd party developers? == We need to setup a signing infrastructure. == How to roll it out? == The last point makes it obvious: this will take time. We cannot just go there and enable it in next plasma release as that would break 3rd party developed packages. Thus I suggest the following steps: 1. change the install command to generate the shasums 2. implement generic infrastructure in KPackage to validate the shasums/ signature 3. start to use it in KWin/Wayland for all scripted elements (security risk really high) 4. start setup CA infrastructure 5. start signing 3rd party plasmoids 6. start validating packages, but allow to still load not-signed packages 7. on Wayland switch over The last point I think should not happen in 2016. So we have about a year to get everybody on board. == This whole thing is futile, because... == because there are so many other ways to take over control over the system? That's true, let's fix them and make the system secure! Please don't oppose ideas to make the system more secure because there are other insecure elements. I'm trying to look at the big picture here. == Will it affect startup time? == Obviously generating the sha-sum requires loading the file and performing a calculation. This takes time, but I don't think it will affect startup time. It's a highly concurrent situation: we have many files to check, so that can all be threaded. Most of the time will probably be on file loading and we have to do that anyway. The new API must be designed in an async way. I'm thinking of something like: QFuture<ValidationResult> validate(ValidationFlags flags); == Signing packages doesn't protect against malicious code == That's true, but that's not what I want to solve. But it will make it less likely that the package is malicious as someone will have looked at the code to sign it. Currently packages on kde-look.org or any other location are not checked, so this can only improve the situation. == Why not verify whether the files are root owned? == This was my initial idea for solving the problem in KWin, but this would be highly disruptive to developers and also 3rd party devs and users. == Why not verify root owned as another way to signing? == Because it just makes the code more complex. Let's just sign all files and have one way instead of multiple. == Why this mail on plasma-devel and not frameworks? == Because Plasma is currently the main user of KPackage, so I want to discuss in the inner group first, before going to the big exposure. ---- Long mail, sorry about that. But I wanted to outline the idea properly as it's security relevant. If you have further questions, please ask. I spent days thinking about this during my vacations, so I'm sure I already thought about your question as well ;-) Cheers Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel