-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
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:
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
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
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
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
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
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
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
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,
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:
$
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.
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
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!
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:
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.
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
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
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
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.
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
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
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
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
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
25 matches
Mail list logo
