Quoting Michael H. Warfield (m...@wittsend.com): > On Fri, 2013-05-17 at 09:24 -0500, Serge Hallyn wrote: > > Quoting Kaarle Ritvanen (kaarle.ritva...@datakunkku.fi): > > > On Thu, 16 May 2013, Natanael Copa wrote: > > > > > > >On Wed, 15 May 2013 13:10:06 -0500 > > > >Serge Hallyn <serge.hal...@ubuntu.com> wrote: > > > > > > > >>Quoting Kaarle Ritvanen (kaarle.ritva...@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.
I'm not quite ready to send it (and have been derailed with wanting to finish api conversion of a few commands, and other stuff next week), but I do have a working patch introducing 'lxc-ubuntu-cloud-user' template, which allows an unprivileged user to create a container, and will run everything (except the tiny program which maps uids) without root. lxc-alpine looks like it will be another good candidate for this (as is lxc-cirros). Basically anything which untars. rsync is harder (hard enough that we may never support it) and debootstrap impossible... -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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
