Re: hosted reproducible package building with multiple developers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2010 01:03 PM, 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? We have been slowly looking into an SELinux solution for this. Just using koji/mock is still dangerous, since the environment is running as root and the rpm could contain stuff to attack the system. (Break out of the choot, attack other mock systems. Attack the network etc.) To make this secure, you really need a sandboxed mock. Where the mock environment runs with a context of mock_t and is isolated from other mock environments using MCS separation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0CMFAACgkQrlYvE4MpobMJXACfawU8kCL9/eWIJgk46Rrka2FZ uGEAoOFLc8aDDLGGV0ldPI3cDNP79SqS =ZCfg -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Fri, 2010-12-10 at 14:02 +, 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Fri, Dec 10, 2010 at 09:17:27AM -0500, seth vidal wrote: On Fri, 2010-12-10 at 14:02 +, 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. Hmm, it sounds very much like you ought to be able to prevent this kind of attack with clone+pivot_root, though it is likely going to be more work than a traditional chroot() based. The theory is as follows though 1. clone() with the CLONE_NEWNS set 2. Remount / with MS_PRIVATE|MS_REC flags These two steps ensure the new process has a totally private filesystem hiearchy where mount/unmount changes cannot leak back into the host OS, and also new mounts in host can't propagate down into the container process. Then the complex bit is to setup a new root 3. Create $MOCKROOTPATH 4. Create $MOCKROOTPATH/.oldroot 5. Mount tmpfs on $MOCKROOTPATH/.oldroot 6. Create $MOCKROOTPATH/.oldroot/new 7. Bind mount $MOCKROOTPATH $MOCKROOTPATH/.oldroot/new 8. chdir $MOCKROOTPATH/.oldroot/new 9. pivot_root(., .oldroot) At this point the container process has a new / filesystem that is based on what the main OS sees as $MOCKROOTPATH. The main OS' root filesystem is still (temporarily) visible to the container procss as /.oldroot. Now you'd need to bind the directory containing the RPMs to install any other data you want, and also setup the generic special mounts you might need 10. Bind mount /.oldroot/path/to/rpms /tmp/rpms 11. Mount /proc, /dev, /sys, /dev/pts etc as normal NB, devpts should have the 'newinstance flag set to ensure there's no access to /dev/pts/N nods from the main OS. Also the main OS should have been using 'newinstance' for its own mount of devpts (/me wonders if Fedora is doing that yet...it should be to ensure LXC containers have a properly isolated /dev/pts). Finally, iterate killing off all the mount points under /.oldroot, from longest path first 12. foreach mountpoint under /.oldroot umount $mountpoint The process now has a private root filesystem where it can only see files from $MOCKROOTPATH, the magic filesystems proc, devfs, sysfs, etc a private devpts, and the specific data directories you bind mount for it. Kernel bugs aside, there should be no means of escape from this private filesystem as you could with chroot. Adding CLONE_NEWPID would be worthwhile to stop the mock process seeing any other PIDs on the machine. Using cgroups device ACL controller could be used to block the cloned mock process from doing mknod in /dev to access other device nodes (ie whitelist just /dev/null /dev/zero, /dev/urandom and any /dev/pts/*). There are various other CLONE flags that lock down more things if desired, eg to hide all host network interfaces. Of course alot of this setup complexity could be avoided by using either libvirt's LXC driver or the alternative LXC commandline tools. Both of
Re: hosted reproducible package building with multiple developers?
On 2010-12-08 at 21:00+00 Richard W.M. Jones rjo...@redhat.com wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. This is a certainly true. If an attacker manages to gain control of a VM guest, he can attempt to attack the VM host. (In fact, depending on the attack, escalated privileges on the VM guest may not even be necessary.) But this is simply another instance of the generic problem of security vulnerabilities providing an avenue for privilege escalation, which isn't a problem that is unique to VMs. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? Because a security solution that trusts users not to deliberately or accidentally acquire access that they aren't [administratively] permitted to have is no solution. It would be no different than hanging a sign on the front door of my house that said, even though my door is unlocked, since stealing is wrong, I trust that no one will rob me. Furthermore, intelligent users would also refuse such an arrangement, because if the server that provides mock is rooted, the prime suspects would immediately be the mock users who did not otherwise have root privileges on the box. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Fri, 2010-12-10 at 15:06 +, Daniel P. Berrange wrote: Adding CLONE_NEWPID would be worthwhile to stop the mock process seeing any other PIDs on the machine. It's critical, or mock could ptrace some process running as root on the host and inject arbitrary code. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Fri, Dec 10, 2010 at 12:43:04PM -0500, Matt McCutchen wrote: On Fri, 2010-12-10 at 15:06 +, Daniel P. Berrange wrote: Adding CLONE_NEWPID would be worthwhile to stop the mock process seeing any other PIDs on the machine. It's critical, or mock could ptrace some process running as root on the host and inject arbitrary code. That is true. I forgot to mention that you'd probably need to block a large number capabilities while the 'root' part of mock were executing. eg while mock needs things like CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_MKNOD, etc to put down files during RPM install, you don't want it having SYS_ADMIN, MAC_ADMIN, AUDIT_CONTROL, SYS_BOOT, SYS_MODULE, or SYS_TIME and some others (PTRACE if not using CLONE_NEWPID). Regards, Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 2010-12-10 at 14:02+00 Daniel P Berrange berra...@redhat.com wrote: I'm not familiar with what attacks you can do on mocks' chroot setup offhand http://fedoraproject.org/wiki/Projects/Mock describes an easy one: $ /usr/bin/mock --init -r fedora-10-i386 $ /usr/bin/mock --shell -r fedora-10-i386 mock-chroot chmod u+s bin/bash $ /var/lib/mock/fedora-10-i386/root/bin/bash -p # cat /etc/shadow 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. There are two challenges here. First, you must be able to prevent the root user from breaking out of the chroot jail. But second, you must also prevent unprivileged users outside of the chroot jail from being able to interact with things inside the chroot jail in a manner that they can use to escalate their privileges. Setting up a setuid bash shell within the chroot jail and then invoking it via a normal user outside of the jail is the obvious example, but there are undoubtedly other avenues of attack that must be defended. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Fri, Dec 10, 2010 at 03:06:59PM +, Daniel P. Berrange wrote: The theory is as follows though 1. clone() with the CLONE_NEWNS set [...] There are various other CLONE flags that lock down more things if desired, eg to hide all host network interfaces. I don't think CLONE_* can stop them creating a /dev/hda-equivalent device node and then editing files on your real hard disk. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Fri, Dec 10, 2010 at 06:06:47PM +, Richard W.M. Jones wrote: On Fri, Dec 10, 2010 at 03:06:59PM +, Daniel P. Berrange wrote: The theory is as follows though 1. clone() with the CLONE_NEWNS set [...] There are various other CLONE flags that lock down more things if desired, eg to hide all host network interfaces. I don't think CLONE_* can stop them creating a /dev/hda-equivalent device node and then editing files on your real hard disk. That's what the cgroups device ACL I mentioned is for. You set it up to only allow /dev/null, /dev/zero similar nodes. Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Fri, Dec 10, 2010 at 01:01:56PM -0500, James Ralston wrote: On 2010-12-10 at 14:02+00 Daniel P Berrange berra...@redhat.com wrote: I'm not familiar with what attacks you can do on mocks' chroot setup offhand http://fedoraproject.org/wiki/Projects/Mock describes an easy one: $ /usr/bin/mock --init -r fedora-10-i386 $ /usr/bin/mock --shell -r fedora-10-i386 mock-chroot chmod u+s bin/bash $ /var/lib/mock/fedora-10-i386/root/bin/bash -p # cat /etc/shadow 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. There are two challenges here. First, you must be able to prevent the root user from breaking out of the chroot jail. But second, you must also prevent unprivileged users outside of the chroot jail from being able to interact with things inside the chroot jail in a manner that they can use to escalate their privileges. Setting up a setuid bash shell within the chroot jail and then invoking it via a normal user outside of the jail is the obvious example, but there are undoubtedly other avenues of attack that must be defended. Oh fun, I didn't notice the permissions in /var/lib/mock/$NAME/root were so open as to allow access from non-root users outside the chroot. That could be locked down though, so that stuff inside the chroot was only visible while on the inside. Dnaiel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 12/10/2010 10:12 AM, Daniel P. Berrange wrote: Oh fun, I didn't notice the permissions in /var/lib/mock/$NAME/root were so open as to allow access from non-root users outside the chroot. That could be locked down though, so that stuff inside the chroot was only visible while on the inside. Got patches? :) -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
2010/12/10 Matt McCutchen m...@mattmccutchen.net: On Fri, 2010-12-10 at 15:06 +, Daniel P. Berrange wrote: Adding CLONE_NEWPID would be worthwhile to stop the mock process seeing any other PIDs on the machine. It's critical, or mock could ptrace some process running as root on the host and inject arbitrary code. Wouldn't a properly set-up LXC container be a better solution here? See http://lxc.sourceforge.net/ . LXC is already packaged for Fedora, and also in RHEL6 iiuc. -- Thomas Moschny thomas.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
Till Maas wrote: I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. By does not use kvm, you mean pure software emulation? Enjoy the factor 50 slowdown! (Yes, I've tried this, it was the only way for me to build x86_64 packages locally before I got the Core 2 Duo notebook, as I only had a 32-bit-only Pentium 4 Northwood desktop and an ancient Pentium II laptop, which was of course 32-bit-only as well. A package which normally takes 10 minutes to build took 8 hours under QEMU software emulation.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
I didn't mean to say that using a VM was a bad thing. It's an obvious improvement over mock. Attacks that elevate to root in the host are in the realm of highly theoretical at the moment. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
hosted reproducible package building with multiple developers?
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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
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. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 2010-12-08 at 13:07-05 seth vidal skvi...@fedoraproject.org wrote: the mock chroots that koji uses could still be rooted by someone who can submit their own build-requirement-providing packages. Well, we vet all packages our developers submit before releasing them to our repositories, so we would catch a developer submitting (e.g.) a suid-bash-shell-1.0.0-1.el5.x86_64.rpm package. Does koji provide a mechanism for the submitter to specify his own yum repositories for mock to use? in order to protect the builders they must be: 1. disposable 2. in a vm or possibly both. Well, the ultimate protection would be to use this procedure for each build: 1. Instantiate VMs for all architectures specified by the build, via cloning known good build VMs. 2. Use koji to build on each VM. 3. Destroy each VM that was instantiated. But that's some *serious* overhead. Plus, I'm not sure that we could automate steps #1 and #3, which would be a dealbreaker. Honestly, given current trends, it might be that before too much longer, the best solution might be to simply give each developer his own VM for each OS/architecture he wants to build for, and tell him to use mock directly. Before each build, he snapshots the VM, and after each build, he reverts to the snapshot (discarding whatever changes the build process made to the system)... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, 2010-12-08 at 13:50 -0500, James Ralston wrote: On 2010-12-08 at 13:07-05 seth vidal skvi...@fedoraproject.org wrote: the mock chroots that koji uses could still be rooted by someone who can submit their own build-requirement-providing packages. Well, we vet all packages our developers submit before releasing them to our repositories, so we would catch a developer submitting (e.g.) a suid-bash-shell-1.0.0-1.el5.x86_64.rpm package. Does koji provide a mechanism for the submitter to specify his own yum repositories for mock to use? not that I'm aware of - the folks on the buildsys list who maintain koji may be able to help you more https://lists.fedoraproject.org/mailman/listinfo/buildsys Well, the ultimate protection would be to use this procedure for each build: 1. Instantiate VMs for all architectures specified by the build, via cloning known good build VMs. 2. Use koji to build on each VM. 3. Destroy each VM that was instantiated. But that's some *serious* overhead. Plus, I'm not sure that we could automate steps #1 and #3, which would be a dealbreaker. sure you can. :) I'm dabbling in that right at this moment :) Honestly, given current trends, it might be that before too much longer, the best solution might be to simply give each developer his own VM for each OS/architecture he wants to build for, and tell him to use mock directly. Before each build, he snapshots the VM, and after each build, he reverts to the snapshot (discarding whatever changes the build process made to the system)... perhaps. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, Dec 08, 2010 at 01:50:22PM -0500, James Ralston wrote: Well, the ultimate protection would be to use this procedure for each build: 1. Instantiate VMs for all architectures specified by the build, via cloning known good build VMs. 2. Use koji to build on each VM. 3. Destroy each VM that was instantiated. IIRC Seth is working on this. To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. Regards Till pgp8FYyQg4Y6e.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. the point is to make the vm's be entirely disposable. So you make the vm build the pkg in mock suck the results off destroy the vm nothing to risk, then. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, Dec 08, 2010 at 04:50:11PM -0500, seth vidal wrote: On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. the point is to make the vm's be entirely disposable. So you make the vm build the pkg in mock suck the results off destroy the vm nothing to risk, then. If we're being picky then the hypervisor might be exploited during the package build, with the exploit escalating to root on the host. It's very hard to pull this off, but with security never say 'never'. In any case, using sVirt (libvirt + SELinux) should help. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 12/08/2010 02:02 PM, Richard W.M. Jones wrote: On Wed, Dec 08, 2010 at 04:50:11PM -0500, seth vidal wrote: On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. the point is to make the vm's be entirely disposable. So you make the vm build the pkg in mock suck the results off destroy the vm nothing to risk, then. If we're being picky then the hypervisor might be exploited during the package build, with the exploit escalating to root on the host. It's very hard to pull this off, but with security never say 'never'. In any case, using sVirt (libvirt + SELinux) should help. Rich. Meh, take it one step further, do bare hardware kickstarts, then fire up the vm within... Or maybe flash the bios first, then do the kickstart then... :) -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On Wed, 2010-12-08 at 22:02 +, Richard W.M. Jones wrote: On Wed, Dec 08, 2010 at 04:50:11PM -0500, seth vidal wrote: On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: On Wed, Dec 08, 2010 at 09:00:51PM +, Richard W.M. Jones wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? I guess giving someone a shell account in a VM is usually not less safe than giving someone shell access on the host of the VM, as long as the VM does not use kvm and does not run as root. Because even if the user could break out of the VM, he still has only the same privileges as when he got a shell access to the host directly. the point is to make the vm's be entirely disposable. So you make the vm build the pkg in mock suck the results off destroy the vm nothing to risk, then. If we're being picky then the hypervisor might be exploited during the package build, with the exploit escalating to root on the host. It's very hard to pull this off, but with security never say 'never'. In any case, using sVirt (libvirt + SELinux) should help. and this is where I stop caring. putting it in a vm means I don't care about it for MY systems b/c the systems are thrown away at the end of us. How the vendor/serviceprovider/etc of the vm-hosting-infrastructure protects themselves falls into the SEP category. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
