RFC: new mock: strategy, selinux, etc.

Clark Williams williams at redhat.com
Thu Jan 4 16:37:03 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

It's been some number of months (six+) since we decided to change the
way mock works. We (Michael Brown and I, with input from skvidal and
others) came up with a change in how mock launches, manages permissions
and runs privileged commands.

Old mock (mock-0.6 and previous) is a python script that does some
sanity checking (insures that the person running mock is not root and is
in the mock group) and then processes the input commands. Whenever it
needed to do something that required root privileges, old mock ran a
setuid root program named mock-helper. Mock-helper is a C program that
knows how to do a limited number of things (mount/unmount, run chroot,
etc.).

The new mock (mock-0.7 and beyond) turns things around a bit. In new
mock, the program /usr/bin/mock is a setuid:root, setgid:mock C program
that does one thing only: launches the command "python
/usr/libexec/mock.py <args>" in it's own kernel namespace. The mock.py
logic still sanity checks that the user is in the mock group and drops
privileges to the actual uid while keeping the gid of the process the
mock group. As long as we're careful to maintain proper group ownership
and permissions of created file and directories, this should go a long
way toward fixing the issues we're having with multiple users on a
single machine.

New mock will no longer use mock-helper. When it needs to do something
that requires root privileges, it will elevate it's privilege level to
root (using os.setreuid()), execute the command and then drop privileges
back to the normal user.

All of this is working, although it has not been extensively testing
(hello rawhide!). I've merged the BZ bugfixes from the mock-0.6 branch
of CVS into the head (which is the new mock) and would like to push the
new mock out to rawhide for testing.

What I'm looking for from the readership of this list is:

1. Review of strategy and code for security issues
2. Help in formulating an SELinux plan/policy for mock

We had some discussion on this issue back in June 2006, but I'd like to
look at it one more time before inflicting the new mock on the rawhide
faithful.

With regard to SELinux, I'm not sure where we need to go with mock. I
want mock to function properly and securely on a system running SELinux,
but I'm just not sure how to go about that. I've looked at the steps
mentioned on:

	http://fedoraproject.org/wiki/Extras/MockTricks

But I'm too SELinux ignorant to be able to make an informed judgment on
whether that's the right thing to do. Help on this would be greatly
appreciated.

Thanks,
Clark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFnS0vHyuj/+TTEp0RAtmUAJ0X6axpPl9UNA8JeSYBeiT++OBtQwCg1/Vj
3NGUFzEmfw5b10NJq3LhxT0=
=sIYO
-----END PGP SIGNATURE-----




More information about the Fedora-buildsys-list mailing list