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.
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
>
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
