[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Trust in the Debian Build Process

[I'm not subscribed to debian-devel, so please cc me on responses.]


I'd like to throw in some propositions regarding the Debian build
process and it's security implications.

The essential problem we have to face is that every Debian
developper and whoever controls the machines developpers are using
has trivial root access to every Debian system his package is
installed on.

Part of this risk can be controlled by having a Debian-internal web
of trust and digitally-signed binary packages.  Publically available
source code is another point which helps exposing possible risks
from manipulated packages and tracking down those responsible for an
eventual security compromise.

There is one _very_ weak link in this chain: Currently, the user has
no way to tell that the binary package he is using was actually
generated from the published source code - usually, he won't rebuild
the packages he's installing.

One may argue that this point can be solved by the developper
confirming the correct build process using digital signatures on the
binary packages.

Anyway, this argument is short-sighted for two reasons:

- A malicious developper may hope to get away with a manipulated
  binary package.  E.g., think about an attacker doing a
  non-maintainer-upload of a security-critical package, where the
  binary package does _not_ match the published code but has a
  back-door in the compiled code.
  The NMU version of the package may soon be replaced by a new
  package from the actual maintainer, so there is a rather short
  time window in which damage may be done (and noticed).  This time
  window can be large enough to lead to some significant problems.

  (People will usually rush to install new versions of
  security-critical packages to keep their systems secure.)

- The developper's machine may have been compromised, and the
  attacker may have manipulated, e.g., some libraries linked
  statically into the package.  The developper will happily certify
  the binary package without even knowing that he is just opening up
  lots of machines.

One possible solution may look like this:

Centralize the actual build process. Use a well-defined and
well-secured set of machines for automatically building the binary
packages.  Sign the generated binary packages with a central code
signing key.  Have the maintainers sign the diff files they submit.
Provide digital signatures for the source tar balls.

Additionally, maintainers should only upload the diffs against the
canonical packages, so extra scrutinity for checking Debian packages
can be minimied.  The upstream source packages should be
automatically fetched from well-known archive sites; these archive
sites should be documented in the package documentation.

(There may other and better possibilities, and there may also be
important procedural steps in the current set-up I just don't know

Please note that this message is not about any dis-trust in the
Debian developper community - just on the opposite, I highly respect
and appreciate the work done by you, using Debian GNU/Linux on
pretty much every PC under my influence.

This message is rather about minimizing the trust that system
administrators have to put into persons completely unknown to
themselves, into the security of systems they didn't ever see.  

And it's about minimizing the risk the Debian project as a whole is
currently taking:  One incident like the thought-out scenarios from
above may be sufficient to ruin or significantly damage the trust
the Debian project is currently enjoying in the Linux Users Community.

Thanks for reading, 

Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Reply to: