Talk about how the Invirtibuilder is insecure.

[invirt/packages/invirt-dev.git] / README.invirtibuilder

diff --git a/README.invirtibuilder b/README.invirtibuilder
index d364399..6ba5124 100644 (file)
--- a/README.invirtibuilder
+++ b/README.invirtibuilder
@@ -289,9 +289,57 @@ build daemon runs any scripts in a hook directory. The hook directory
 could contain scripts to publish the results of the build in whatever
 way is deemed useful by the developers.
 
+Security
+========
+
+As noted above, our intent was for a single instance of the
+Invirtibuilder to be used for both our trusted production environment
+and our untrusted development environment. In order to be trusted for
+the production environment, the Invirtibuilder needs to run in the
+production environment as well. However, it would be disasterous if
+access to the development environment allowed a developer to insert
+malicious packages into the production apt repository.
+
+In terms of policy, we enforce this distinction using the remctl ACL
+mechanism described in `The Build Queue`_. But is that mechanism on
+its own actually secure?
+
+Only mostly, it turns out.
+
+While actual package builds run unprivileged (with the help of the
+fakeroot_ tool), packages can declare arbitrary build dependencies
+that must be installed for the package build to run. Packages'
+maintainer scripts (post-install, pre-install, pre-removal, and
+post-removal scripts) run as root. This means that by uploading a
+malicious package that another package build-depends on, then
+triggering a build of the second package, it is possible to gain root
+privileges. Since breaking out of the build chroot as root is trivial
+[#], it is theoretically possible for developers with any level of
+access to the APT repositories to root the build server.
+
+One minor protection from this problem is the Invirtibuilder's
+reporting mechanism. A single independent malicious build can't
+compromise the build server on its own. Even if a second build
+compromises the build server, the first build will have already been
+reported through the hook mechanism described in `Build Failures`_. We
+encourage users of the Invirtibuilder to include hooks that send
+notifications of builds over e-mail or some other mechanism such that
+there are off-site records. The server will still be compromised, but
+there will be an audit trail.
+
+Such a vulnerability will always be a concern so long as builds are
+isolated using chroots. It is possible to protect against this sort of
+attack by strengthening the chroot mechanism (e.g. with grsecurity_)
+or by using a more isolated build mechanism
+(e.g. qemubuilder_). However, we decided that the security risk didn't
+justify the additional implementation effort or runtime overhead.
+
 .. _config-package-dev: http://debathena.mit.edu/config-packages
+.. _fakeroot: http://fakeroot.alioth.debian.org/
 .. _git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/
+.. _grsecurity: http://www.grsecurity.net/
 .. _Invirt: http://invirt.mit.edu
+.. _qemubuilder: http://wiki.debian.org/qemubuilder
 .. _remctl: http://www.eyrie.org/~eagle/software/remctl/
 .. _SIPB: http://sipb.mit.edu
 .. _VCS location information: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs
@@ -305,3 +353,4 @@ way is deemed useful by the developers.
        pockets with ``allow_backtracking`` set to ``True``, we don't
        create new tags for builds on pockets with
        ``allow_backtracking`` set to ``True`` either.
+.. [#] http://kerneltrap.org/Linux/Abusing_chroot