The current fedora.us buildsystem and future directions
Enrico Scholz
enrico.scholz at informatik.tu-chemnitz.de
Fri Nov 28 05:31:07 UTC 2003
Hello,
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.
Resource-restrictions:
excessive resource-usage (memory, diskspace,...) of a build SHOULD
be prevented. Usage of certain resources (e.g. network) MUST be
prohibited
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
http://www.tu-chemnitz.de/~ensc/fedora.us-build/html
[HTML], respectively
http://www.tu-chemnitz.de/~ensc/fedora.us-build/files/buildsystem.pdf
[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
exceptions.
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
option?
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.
Enrico
Footnotes:
[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031128/67a1b55a/attachment.sig>
More information about the fedora-devel-list
mailing list