[lxc-devel] [PATCH] lxc-alpine: download statically compiled package manager if not available on host

[Serge Hallyn]

Quoting Natanael Copa (ncopa at alpinelinux.org):
> On Fri, 17 May 2013 09:24:51 -0500
> Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> 
> > Quoting Kaarle Ritvanen (kaarle.ritvanen at datakunkku.fi):
> > > On Thu, 16 May 2013, Natanael Copa wrote:
> > > 
> > > >On Wed, 15 May 2013 13:10:06 -0500
> > > >Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > > >
> > > >>Quoting Kaarle Ritvanen (kaarle.ritvanen at datakunkku.fi):
> > > >>...
> > > >>>+        wget="wget -O - $repository/x86"
> > > >>..
> > > >>>+        $wget/apk-tools-static-$apk_version.apk | \
> > > >>>+            tar -Oxz sbin/apk.static > $apk || return 1
> > > >>>+        chmod u+x $apk
> > > >>>+
> > > >>>+        apk_opts="$apk_opts --allow-untrusted"
> > > >>>+    fi
> > > >>>+
> > > >>>+    $apk add -U --initdb --root $rootfs $apk_opts "$@"
> 
> > It's the 'wget $url | /bin/sh' that, not the apk --allow-untrusted,
> > that really bothers me.
> 
> He is not really piping anything directly to shell. He is piping it to
> tar, which will extract a sbin/apk.static (a temp static package
> manager binary in case its missing in first place).

and execute it.

> It *is* scary that the binary is not checked against anyting, no https
> certificate, no pgp signature, no nothing.

Right.

> > I do see that for instance feeding a
> > tar file with malicious /bin/passwd, which templates later run
> > under a regular chroot, could be just as easy...
> 
> I don't really understand what you mean with this...

In the ubuntu-cloud template we wget a tarball which is the rootfs for
the container, extract it, then chroot into it and run /bin/passwd to
set the initial user's password, without any change in MAC context.
So if someone can slip you a tarball from a compromised server, you
have root on your system running a potentially malicious program.

...

> and the code needs to check if you have selinux and if not fall back to
> apparmor. The patch is on here for convenience so it "just works"
> on distros who don't ship an apk-tools package. apparmor/selinux would
> be too much cost/work compared to benefit in my opinion.

It wouldn't be just in response to this.  It would be for all
templates.

But,

...

> Kaarle, I have an idea that should be doable without too much effort.
> 
> When building the apk.static we also create a signature using the
> private keys found on the build box, we ship it within the
> apk-tools-static package (as sbin/apk-tools.static.RSA<keyname> or
> similar) The official build servers would have the official build
> key(s) and we can embed the official public key(s) in the template.
> They don't change that often.
> 
> 
> The template script would look something like:
>   
>   wget="wget -O - $repository/x86"
>   ...
>   $wget/apk-tools-static-$apk_version.apk | \
>     tar -C $tmpdir -z sbin/apk.static sbin/apk.static.RSA* \
>     || return 1
> 
>   # use openssl to verify the RSA sig here against the emedded key
>   ...
> 
>   apk=$tmpdir/sbin/apk.static
>   chmod u+x $apk
>   ...etc...
> 
> If we embed the pub keys in the script we can also get rid of the

So long as you mean embed the pub keys into the lxc template, that
would be great.

And I think I'll pursue the same for ubuntu-cloud and cirros
templates.

> --allow-untrusted in the same shot and you will at no point run
> anything that has not been cryptographically verified.

Sounds great - thanks.

-serge