in ubuntu and debian using the binfmt-support tool, it is possible to register
interpreters based on file magic with the binfmt module, so a mono file gets
executed by the proper mono interpreter, java by the java interpreter etc.
we recently added a qemu-arm-static package that allows executing armel
binaries under x86 systems. this package also registers with binfmt. it also
comes with a script that builds armel specific chroots (and copies the static
binary into the chroot).
now chrooting into such an armel chroot and trying to execute something another
binfmt handler is available for in the kernel (i.e. installing mono
applications in this armel chroot on a x86 system) ends up in the situation
that $interpreter of the host system gets executed instead of
$chroot/$interpreter.
the module should determine from which namespace ($chroot) the binary wanting
to execute the interpreter comes and act accordingly by executing the binary
from inside the chroot instead of the one from the host system.
given that i now could use an x86 mono or java binary from inside the chroot to
access the actual host system with them appears like a (even not actually
major) security issue.
I cannot reproduce this issue. For example, I have /tmp/test.pyc which is the python-compiled version of 'os.system(
$ hexdump -C /tmp/test.pyc | head -n1
00000000 d1 f2 0d 0a fd 34 ad 4a 63 00 00 00 00 00 00 00 |.....4.Jc.......|
$ cat /proc/sys/
enabled
interpreter /usr/bin/python2.6
flags:
offset 0
magic d1f20d0a
It does run, but it's running in the chroot (reports "jaunty" not "karmic"), and the executable launched is inside the chroot too:
$ ps auwwx | grep test
kees 10858 0.1 0.0 19028 3508 pts/9 S+ 11:13 0:00 /usr/bin/python2.6 ./test.pyc
$ ls -la /proc/10858/exe
lrwxrwxrwx 1 kees kees 0 2009-09-13 11:13 /proc/10858/exe -> /var/lib/