On Fri, 2010-12-10 at 14:02 +0000, Daniel P. Berrange wrote: > 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. Since the pkgs have to be installed in the chroot as root if a user can specify their own dependencies then they can buildrequire a pkg which has a %pre or %post script which changes of the chroot and can then get to the real system root. The 'easy' solution was to have throw away vms so even if they got out they couldn't get far and the system wouldn't last long. -sv -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
