The current fedora.us buildsystem and future directions

[Colin Walters]

On Mon, 2003-12-01 at 14:51, Enrico Scholz wrote:
> walters at 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).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031201/885cb46a/attachment.sig>