Discussion summary: Mock security

[Michael E Brown]

On Wed, 2006-06-07 at 11:13 -0400, Jeremy Katz wrote:
> David Smith wrote:
> > On Tue, 2006-06-06 at 15:50 -0500, Michael_E_Brown at Dell.com wrote:
> >> 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.
> > 
> > ... 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?
> 
> It sounds like Michael did a pretty full investigation.  And things at 
> least initially weren't bad off in this respect.

I don't want to lead anybody astray here. I am not a security expert, so
there may well be other things here that I am missing. I just pointed
out the ones that were obvious to me.

> 
> > 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?

Given the current state of mock-helper, I would say a different design
is called for, one where 'untrusted' user cannot pass any data down to a
trusted process, or as a last resort, all data that is passed is subject
to rigorous validation.


> We really want it to be pretty secure, though -- otherwise, it's a risk 
> for build farms and a future where we might try to have shell servers 
> available for all arches for people to test and debug builds.
> 

That is the thinking behind my audit.


> >> Problem area: do_chroot()
> >> 	passes unchecked user data to chroot command. User can easily
> >> get a shell, and, for example, create device nodes.
> [snip]
> > 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:
> 
> What if, instead, it chrooted + changed to the mockbuild user?  Would 
> that break your usage case?

Since the mockbuild user in the chroot == current user id non-chroot,
this should preclude some problems, the problem is that many operations
will not be able to be done by current user id due to permissions.

The two suggestions I have seen to fix the architecture here are:
  A) A daemon that runs as root. It accepts minimal 'commands' from
untrusted user and uses those commands to build the chroot.

  B) Same idea as above, but as a SUID program instead of daemon.

the problem with (B) is that it will be a C program, where (A) can be a
python executable. I think we all know which one is easier to maintain.

The problem with the implementation of this solution is that it involves
a pretty hefty rewrite of large portions of code, and then re-testing.
It is only worth this effort if somebody steps forward and says they
actually need this level of security.
--
Michael