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

[Serge Hallyn]

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 "$@" alpine-base
> >>
> >>Boy does that scare me though.
> >
> >We could inline the public key(s) in the script so we could remove the
> >'--allow-intrusted' above. But verifying the sig for the static binary
> >might be tricky without having apk-tools installed already.
> 
> Installing and executing unverified binaries is done by other templates as
> well. For example, the Fedora template downloads the mirror list using
> plain HTTP and installs packages with yum --nogpgcheck, which is
> equivalent to apk --allow-untrusted. The configure_* functions then

It's the 'wget $url | /bin/sh' that, not the apk --allow-untrusted,
that really bothers me.  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...

Note I haven't nacked this.  I was wondering what others think.

> execute some installed stuff, albeit this is done in chroot.
> 
> Would the template be less scary if it ran the statically linked apk
> in chroot? This would add some complexity, as the template would
> need to install at least static busybox and resolv.conf to the
> container root prior to invoking apk.

Yes it would make me feel a bit better.  What would really make me feel
better is if we could run any downloaded code under a different MAC
(selinux or apparmor) profile.  This might require two- or three-stage
templates.  Currently most templates first do a download_image() (into
the cache), then configure_image().

The templates would be called with all the usual args, plus a new
--{first,second.third}-stage argument.  first-stage runs
unprotected and only downloads things into cache.  second-stage
runs without ability to mount etc (but with CAP_MKNOD), and only
lays the rootfs down.  third stage does additional setup (like
setting password) and runs in the regular container MAC context/profile
and with cgroups and dropped capabilities, i.e. fully protected.

(I'm not asking you to do this)

What do others think?  Stéphane?  Dwight?

If we agree on this route, then I would take the lxc-alpine patch
as is for now.

-serge