Filesystem protection

Software development is a process which inevitably involves bugs, both in the software itself & the processes used to build it. The build process may accidently attempt to install files into the real root directory, rather than the virtual root when packaging as an RPM. Likewise a test suite for the application may try to write into the real root filesystem, either through coding error, or by accidentally processing a configuration file for the main system, rather than the test instance. To mitigate against these risks, it is crucial that the build process be run in a user account with no privileged access to the main filesystem. By convention, Test-AutoBuild is intended to run in a dedicatd user account called builder with a home directory in /var/builder.

Network protection

If a Test-AutoBuild instance is building modules located in a source repository from an external network, then it is important to consider the security implications of code from 3rd parties being run within the trusted intranet zone. If a 3rd part were to compromise the external source repository, trojaned code could be committed which would be checked out & on the next iteration of the build. This could potentially have full access to the network hosting the build server.

The key to mitigating this risk is to ensure that all outgoing network access from the build server is locked down. The only outbound connections that should be allowed are those to the the source control repositories, and basic network infrastructure services such as DNS and NTP. Sensitive network services such as NIS, LDAP and Kerberos should not be active on the build server.

Resource limitation

If the build instance is running on a server which is shared with other applications & users, then there is a problem of resource contention. Memory, CPU time and disk space are all finite, so resource limitation is required. Once approach is to run a completely dedicated virtual machine instance, such as User Mode Linux, within the physical host. Other systems such as Xen allow processing enclaves to be defined within the host, with a finite resource allocation.