Proposal: integrity checks for packages and cryptographic signing

[Martin Graesslin]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160104/d9632dc5/attachment-0001.sig>