11:31 p.m.
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:com...
5:12 p.m.
On Fri, 2003-11-28 at 00:31, Enrico Scholz wrote:
1. SELinux can protect foreign processes. But is it possible to hide
them in /proc also?
It is not currently possible to hide them. However, the entries in
/proc have the same type as the domain of the running process. So if
you don't allow any operations on that type (including getattr), then
the only thing one can tell is that a process exists at that PID.
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?
Using SELinux, a chroot doesn't provide any additional direct security.
However, you may find it convenient to use a chroot in this instance so
that different sets of packages can be installed, etc.
3. What is the performance impact of the policy checking?
Minimal; IIRC the overhead was something like 1-2% for very system-call
intensive tasks, and negligible after that.
4. How can disk/memory usage restricted with SELinux? Would CKRM be
an
option?
SELinux does not deal with resource restrictions.
5. Can special mount-operations (e.g. /proc filesystem) be allowed
by
the policy, or does this require userspace helper also?
The mount system call is restricted, yes.
6. Setup of an SELinux policy seems to be very complicated. How
possible
are holes in a setup?
Assuming that there are no bugs in the kernel, it is impossible to reach
sysadm_t (essentially equivalent to the SELinux "root") if the policy
doesn't very explicitly permit it.
I hope that answers your questions!
1:51 p.m.
walters(a)verbum.org (Colin Walters) writes:
> 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?
Using SELinux, a chroot doesn't provide any additional direct security.
However, you may find it convenient to use a chroot in this instance so
that different sets of packages can be installed, etc.
I am asking because of the following situation: there are two, (nearly)
equal buildroots A & B in the directory tree like
<basedir>
|- A
`- B
Can it be prohibited that A modifies files within B?
Would it be possible to forbid any kind of access at <basedir> for
buildprocesses?
> 5. Can special mount-operations (e.g. /proc filesystem) be
allowed by
> the policy, or does this require userspace helper also?
The mount system call is restricted, yes.
We will have to deal with
mount -t proc none <buildroot>/proc
vs.
mount --bind trojan /bin/sh
The first command MUST be supported, but the second one (inclusive
variants) be forbidden.
Enrico
2:41 p.m.
On Mon, 2003-12-01 at 14:51, Enrico Scholz wrote:
walters(a)verbum.org (Colin Walters) writes:
>> 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?
>
> Using SELinux, a chroot doesn't provide any additional direct security.
> However, you may find it convenient to use a chroot in this instance so
> that different sets of packages can be installed, etc.
I am asking because of the following situation: there are two, (nearly)
equal buildroots A & B in the directory tree like
<basedir>
|- A
`- B
Can it be prohibited that A modifies files within B?
Yes. You ensure that the set of types associated with the files and
processes of A is disjoint from those of B, and that no interaction
between them is allowed by your security policy.
Russell Coker has done work on restricting chroots with SELinux - check
out macros/chroot_macros.te in the latest sample policy.
Essentially you say something like this:
chroot(fedora_group1_t, fedora_group1)
Assuming you have defined a user fedora_group1 with role fedora_group1_r
and type fedora_group1_t.
Would it be possible to forbid any kind of access at <basedir>
for
buildprocesses?
That would be very easy, yes - just don't mention the type of <basedir>
in your policy relating to the chroot types.
We will have to deal with
mount -t proc none <buildroot>/proc
vs.
mount --bind trojan /bin/sh
The first command MUST be supported, but the second one (inclusive
variants) be forbidden.
AFAIK all these mount types are multiplexed through the one mount system
call. SELinux appears to have two checks; first, they need the "mount"
permission of the source filesystem type (such as proc_t or device_t).
However I believe a mount operation has to pass a secondary check - they
need access to the "mounton" operation for the object (file/directory)
that is the destination of the mount. So since the type of /bin/sh
would be shell_exec_t, your chrooted user presumably wouldn't have
permission to bind mount on top of it. I'll try to verify this when I
get a chance.
But as Bill said, it seems to me you could just set up the chroot
(including /proc mount), and not allow the user permission to
mount/unmount anything at all. Why would a build root need to
mount/umount proc?
By the way - one general point about SELinux. So far you have generally
been asking about access to specific files and whether or not the user
execute "mount --blah...". With SELinux, *everything* has a type. This
includes files, but also things like file descriptors and ports. Any
interaction between two types that is not expressly permitted is denied.
So you really want to think in terms of the types of objects and the
operations permitted on them, rather than secondary characteristics such
as their pathnames (/bin/sh, /var/buildroot).
8:25 p.m.
Enrico Scholz (enrico.scholz(a)informatik.tu-chemnitz.de) said:
1. SELinux can protect foreign processes. But is it possible to hide
them in /proc also?
If you cannot access it, why does it matter if it is visible?
4. How can disk/memory usage restricted with SELinux? Would CKRM be
an
option?
SELinux doesn't deal with resource limitations; that would be
handled by CKRM or something similar.
5. Can special mount-operations (e.g. /proc filesystem) be allowed
by
the policy, or does this require userspace helper also?
Not sure what you're asking here. Mount can be allowed or disallowed
based on the policy.
Bill
1:55 p.m.
notting(a)redhat.com (Bill Nottingham) writes:
> 1. SELinux can protect foreign processes. But is it possible to
hide
> them in /proc also?
If you cannot access it, why does it matter if it is visible?
E.g. 'service xyz stop' in rpm-scriptlets may have an unwanted behavior
when it sees 'xyz' processes in other "contexts".
> 5. Can special mount-operations (e.g. /proc filesystem) be
allowed by
> the policy, or does this require userspace helper also?
Not sure what you're asking here. Mount can be allowed or disallowed
based on the policy.
We have to allow *some* kinds of mount but forbid all other ones.
Enrico
2 p.m.
Enrico Scholz (enrico.scholz(a)informatik.tu-chemnitz.de) said:
>> 1. SELinux can protect foreign processes. But is it possible
to hide
>> them in /proc also?
>
> If you cannot access it, why does it matter if it is visible?
E.g. 'service xyz stop' in rpm-scriptlets may have an unwanted behavior
when it sees 'xyz' processes in other "contexts".
In general, you'll be able to tell that there's a process at pid <foo>,
but not what process it is.
Note that scriplets in a build root very very very very very rarely
need to kick processes, if ever.
>> 5. Can special mount-operations (e.g. /proc filesystem) be
allowed by
>> the policy, or does this require userspace helper also?
>
> Not sure what you're asking here. Mount can be allowed or disallowed
> based on the policy.
We have to allow *some* kinds of mount but forbid all other ones.
I would think that the buildroot filesystem setup & mounting would be
done outside of the chroot process.
Bill
9:46 a.m.
??
Enrico Scholz (enrico.scholz(a)informatik.tu-chemnitz.de) said:
> >> 1. SELinux can protect foreign processes. But is it possible to hide
> >> them in /proc also?
> >
> > If you cannot access it, why does it matter if it is visible?
>
> E.g. 'service xyz stop' in rpm-scriptlets may have an unwanted behavior
> when it sees 'xyz' processes in other "contexts".
In general, you'll be able to tell that there's a process at pid <foo>,
but not what process it is.
Note that scriplets in a build root very very very very very rarely
need to kick processes, if ever.
One particularly embarassing test run of mach comes to mind where I
tried rebuilding and installing the patched openssh rpms and it shut
down the sshd process in the main context because the install scriptlet
restarts sshd. So it might happen very very very very rarely, but it
was also very very very very painful at that particular time.
So I'm down with Enrico, as always.
Thomas
4:33 p.m.
On Fri, 2003-11-28 at 00:31, Enrico Scholz wrote:
1. SELinux can protect foreign processes. But is it possible to hide
them in /proc also?
It is not currently possible to hide them. However, the entries in
/proc have the same type as the domain of the running process. So if
you don't allow any operations on that type (including getattr), then
the only thing one can tell is that a process exists at that PID.
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?
Using SELinux, a chroot doesn't provide any additional direct security.
However, you may find it convenient to use a chroot in this instance so
that different sets of packages can be installed, etc.
3. What is the performance impact of the policy checking?
Minimal; IIRC the overhead was something like 1-2% for very system-call
intensive tasks, and negligible after that.
4. How can disk/memory usage restricted with SELinux? Would CKRM be
an
option?
SELinux does not deal with resource restrictions.
5. Can special mount-operations (e.g. /proc filesystem) be allowed
by
the policy, or does this require userspace helper also?
The mount system call is restricted, yes.
6. Setup of an SELinux policy seems to be very complicated. How
possible
are holes in a setup?
Assuming that there are no bugs in the kernel, it is impossible to reach
sysadm_t (essentially equivalent to the SELinux "root") if the policy
doesn't very explicitly permit it.
I hope that answers your questions!
7449
days inactive
7454
days old
8 comments
4 participants
participants (4)
-
Bill Nottingham -
Colin Walters -
Enrico Scholz -
Thomas Vander Stichele