Talk about how the Invirtibuilder is insecure.

svn path=/trunk/packages/invirt-dev/; revision=2868

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.
 
 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
 .. _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/
 .. _git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/

+.. _grsecurity: http://www.grsecurity.net/

 .. _Invirt: http://invirt.mit.edu
 .. _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
 .. _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.
        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