FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 12-08-2010, 05:50 PM
James Ralston
 
Default hosted reproducible package building with multiple developers?

On 2010-12-08 at 13:07-05 seth vidal <skvidal@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
 
Old 12-08-2010, 05:52 PM
seth vidal
 
Default 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 <skvidal@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
 
Old 12-08-2010, 08:00 PM
"Richard W.M. Jones"
 
Default 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
 
Old 12-08-2010, 08:40 PM
Till Maas
 
Default hosted reproducible package building with multiple developers?

On Wed, Dec 08, 2010 at 09:00:51PM +0000, 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-08-2010, 08:50 PM
seth vidal
 
Default 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 +0000, 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
 
Old 12-08-2010, 09:02 PM
"Richard W.M. Jones"
 
Default 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 +0000, 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
 
Old 12-08-2010, 09:12 PM
Jesse Keating
 
Default 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 +0000, 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
 
Old 12-08-2010, 09:14 PM
seth vidal
 
Default hosted reproducible package building with multiple developers?

On Wed, 2010-12-08 at 22:02 +0000, 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 +0000, 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
 
Old 12-09-2010, 07:20 AM
"Richard W.M. Jones"
 
Default 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
 
Old 12-10-2010, 12:51 PM
Daniel J Walsh
 
Default 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
 

Thread Tools




All times are GMT. The time now is 10:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org