[PATCH/next,1/1] package/lxc: security bump to version 3.2.1

- lxc switched from gnutls to openssl since version 3.2.0 and
  https://github.com/lxc/lxc/commit/fa2bb6ba532c5e7f92df8cbae50a68af519f9997
- lxc needs a glibc or musl toolchain since version 3.2.0 and
  https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d
- This version includes a security fix (named CVE-2019-5736 on runC):
  https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 package/lxc/Config.in |  5 +++--
 package/lxc/lxc.hash  |  2 +-
 package/lxc/lxc.mk    | 16 ++++++++--------
 3 files changed, 12 insertions(+), 11 deletions(-)

On Fri, 16 Aug 2019 19:03:15 +0200
Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:

> - lxc switched from gnutls to openssl since version 3.2.0 and
>   https://github.com/lxc/lxc/commit/fa2bb6ba532c5e7f92df8cbae50a68af519f9997
> - lxc needs a glibc or musl toolchain since version 3.2.0 and
>   https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d
> - This version includes a security fix (named CVE-2019-5736 on runC):
>   https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d
> 
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

We normally apply security bumps to master. But this one seems like a
quite major bump, and it also disables the package for uClibc.

Does it make sense to backport just the security fix in master ?

Thomas

Hello Thomas,

Le sam. 17 août 2019 à 15:41, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> a écrit :
>
> On Fri, 16 Aug 2019 19:03:15 +0200
> Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:
>
> > - lxc switched from gnutls to openssl since version 3.2.0 and
> >   https://github.com/lxc/lxc/commit/fa2bb6ba532c5e7f92df8cbae50a68af519f9997
> > - lxc needs a glibc or musl toolchain since version 3.2.0 and
> >   https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d
> > - This version includes a security fix (named CVE-2019-5736 on runC):
> >   https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d
> >
> > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
>
> We normally apply security bumps to master. But this one seems like a
> quite major bump, and it also disables the package for uClibc.
Yes I know that's why I marked it for next.
>
> Does it make sense to backport just the security fix in master ?
I could but this fix will add the glibc or musl toolchain dependency.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Best Regards,

Fabrice

Hello,

+Peter in Cc.

On Sat, 17 Aug 2019 21:36:27 +0200
Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:

> Hello Thomas,
> 
> Le sam. 17 août 2019 à 15:41, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> a écrit :
> >
> > On Fri, 16 Aug 2019 19:03:15 +0200
> > Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:
> >  
> > > - lxc switched from gnutls to openssl since version 3.2.0 and
> > >   https://github.com/lxc/lxc/commit/fa2bb6ba532c5e7f92df8cbae50a68af519f9997
> > > - lxc needs a glibc or musl toolchain since version 3.2.0 and
> > >   https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d
> > > - This version includes a security fix (named CVE-2019-5736 on runC):
> > >   https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d
> > >
> > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>  
> >
> > We normally apply security bumps to master. But this one seems like a
> > quite major bump, and it also disables the package for uClibc.  
> Yes I know that's why I marked it for next.
> >
> > Does it make sense to backport just the security fix in master ?  
> I could but this fix will add the glibc or musl toolchain dependency.

OK, so let's bring Peter Korsgaard in Cc. Since he maintains the
stable/LTS branches, it is important to get his call on this issue.

Thanks,

Thomas

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 >> > Does it make sense to backport just the security fix in master ?  
 >> I could but this fix will add the glibc or musl toolchain dependency.

 > OK, so let's bring Peter Korsgaard in Cc. Since he maintains the
 > stable/LTS branches, it is important to get his call on this issue.

Well, is is "complicated" ;) CVE-2019-5736 is the same issue we fixed
for runc back in February (where the fix had some fallout).

But do notice:

- Issue only applies to privileged containers, which is explicitly
  marked as unsafe by upstream - E.G. on their website:

  They're not safe at all and should only be used in environments where
  unprivileged containers aren't available and where you would trust
  your container's user with root access to the host.

  https://linuxcontainers.org/lxc/security/#LXC

- The current lxc version in 2019.02.x / 2019.05.x / 2019.08 is 3.1.0,
  which is a development version of late 2018.

- A fix is available for the current LTS version (3.0.x, supported until
  2023) and current development version (3.2.1)


So our options are basically:

- Apply the patch to master and 2019.02.x / 2019.05.x

- Revert master/2019.05.x/2019.02.x to the LTS series, 3.0.4

- Cherry pick the fix to 3.1.0 for master/2019.05.x/2019.02.x

- Ignore the issue and only apply the patch to next


I would say option 4 (ignore) or 2 (revert) sounds like the most
sensible options to me.

What do others think?

Am Fri, 16 Aug 2019 19:03:15 +0200 schrieb Fabrice Fontaine:

> Signed-off-by: Fabrice Fontaine
> <fontaine.fabrice@gmail.com>

Tested-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[build-tested using this defconfig:
BR2_x86_64=y
BR2_x86_atom=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/
tarballs/br-x86-64-musl-2019.05.1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_7=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_5_1=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_MUSL=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCAP=y
BR2_PACKAGE_LIBSECCOMP=y
BR2_PACKAGE_LXC=y]

On 27/08/2019 22:39, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
> 
> Hi,
> 
>  >> > Does it make sense to backport just the security fix in master ?  
>  >> I could but this fix will add the glibc or musl toolchain dependency.
> 
>  > OK, so let's bring Peter Korsgaard in Cc. Since he maintains the
>  > stable/LTS branches, it is important to get his call on this issue.
> 
> Well, is is "complicated" ;) CVE-2019-5736 is the same issue we fixed
> for runc back in February (where the fix had some fallout).
> 
> But do notice:
> 
> - Issue only applies to privileged containers, which is explicitly
>   marked as unsafe by upstream - E.G. on their website:
> 
>   They're not safe at all and should only be used in environments where
>   unprivileged containers aren't available and where you would trust
>   your container's user with root access to the host.
> 
>   https://linuxcontainers.org/lxc/security/#LXC
> 
> - The current lxc version in 2019.02.x / 2019.05.x / 2019.08 is 3.1.0,
>   which is a development version of late 2018.
> 
> - A fix is available for the current LTS version (3.0.x, supported until
>   2023) and current development version (3.2.1)
> 
> 
> So our options are basically:
> 
> - Apply the patch to master and 2019.02.x / 2019.05.x
> 
> - Revert master/2019.05.x/2019.02.x to the LTS series, 3.0.4
> 
> - Cherry pick the fix to 3.1.0 for master/2019.05.x/2019.02.x
> 
> - Ignore the issue and only apply the patch to next
> 
> 
> I would say option 4 (ignore) or 2 (revert) sounds like the most
> sensible options to me.
> 
> What do others think?

 I tend to lean towards option 2, but option 4 is fine as well of course.

 Note that I scheduled a discussion about this type of problem (our LTS branch
ends up with a non-LTS version) for the developer meeting.


 Regards,
 Arnout