On Wed, Dec 08, 2010 at 01:07:32PM -0500, seth vidal wrote: > On Wed, 2010-12-08 at 13:03 -0500, James Ralston wrote: > > Riddle me this. > > > > We want to provide a server for developers within our organization to > > build RPM packages for use within our organization. > > > > These are our requirements: > > > > 1. The developers must not be able to leverage the package build > > process to obtain root access on the server. > > > > 2. If a package has a build dependency that is not explicitly > > specified, the build must fail. > > > > 3. If two developers are building packages simultaneously, their > > builds must not conflict. > > > > The only way satisfy requirements #2 and #3 is to use a chroot'ed > > build environment. > > > > mock(1) uses a chroot'ed build environment, but mock fails requirement > > #1, as anyone in the "mock" group can trivially root the box. > > > > I think that koji would satisfy all three requirements, because koji > > uses mock to build, but doesn't allow developers to interface with > > mock directly. But setting up a koji infrastructure seems like a > > highly non-trivial task. > > > > Is there really no way to meet all three of these requirements without > > going the full-blown koji route? > > > > the mock chroots that koji uses could still be rooted by someone who can > submit their own build-requirement-providing packages. > > in order to protect the builders they must be: > 1. disposable > 2. in a vm > > or possibly both. I'm not familiar with what attacks you can do on mocks' chroot setup offhand, but perhaps it is possible to avoid them by also leveraging some of the new kernel container features which allow you to build stronger virtual root, without going to the extreme of a full VM. Regards, Daniel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
