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

[Michael H. Warfield]

On Fri, 2013-05-17 at 09:24 -0500, Serge Hallyn 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 "$@" 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...

As a security researcher (my day job), I have to say, now that you
specifically pointed it out, that makes the hair on the back of my neck
stand up.  Even if we only allow a well controlled URL we're requesting,
the thought of blindly piping the data returned into a shell scares the
crap out of me, especially since this would presumably be running as
root.  If there was some way to download it to a file and verify its
contents (md5, sha1, sha256 or -preferably- PGP signature) BEFORE
sending it into a shell, that would make me feel a lot more comfortable.

> 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
> 
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Lxc-devel mailing list
> Lxc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130517/2e6a5c8a/attachment.pgp>