[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

The current fedora.us buildsystem and future directions


the Fedora Project will need a buildsystem which features[1]:

Process separation:
    it MUST be impossible to kill or ptrace processes of other buildroots
    or of the system. Hiding of foreign processes SHOULD be provided.

Device/kernel protection:
    Direct hardware access through /dev/* entries or modification of
    kernel parameters through /proc MUST be impossible. Forbidding the
    creation of such special files is one way to reach it, access
    restriction another one.

Unbreakable chroots:
    it MUST be impossible for a process in a buildroot to have any kind
    of access on objects of the systems (e.g. ssh-keys), or write-access
    on other buildroots.

No buildroot-reusing:
    each build MUST happen in an environment which can not be influenced
    by previous builds in this environment. This includes both
    filesystem-objects, and processes.

    excessive resource-usage (memory, diskspace,...) of a build SHOULD
    be prevented. Usage of certain resources (e.g. network) MUST be

Good performance:
    the buildsystem SHOULD should have only a small or non-existing
    impact on the performance.

Working environment:
    building of common packages MUST succeed. This requires certain /dev
    entries, and a mounted /proc filesystem at least.

Mature userinterface:
    the system SHOULD assist the buildmaster and automate the most
    tasks, so that the spent time will be reduced to a minimum.

The reasons for these items and how they are solved in the current
fedora.us buildsystem are described in

    [HTML], respectively
    [PDF, 204 KiB]

The described buildsystem is in use for a short time only, but it
seems to be secure and to work well (it was used in the rh9* -> fc1
mass-rebuild for the most packages). There were some cases which
needed manual intervention (e.g. manual disttags), but these were

A core part is a vserver[2] capable kernel. Unfortunately, it is not
ported to the kernels which are shipped with Fedora yet, and chances are
only low that it comes into the official 2.6 kernel.

Since Red Hat wants a selfhosting buildsystem, alternatives must be
investigated. SELinux offers interesting features, but it is new and
there are lot of open questions[3]:

1. SELinux can protect foreign processes. But is it possible to hide
   them in /proc also?
2. Is chroot(2) implemented in a safe manner? Or, can parent directories
   of build-roots be protected with SELinux policies? Is a safe chroot(2)
   required at all?
3. What is the performance impact of the policy checking?
4. How can disk/memory usage restricted with SELinux? Would CKRM be an
5. Can special mount-operations (e.g. /proc filesystem) be allowed by
   the policy, or does this require userspace helper also?
6. Setup of an SELinux policy seems to be very complicated. How possible
   are holes in a setup?

It would be nice when an SELinux expert could take a look at this
questions and how it can be used in the buildsystem.

UML might be another option, but its status (chances to come into
official 2.6) and performance impact is not clear.


[1]  http://www.tu-chemnitz.de/~ensc/fedora.us-build/html/index.html#id2503177
[2]  http://linux-vserver.org
[3]  http://www.tu-chemnitz.de/~ensc/fedora.us-build/html/ar01s02.html#sec:components:selinux

Attachment: pgp00178.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]