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

[Natanael Copa]

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).

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

> 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...

If you download and extract a tarball into a dir you intend to chroot
into, then you could always overwrite the etc/passwd before chroot? The
passwd is no problem. The binaries you run in there are.

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

I wouldn't blame anyone for nacking it and I think we (Alpine Linux) can
do better.

> > 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.

As I said, running as root in a chroot offers basically no protection.

> 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().

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.

> 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.

Well, one of the fundamental ideas with apk-tools package manager is
to download and extract in one shot and do the cryptographic
verification on the fly (while waiting for http io). When other package
managers are done downloading and can start verify the pgp signature,
apk-tools is already done.

I looked at the ubuntu and debian templates and I find the caching
feature pretty cleaver. I didn't bother implement it for Alpine Linux
though because the minimal rootfs is only 6MB (which is 2% of the
'debian' size) You could in other words install 50 Alpine containers
while setting up the first debian 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.

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
--allow-untrusted in the same shot and you will at no point run
anything that has not been cryptographically verified.


-nc