Securing Pacman Ideas (other than signing)

tntcoda · 2011-02-26 09:10:10

Hi,

I'm interested in doing some work to secure pacman from potentially malicious maintainers. So I know there has been some work done on package signing and checking against multiple mirrors etc, but these methods all assume the attack would occur between the mirror and the end user. I think the phase between the source code repository and the mirror involving the maintainer are just as important.

With so many people are involved in package construction it's a disjointed network and requires blind trust. So using signing on packages would only allow us to verify that a package came from person X, it would not:

- Tell us if their key was (unknowingly) compromised
- Tell us if their package construction box was compromised
- Tell us if their network link was compromised
- Tell us if they are trustworthy

So I think signing works better in a distro like Redhat because it's more enterprise centric, but with Arch being much more community focused I dont think it would be very beneficial, although it would still be very beneficial but in the ideal world more is needed. Basically signing is great at preventing MITM attacks from the mirror to the user, but nothing before the mirror is protected. As an example, what's to stop a package maintainer changing a single byte in the source code to introduce a bug, it gets pushed out to thousands of people and installed with root permissions, not good...

Some ideas I was having:

- Have a trusted well audited Arch box (or small distributed cluster with regular correlation checks) doing package compilation from source, so this box would go out to the source repository pull down the code (over SSL if possible) and compile.
- It hashes every executable binary and library that is going to be installed, maybe configs to?
- It tars up this list of hashes and signs the tar with a trusted Arch root key
- A trusted hash list for package X could be pulled in by users over SSL and a scan by userspace software completed using simple hash checks.
- You could run this in real time before a package is installed, i.e pacman -S pkgX would invoke the scan before the binaries in the package are installed.

Would this work? Or is it seemingly not possible to protect people from a malicious maintainer? Or flawed idea?

Another idea that would be awesome would be if you could take a binary on a box and do a % match check to trusted source code, but I think this is probably not possible given things like compilation configs and patches etc

Allan · 2011-02-26 09:28:32

This is really nothing about securing pacman at all. It is about everything before pacman. You are right that there is nothing stopping a developer or TU uploading a broken package. In fact, even with your idea I could still create a package that could screw over many peoples systems (as root) before it was noticed.

Some comments:
1) an automated build system where people submit packages to be built would be required. People have started writing this sort of thing several times and never finished as far as I know.
2) how is having a single master key sitting on a single server more any less vulnerable to attack? That would make a single target on a single computer which if compromised would invalidate all packages. Developers signing their own packages actually limits the damage any one key compromise can do.
3) signing a file with hashes of all files is not any more secure than just signing the package (although file hashes do allow for more auditing on the users systems)

ngoonee · 2011-02-26 12:33:36

An important principle to remember is that the developers and TUs have the ability to break all your systems however they want. That's the nature of the system, if we do not trust these devs/TUs we should not use this distro.

Of course, this isn't anything new if we think about it. We trust firefox's devs implicitly, especially if running their binaries. In Gentoo, who reads through every ebuild?

The automated build system is a great idea, if someone would actually write it (and in a way scalable to all the packages we have).

Arch Linux

#1 2011-02-26 09:10:10

Securing Pacman Ideas (other than signing)

#2 2011-02-26 09:28:32

Re: Securing Pacman Ideas (other than signing)

#3 2011-02-26 12:33:36

Re: Securing Pacman Ideas (other than signing)

Board footer