Changeset 2868


Ignore:
Timestamp:
Jan 9, 2010, 12:36:45 PM (15 years ago)
Author:
broder
Message:

Talk about how the Invirtibuilder is insecure.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/packages/invirt-dev/README.invirtibuilder

    r2858 r2868  
    290290way is deemed useful by the developers.
    291291
     292Security
     293========
     294
     295As noted above, our intent was for a single instance of the
     296Invirtibuilder to be used for both our trusted production environment
     297and our untrusted development environment. In order to be trusted for
     298the production environment, the Invirtibuilder needs to run in the
     299production environment as well. However, it would be disasterous if
     300access to the development environment allowed a developer to insert
     301malicious packages into the production apt repository.
     302
     303In terms of policy, we enforce this distinction using the remctl ACL
     304mechanism described in `The Build Queue`_. But is that mechanism on
     305its own actually secure?
     306
     307Only mostly, it turns out.
     308
     309While actual package builds run unprivileged (with the help of the
     310fakeroot_ tool), packages can declare arbitrary build dependencies
     311that must be installed for the package build to run. Packages'
     312maintainer scripts (post-install, pre-install, pre-removal, and
     313post-removal scripts) run as root. This means that by uploading a
     314malicious package that another package build-depends on, then
     315triggering a build of the second package, it is possible to gain root
     316privileges. Since breaking out of the build chroot as root is trivial
     317[#], it is theoretically possible for developers with any level of
     318access to the APT repositories to root the build server.
     319
     320One minor protection from this problem is the Invirtibuilder's
     321reporting mechanism. A single independent malicious build can't
     322compromise the build server on its own. Even if a second build
     323compromises the build server, the first build will have already been
     324reported through the hook mechanism described in `Build Failures`_. We
     325encourage users of the Invirtibuilder to include hooks that send
     326notifications of builds over e-mail or some other mechanism such that
     327there are off-site records. The server will still be compromised, but
     328there will be an audit trail.
     329
     330Such a vulnerability will always be a concern so long as builds are
     331isolated using chroots. It is possible to protect against this sort of
     332attack by strengthening the chroot mechanism (e.g. with grsecurity_)
     333or by using a more isolated build mechanism
     334(e.g. qemubuilder_). However, we decided that the security risk didn't
     335justify the additional implementation effort or runtime overhead.
     336
    292337.. _config-package-dev: http://debathena.mit.edu/config-packages
     338.. _fakeroot: http://fakeroot.alioth.debian.org/
    293339.. _git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/
     340.. _grsecurity: http://www.grsecurity.net/
    294341.. _Invirt: http://invirt.mit.edu
     342.. _qemubuilder: http://wiki.debian.org/qemubuilder
    295343.. _remctl: http://www.eyrie.org/~eagle/software/remctl/
    296344.. _SIPB: http://sipb.mit.edu
     
    306354       create new tags for builds on pockets with
    307355       ``allow_backtracking`` set to ``True`` either.
     356.. [#] http://kerneltrap.org/Linux/Abusing_chroot
Note: See TracChangeset for help on using the changeset viewer.