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