[opensuse-buildservice] OBS ARM build discussion I would like to start
Hi all, Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu. Because qemu is much slower them native ARM builds the external build is way behind. So for people outside of suse.com it's not really possible to fix packages as you don't know if the current status is still valid. I would like to know how the people in charge of OBS think about this? Can the current situation be changed or is this due to a security policy? Can we help to solve this issue? If so what are the problems we are facing and which security should be met? Did I leave something out or is something now correct? Regards, Joop. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Mittwoch, 21. Dezember 2011, 11:34:24 schrieb Joop Boonen:
Hi all,
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Because qemu is much slower them native ARM builds the external build is way behind.
Well, it is not that the native build is in a so much better shape ...
So for people outside of suse.com it's not really possible to fix packages as you don't know if the current status is still valid.
I would like to know how the people in charge of OBS think about this? Can the current situation be changed or is this due to a security policy?
No. It can be changed when we have arm hardware which support a safe virtualization. Or someone brings the XEN para virtualiziation for arm in a state which can be merged with our mainline kernel (I doubt it is easy).
Can we help to solve this issue? If so what are the problems we are facing and which security should be met?
Did I leave something out or is something now correct?
Actually there is another reason why we need qemu base builds. Our goal should be to make arm builds part of openSUSE:12.2 project so we get an official release. But that means the average openSUSE developer needs to be able to make arm builds and to debug it. I only see qemu as a solution here. bye adrian
Regards,
Joop. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hi,
2011/12/21 Joop Boonen
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Because qemu is much slower them native ARM builds the external build is way behind. So for people outside of suse.com it's not really possible to fix packages as you don't know if the current status is still valid.
I would like to know how the people in charge of OBS think about this? Can the current situation be changed or is this due to a security policy? Can we help to solve this issue? If so what are the problems we are facing and which security should be met?
Did I leave something out or is something now correct?
FYI, I have a scratch project trying to bootstrap a self-hosting set of native tools that can be imported to speed up ARM (and possibly other platform) builds: https://build.opensuse.org/project/show?project=home%3Amzabaluev%3ALynch%3AS... The idea is similar to what Mer folks do: natively built essential tools and the cross toolchain, installed into ARM builds using displaced "shadow" locations for libraries and other things, via magic in RPM and OBS that is yet to be done. One of the goals is to see if a runtime emulation layer like hijacking library calls (as in Scratchbox) can be avoided. Now I'm at a point where I can build binutils with a "shadow" glibc in osc chroot, but there is a problem with KVM builds in OBS, where bash fails unable to find dynamic libraries. I would like to debug this with setting LD_DEBUG, but I did not figure out yet how to do it for KVM builders, if it's even possible at all (what do KVM workers run for init, to begin with?) Hope this helps, Mikhail -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 21/12/11 07:34, Joop Boonen wrote:
Hi all,
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Huh ? LXC or simple the systemd-nspawn util does not provide enough security for building packages ? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, Dec 30, 2011 at 03:01:37PM -0300, Cristian Rodríguez wrote:
On 21/12/11 07:34, Joop Boonen wrote:
Hi all,
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Huh ? LXC or simple the systemd-nspawn util does not provide enough security for building packages ?
No. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 30/12/11 15:04, Marcus Meissner wrote:
On Fri, Dec 30, 2011 at 03:01:37PM -0300, Cristian Rodríguez wrote:
On 21/12/11 07:34, Joop Boonen wrote:
Hi all,
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Huh ? LXC or simple the systemd-nspawn util does not provide enough security for building packages ?
No.
really ? why ? or we are once again trading usability for paranoia ? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, Dec 30, 2011 at 03:05:57PM -0300, Cristian Rodríguez wrote:
On 30/12/11 15:04, Marcus Meissner wrote:
On Fri, Dec 30, 2011 at 03:01:37PM -0300, Cristian Rodríguez wrote:
On 21/12/11 07:34, Joop Boonen wrote:
Hi all,
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Huh ? LXC or simple the systemd-nspawn util does not provide enough security for building packages ?
No.
really ? why ? or we are once again trading usability for paranoia ?
We currently consider it not being able to confine root processes. If you can think a method where you can do the full build process as non-root it might be usable. https://bugzilla.novell.com/show_bug.cgi?id=708989 is our audit tracker bug, but we really have not looked that deep. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 30/12/11 15:17, Marcus Meissner wrote:
On Fri, Dec 30, 2011 at 03:05:57PM -0300, Cristian Rodríguez wrote:
On 30/12/11 15:04, Marcus Meissner wrote:
On Fri, Dec 30, 2011 at 03:01:37PM -0300, Cristian Rodríguez wrote:
On 21/12/11 07:34, Joop Boonen wrote:
Hi all,
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Huh ? LXC or simple the systemd-nspawn util does not provide enough security for building packages ?
No.
really ? why ? or we are once again trading usability for paranoia ?
We currently consider it not being able to confine root processes.
If you can think a method where you can do the full build process as non-root it might be usable.
https://bugzilla.novell.com/show_bug.cgi?id=708989 is our audit tracker bug, but we really have not looked that deep.
Ok, the above mentioned report, there is this sentence "cannot really jail a root process as all containers share the same host kernel and f.e. LKM's can easily bypass it." what does he mean with "LKM's can easily bypass it" ?.. when using systemd-nspawn the following is the expected behaviour: "Network interfaces and the system clock may not be changed from within the container. Device nodes may not be created. The host system cannot be rebooted and **kernel modules may not be loaded from within the container**" -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Le vendredi 30 décembre 2011 à 15:05 -0300, Cristian Rodríguez a écrit :
On 30/12/11 15:04, Marcus Meissner wrote:
On Fri, Dec 30, 2011 at 03:01:37PM -0300, Cristian Rodríguez wrote:
On 21/12/11 07:34, Joop Boonen wrote:
Hi all,
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Huh ? LXC or simple the systemd-nspawn util does not provide enough security for building packages ?
No.
really ? why ? or we are once again trading usability for paranoia ?
With my "lxc (open)SUSE maintainer hat", I should remind lxc upstream
strongly advise not to use LXC for security purpose, as it doesn't not
prevent (yet) privilege escalation and root separation. I will happen
one day but not yet.
--
Frederic Crozat
participants (6)
-
Adrian Schröter -
Cristian Rodríguez -
Frederic Crozat -
Joop Boonen -
Marcus Meissner -
Mikhail Zabaluev