Quoting Natanael Copa (nc...@alpinelinux.org): > On Fri, 17 May 2013 09:24:51 -0500 > Serge Hallyn <serge.hal...@ubuntu.com> 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 "$@" > > > 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 ------------------------------------------------------------------------------ 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
