Discussion summary: Mock security

[David Smith]

On Tue, 2006-06-06 at 15:50 -0500, Michael_E_Brown at Dell.com wrote:
> Current mock contains one SUID program, mock-helper, that can be run
> only by people in the 'mock' group. This helper script performs many
> actions as root that cannot be done by the main mock python executable.
> There is one question we need to answer in regards to the current
> mock-helper security model. 
> 	-- Should we allow untrusted users access to the 'mock' group?
> 
> If we answer 'yes' to this question, that implies that we must make
> mock-helper bulletproof for users in the 'mock' group who wish to use
> mock-helper to leverage access to 'root' on the box.
> 
> After looking closely at the mock-helper source, I have identified
> several problematic areas, listed below. I do not believe, given the
> current state of mock-helper, that we should endorse the idea of
> allowing untrusted users access to the 'mock' group. We should very
> prominently label mock as giving, essentially, root access to each user
> you allow to run it. I believe the wiki, the help text of "mock -h", the
> mock README, and the mock man page should all be updated with this
> information.
> 
> Proposed warning text:
> ====================================================================
> Mock contains a Set-UID helper program that can only be run by users in
> the 'mock' group. Adding users to the 'mock' group is equivalent to
> giving them full root access to the OS. Do not add untrusted users to
> the 'mock' group. Mock is not designed to safely be run by untrusted
> users.
> ====================================================================

... stuff deleted ...

If you implemented all your proposed solutions, do you think that
warning could be removed?  Do you think that mock would be secure at
that point?

If the answer is no, how much effort do we want to spend here if at some
point we have to trust the users in the "mock" group anyway?

> Problem area: do_chroot()
> 	passes unchecked user data to chroot command. User can easily
> get a shell, and, for example, create device nodes.
> 
> Proposed Solution:
> 	Do not pass user-supplied data to chroot. Make an array of
> allowed commands, mock.py should just pass which command it wants to run
> from the list. Any required user input should be filtered for
> [A-Za-z0-9,+\-.], or similarly strict regexp. No extra options should be
> allowed to the command (for example, no input starting with '-')

I'm afraid you might be missing the point of the "mock chroot" command -
which is to do arbitrary things on/in the chroot.  By definition there
is no predefined list of allowed commands.

In our case, we're using mock to cross-build RPMs.  Here's how my co-
worker Clark Williams <williams at redhat.com> described it a few months
ago when he added the chroot command:

On Thu, 2006-03-02 at 10:09 -0600, Clark Williams wrote: 
> When cross-building a root filesystem, you need to bootstrap something
> we call a "sysroot", which is essentially a software development
> environment for the target system (headers and libraries mostly). The
> way we do that is we create an empty "root" and as we build RPMS
> (starting with GLIBC), we install the -devel packages into that target
> root (the sysroot). Our cross toolchains know how to access the sysroot,
> so when you compile hello.c, it gets the correct headers and libraries.
> 
> To be able to install rpms into the sysroot (which lives in the mock
> chroot) I've added a chroot command to my local copy of mock (patch
> below).

In our case the "mock chroot" command is really just a convenience, but
it is a nice big fat one.  It keeps all the mount logic and chroot logic
in one place instead of us re-inventing the wheel.  I'm hoping others
are also using mock in weird and wonderful ways.

I'm not sure I can think of a great solution to the problem of
tightening security of mock without totally removing the "mock chroot"
command, which I'm certainly not in favor of.

A "hack" solution would be to have a second group, named something like
"mockgurus", whose members would only be the only ones allowed to
execute the "mock chroot" command.  Of course we're really back in the
same security boat here, but perhaps we've shrunk the boat a bit.

-- 
David Smith
dsmith at redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)