How can I force chrooted programs to use a virtual ethernet device?

Question

First off, this is not for security reasons, or for use in a production environment. It's because I want to mess around with different configuration management systems on relatively low-spec workstation, without using VMs (time and resource overhead) or LXC (version requirements and unneeded complexity). Chroots are relatively insecure, but they're also quick and painless to set up.

Anyway: given a chroot environment and a virtual ethernet interface (eth0:1 or such), how can I make sure that programs in the chroot always use the virtual interface?

Note that I don't need true network isolation, where the real interface can't be seen inside the chroot. I just want chrooted programs to answer to a different IP address than the host (or other chroots), so I can use server/client setups properly with e.g. Puppet.

The host is running Debian Wheezy x64.

Perhaps I am approaching this the wrong way. What I want is to have several chroots and be able to access each by hostname from the host system. Is that possible?

Answer 1

Chroot is of no help here. It only affects file names, not networking and other features.

Modern versions of Linux offer a way to virtualize certain aspects of the environment piecemeal, via namespaces. In addition to the traditional virtualization of filenames through chroot (so a chrooted process won't see files outside the chroot), you can virtualize process IDs (so a process inside a PID namespace won't be able to signal or trace processes outside the namespace), users (so user 1234 inside the user namespace is independent of user 1234 outside the namespace), etc. Of interest to you are network namespaces, in which processes have their own network interfaces, IP addresses, routing, etc.

I recommend reading the excellent LWN article series by Michael Kerrisk, at least the introduction and the article on network namespaces.

Network namespaces have been around since kernel 2.6.29 (with a partial implementation available in earlier versions), so they're available on all contemporary distributions apart from RHEL5/CentOS5. Starting with kernel 3.8, you can even combine a network namespace with a user namespace and perform the network setup inside the namespace, without having root permissions outside the namespace; with earlier kernels such as the 3.2 on wheezy, you need root access in the host system to create the user namespace in the first place. Userland tools have been slower in coming than the kernel features, so many current systems don't have all the tools to make full use of the kernel features. Debian wheezy comes with unshare, which is enough to create that namespace, but lacks the shell wrapper nsenter around setns to act inside a namespace from the host (it entered unstable in July).

See Command to run a child process "offline" (no external network) on Linux for a simple example of creating a network namespace. Scott Lowe's blog has a more detailed tutorial.

Answer 2

Answer: as far as I can tell from fairly extensive Googling, lack of network namespacing in chroot does in fact make this impossible. You cannot assign a chroot environment its own IP, its own hostname or FQDN, or anything along those lines, by any means.

Chroot is useful for securing single programs or daemons. For creating any kind of isolated test system, it appears to be mostly useless.