Bug 14162

Summary: binfmt allows breaking out of chroots due to not respecting namespaces
Product: Other Reporter: Oliver Grawert (ogra)
Component: ModulesAssignee: other_modules
Status: CLOSED OBSOLETE    
Severity: normal CC: alan, lool, serge
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.31 and before Subsystem:
Regression: No Bisected commit-id:

Description Oliver Grawert 2009-09-11 13:02:52 UTC
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.
Comment 1 Serge Hallyn 2009-09-14 16:58:46 UTC
The binfmt_misc module opens the interpreter using 'open_exec()', which
passes AT_FDCWD to do_filp_open, so the file should be being opened
relative to current->fs_root.

Do you have a testcase which shows that is not happening, or were you
just asking for confirmation?

There is also the concern of containers being able to add handlers
through /proc/sys/fs/binfmt/.  That can be addressed overlaying /proc with
the proc-lxc fuse filesystem, which by default does not show /proc/sys
to containers at all.

Am I understanding everything correctly, and does this address your
concerns?  If not, then please set me straight and let us discuss on
the containers@lists.osdl.org mailing list.

thanks,
-serge