Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

Secure Automated Builds

June 16th, 2006 by Multimedia Mike

I have a small, low-power x86 Linux box sitting on the internet. I want to use it to set up an automated build system for FFmpeg. To what end? At the outset, I would like to validate that the entire codebase builds, with all extra modules enabled, under different gcc versions and post results to a webpage.

The process outline is pretty straightforward. At periodic intervals:

  • check out a fresh copy of the FFmpeg SVN tree
  • ‘configure’ with all relevant options and the desired compiler version
  • ‘make’, log the stdout and stderr text in separate text files
  • log the status report to a public website

Pretty simple so far. Other ideas include compiling with multiple compiler versions, including cross-compilers for multiple platforms; automated regression testing; aggregated results sent to a new mailing list [insert your brainstorm here]. I’m starting small because this particular machine requires almost a half hour to complete just one FFmpeg build.

Here is the big item I’m concerned about: How to guard against malicious script injections? Not to say that I don’t trust my FFmpeg brethren but… I can’t think of a good way to end that sentence. But think about it: When you run the configuration script and Makefile, you’re executing free-form shell commands. One of the worser-case scenarios:

all:
    find / | xargs rm -rf

“But Mike,” I hear you exclaim, “as long as you run it as your own unprivileged user vs. root, it won’t destroy the entire system.” That’s terrific news; the easily replaced Linux base system would be safe. So what about running the build process as a heretofore non-existent user (something other than ‘nobody’ since a standard Linux box is going to have files owned by him)? Random shell commands could still, for example, read world-readable files and transmit them offsite. What kind of files? I’m not interested in the fine details, it’s still a security hole.

So there is the possibility of switching to the unknown user in its own chroot’d shell. Ideally, this environment would:

  • prohibit network access (setup process gets the fresh SVN tree before entering chroot shell)
  • have access to various build tools

I guess what I’m wondering is: Have these problems already been solved? Are there open source projects that already provide good solutions to these problems? Otherwise, I already know it’s a lot of work to set up such an chroot environment (and I have no idea how to prohibit network access for a particular user).

Posted in FATE Server, Open Source Multimedia | 3 Comments »

3 Responses

  1. adament Says:

    I don’t know if this is what you are looking for but I did some searches on google and this tool came to mind: http://www.jmcresearch.com/projects/jail/ apparently it’s supposed to make it easier to setup a chroot jail but I don’t know if it really helps with the network access problem. I can’t really seem to figure out how to do that but perhaps google will be of more help.

    Another idea which springs to mind is virtualisation, however since it is an old computer I don’t know how useful it would be. But take a look at Xen: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/. It seems to have really good performance(a reduction of about 1-5% compared to native linux. According to this page http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.html). UML might also be worth a look: http://user-mode-linux.sourceforge.net/

    Another approach would perhaps be to use MAC, but I have no experience with that so I don’t know how much you can tune access permissions but take a look at this article: http://security.linux.com/article.pl?sid=05/02/11/2017218.

    I hope this helps a bit.

  2. NuclearDog Says:

    FreeBSD can do what you’d like.

    You can create a jail (http://en.wikipedia.org/wiki/FreeBSD_Jail) for your build process to run in, completely isolating it from the system. As for firewalling, you’ve got a couple of options. You could firewall off the build process user (ipfw drop all from any to any uid buildproc) or, since each jail requires its own IP anyways, you could simply firewall off that IP.

    ND

  3. mangui Says:

    maybe you could have a look at the buildbot project :
    http://buildbot.sourceforge.net
    hope this inspire or help you.