Packages signing in pacman, Archlinux getting secured?
Introduction
This post title is such a troll… Archlinux is my favorite Linux-based distribution, it’s already secured, blah blah blah, you got the point. Here’s the story. Questions come next.
Signing? How awesome is that!?
Security is one of my big concerns. So I started to work on packages signing, which might be the biggest lack in Archlinux for now. Thanks to toofishes, who is totally mentoring me on this, we went to a point where a nearly complete design is available. The implementation is far from finished, but it’s now possible to see where we’re going, if we keep this way. And I think it perfectly suits the Arch philosophy.
The place to start with
We started working on makepkg. Basically, we added an option in the BUILDENV array (defined in /etc/makepkg.conf) named sign, which causes makepkg to sign the package it builds using gpg, creating a binary 72 bytes detached signature file.
That’s one small step for add-repo…
Then, we need the signature to be available on the repos. Using a 72 bytes file for each package would be overkill considering the number of mirrors. So we wanted to include the signature in the repo database (this .db.tar.gz file you might have opened if you understand a few words in this post). A whole file path in the tarball for every signature would be overkill too, plus it is uncompressed in /var/lib/pacman/sync/ and each signature could take something like 8kb (depending on your fs and its options, btw) as a separate file! But for each package, there’s a desc file with fields in it. Our idea is to put the signature in it. As it is plain text, we can’t put the binary signature directly. base64 is here! With a tool to (de)code it in coreutils, it definitely was the way to go. Now we have a new field which looks like:
%GPGSIG% iEYEABECAAYFAkhDcqcACgkQj8OreK3cj9eStwCeIjf9AWQcPE9hH+t7iQ2pVCychxwAoKBcIiYph4RzVISP6bklppdOwmkF
It’s a long line, but it is still plain ASCII and won’t interfere with the file format as there can’t be any % in it. So we tweaked repo-add. That was a one line patch in the code. Did I tell you it’s a true story?
What’s the point?
Now that everything is here to generate repos with signed packages, maybe pacman could use this brand new information…
It could embed muuuch code from GnuPG. OK, what else? It could use gpgme, which would rely on gnupg itself, but is supposed to make things easier. Here, we just have to check a signature. We can work like git! Basically, we just need to popen something like gpg --keyring $keyringfile --no-default-keyring --verify - $pkgfilename and write the binary key to it. Then check for return code 0.
That’s where the biggest design choice come. How pacman should know whether a package can be trusted or not? Let’s use (a) keyring(s)!
I’ll let the gnupg users who learnt their lesson tell you that to trust Archlinux’s packages, you need to meet Aaron Griffin himself (omg omg! RMS would be so jealous!), or someone who met him, or someone who met someone who met him, etc. as long as it seems at least a lot more than reasonable to you. And please do the same for [archlinuxfr], [eee], etc. Web of trust is a good concept.
Irrelevant throughts: Now let’s suppose you install Archlinux via FTP: you launch your installer from the USB key you’ll give to Grand’ma at her birthday next week, and you have configure gpg before installing packages. Well, I don’t know for you, but when I install a system, I want this done fast. Meaning at least a prompt to start tweaking within minutes. Dealing with a keyring like you would do for e-mails or chat sessions with your buddies at the NSA is not really adapted. Anyway, you will be able to work that way with our system!
We could have a keyring per repository in pacman.conf. I think it doesn’t make much sense: if I trust a developer to provide me binaries it seems I want to use, I don’t really care whether it’s init or vim (but I care whether it’s not emacs or still not). And I care even less if it’s in [core] or [community], because I love TUs. Did I tell you TUs are beautiful and smart young men and women who need care and love?
Now that you’re convinced pacman’s keyring should be system-wide, it would be convenient to deal with the various packagers of the repos you use. Here’s a hypothetical story:
I wake up at 10AM. I take my breakfast, a shower, and go to school. My girlfriend (yes, hypothetical) kisses my math teacher… Let’s be realistic. A year later, I install Archlinux on my brand new laptop. In [core], I keep archlinux-keyring. I add the [archlinuxfr] repository to /etc/pacman.conf, pacman -S archlinuxfr-keyring. I confirm the installation even if this package is not signed. I change Keyring /etc/pacman.d/archlinux.gpg to Keyring /etc/pacman.d/belovedlaptop.gpg, and run gpg-merge-keyrings archlinux.gpg archlinuxfr.gpg belovedlaptop.gpg. Then I add the [kdemod] repository, install its keyring and run gpg-add-keyring kdemod.gpg belovedlaptop.gpg.
Questions as promised
Why don’t the thousands of people who visit this blog put at least a dozen of comments on it? Do you think I should stop replying to my replies to my patches on pacman[dash]dev[at]archlinux[dot]org? Is packages signatures something you actually want? Do we do it completely wrong or just wrong?
26 Comments to “Packages signing in pacman, Archlinux getting secured?”
Leave a Reply
I’d like to have this feature, but maybe the checking should be optional; I was trying to configure a debian-based distro for a friend of mine, and I found all the signature stuff really annoying (most likely because I never used apt).
I like the feature, but I fear the implementation :)
I’ve never understood why more package managers (pacman, portage, paludis) didn’t implement signature checking. There’s absolutely no good reason not to, and not doing it is just asking for trouble.
This would satisfy one of my two main concerns with pacman, the other being the lack of package version control. (I can say “don’t consider foo for upgrades” and hope this doesn’t break anything depending on it, but I can’t say “don’t upgrade foo past 1.3.1 and don’t upgrade any packages that require versions of foo >1.3.1″. I also can’t downgrade to a previous version of foo from within pacman, which can get annoying in some scenarios.)
*sign*
Thanks for getting involved with pacman development and particularly this part of it.
GPG signing of packages is a many times asked and long awaited feature.
PS. Sadly AFAIK there are no female TU’s.
Anyone ever heard of more than 10 cases of a malicious pkg doing major damage?
And how would you garuantee that the base key is ‘clean’?
What if a mirror distributes malicious CDs // images.
That wouldn’t help anyone.
And how about the weekly / monthly changing TUs and Devs? Why should I trust them anyway?
I think this assumes more security than it really gives. Mostly there is no real basis to trust each other in the team, just because they have provided nice PKGBUILDs before they could still go mad.
Best is, if someone would just propose a PKGBUILD and 2-5 people have to say its OK and the server will build it.
Then we would have to trust only Archlinux.org (-Admins).
Anyway, I like arch better, even with the sec-flaws than LFS or something weird like that…
The only problem is trusting the keys stored in the repository.
Pretend I’m an attacker. And I have access to the server ie. the package files and the db. I could build a new archlinux-keyring package with my key in it, sign that package with my key, and then sign any packages that I decide to modify maliciously with my key as well. As long as people are trusting the archlinux-keyring package, which is shared in the same way as every other package, it’s not all that secure.
Now, if the archlinux-keyring package was independently verified or available over some other channel, that would fix that flaw, but it’s hard to make that sort of thing automatic.
“And how would you garuantee that the base key is ‘clean’?”
The best you can do is verify that the base image you install from has the correct checksum and verify that the mirrors agree on the checksum. If the servers are compromised and a malicious image distributed along with a modified checksum, there should be a mechanism in place to notice it (..eventually). For example, the checksums ought to be signed by the developer(s) that prepare the image for release, and the developers themselves should routinely verify that the signature is correct. The developers have known good copies of their own gpg keys.
“Best is, if someone would just propose a PKGBUILD and 2-5 people have to say its OK and the server will build it.”
AUR doesn’t even validate your email address or use a captcha. It would be trivial to quickly create a dozen fake users to independently “confirm” that a malicious PKGBUILD was fine. If you mean 2-5 developers have to verify it, then this still doesn’t address the problem of the mirrors being compromised and the package modified by an attacker.
“I think this assumes more security than it really gives. Mostly there is no real basis to trust each other in the team, just because they have provided nice PKGBUILDs before they could still go mad.”
The assumption is that developers can be trusted. If a developer goes mad, their key can be removed from the keyring and the packages they have signed will no longer be installed (without being forced). This is no worse than it is now as far as developers sabotaging packages, but it does help guard against outsiders compromising servers and modifying packages. The best you can do is require multiple developers to sign off on a package, but even then there’s no guarantee. You can’t use Arch, or any other distribution, without trusting the developers to some extent.
“Pretend I’m an attacker. And I have access to the server ie. the package files and the db. I could build a new archlinux-keyring package with my key in it, sign that package with my key, and then sign any packages that I decide to modify maliciously with my key as well.”
If you’re a developer, yes, there’s nothing preventing you from doing that. See the paragraph before this one. If you’re not, you wouldn’t have the necessary gpg key to sign the archlinux-keyring package.
“Anyone ever heard of more than 10 cases of a malicious pkg doing major damage?”
Maybe it has happened once, maybe a dozen times, maybe never. This has absolutely no bearing on the fact that it CAN happen. It may be unlikely, but you can’t assume that it will not happen to you. There’s no reason to knowingly leave any more security holes than necessary in your distribution system. There are possible holes inherent in trusting the system (what happens if a developer is the attacker?), but that’s no reason to not fix as many possible security problems as you can.
Of course, it doesn’t replace you as an admin. You can make your keyring as you want. The only *default* behavior I would personally expect from Archlinux is to provide a keyring. Trust people in it or not, that’s up to you. Trust the fact that you got the keyring Aaron wrote or not. This system will only *reduce* risks anyway, like any other. What if the packager is malicious? Well, *you* trusted him (maybe implicitly), you were wrong. But pacman ensured he trusted his package (by signing), him and not some strange guy from the Moon with ice creams instead of hands who used an server hole but visibly not a keyboard. What if the upstream author was malicious? I don’t have a solution, there’s no tool other than a (hypothetical) TRUE genius brain to get sure a base GNU/Linux system doesn’t include malicious code. But if you want “true” security and are this genius, then you can use a source distribution and review every single line of code. You might want to bootstrap the whole system by writing your own OS (assembler in binary code, compiler in assembly language, all this work directly with a magnet on your hard drive…). Any CPU you didn’t make with your own body is a potential hole itself. Maybe atoms by themselves are security holes! Except in maths, security is all about compromises. That’s why we use both formal and computational models. And I had a lot of fun writing this comment.
I don’t really care, because I trust my mirror, which I maintain myself. But that can be a good idea if you don’t.
I think you can do easier than a keyring and so on: put a separate file with the md5 (or whatever you want) signs of all the package files on each repo, and a separate line in pacman.conf to specify the server to fetch this file. Of course you shouldn’t specify the one you use for packages. That way, a malicious attacker would have to compromise two servers instead of one. You could also add the possibility to compare the file with one from a third server if you’re paranoid…
You wouldn’t have to put the signs in the desc file too, because they would be re-computed by each user on his own computer. So, no need to add anything into the actual packages to make it work…
Your mirror has to mirror something… what if the server it mirrors is compromised and hosts compromised packages, which then propagate to your mirror?
I sync on a french public mirror I trust too, which itself syncs on archlinux.org. I also think the risk of malicious attacks is not that high. But that’s also beacuse I don’t even really care if a package I install wipes my DD since I save every important thing I do on an external media.
I love confidentiality. Even by compromising my EEEPC, someone might steal all my private data, including private keys which give access to a lot more stuff than the 4GB of this laptop, etc. And I don’t trust all the Wifi connections I use when I install some random console tool.
I’d really like to see this as it has been a big concern for me ever since I’ve started using arch linux! Thanks for doing this!
Are you aware of gpg command-option -a?
You dont need base64 from coreutils to handle/create an ASCII signature.
But I welcome your efforts on introducing signatures. Actually in gnuffy we already use signatures (and as we use lots of archlinux packages, its a pain that archlinux doesn’t sign) (especially as they do not provide accurate filesizes but fakeable md5sums only))
Please continue your good work!
Well, somebody kick some other bodies to implement this. Signed packages would instantly make me switch from Gentoo.
Things are going pretty slow. I finally don’t have much time but kept interest on this; toofishes’ contributions made me realize he could be a lot faster than I am and that kinda discourage me ;)
The answer to all this is very, very simple:
1) Signed packages provide more security over non-signed. That’s a matematical and logical fact.
2) It is much harder to break into specific server and change keys (while planting malware onto a mirror), than to break into any of the many mirrors and plant malware, without having to break into specific server and hijack keys.
3) Trusting a signature that _may_ be hacked one day is not lowering any security of having no signature to begin with (see point 1).
4) Frequency, or absence thereof, of planted malware attacks in the past is not an argument. One time is enough to make serious damage, if only to one server or desktop. Do you want that one computer to be _yours_? I don’t.
Absence of known attacks does not mean there is no interest, it could mean ( and probably does) that the systems are secure enough to be (extremely) difficult to hack into.
5) Systems can be employed (ala snort) that monitor for any intrusion. This in fact leaves the majority of trust, then, into the admin who uploads keys manually. Hacking such a system is exponentially more difficult.
6) Subtle “attacks”, ie. planting backdoors silently, is more evil and more profitable than overt attack that might be discovered immediately. Short of building your packages from source (that you went through to see if the code is allright, there is no certainty that existing packages are not already infected by a backdoor or whatever.
6a) If I wanted to build my OS from source, I’d go Gentoo.
7) as Linux makes its way onto the Desktop you can rest assured more of such attacks will be attempted.
There is simply no argument, signing is mandatory for anything you are going to install. I really want to switch to Arch Linux, but this is the only thing stopping me so far.
[...] found an interesting blogpost about archlinux and package signing at http://gcarrier.koon.fr/2008/06/03/packages-signing-in-pacman-archlinux-getting-secured/ and now I’m asking if it will be implemented in the near future. Any [...]
Package signing? Definitely… I am for!
I’m still an Archlinux user, but I’m not really happy with it, because of the missing signatures.
Please implement this, everything could be so perfect!
Is there an indication when this can be implemented?
I have just switched to Arch Linux and it works like a charm!
Unfortunately I have found out about Arch not signing its packages afterwards. I had just expected that this feature would be featured by any modern Linux distro.
Not signing packages is definitely not acceptable for any distro, neither source nor binary ones.
If this is not going to be implemented in the near future I will have to leave Arch because I cannot live with this kind of bad conscience for a long time.
In the comments above there are some people complaining about sigs with very dump arguments. It seems to me that are quite many people without much knowledge about security and cryptography. If you need help implementing this, feel free to ask for certain support by e-mail. I am not the best programmer (as I had few time to relearn programming after switching from Windows to Linux) but I do know the underlying crypto techniques and general stuff.
Just want to add, I hope this is added, and there another reason it would be helpful. People who upload to the AUR could sign their packages, and then if you trust the uploader’s key, you can skip the whole “THIS PACKAGE WILL KILL YOUR FAMILY (Y/N)” dialogue (and not requiring you to always skip the scary message means the scary message will be more meaningful).
+1 поддерживаю