Ubuntu - can non-root user run process in chroot jail?
Solution 1:
On Linux the chroot(2) system call can only be made by a process that is privileged. The capability the process needs is CAP_SYS_CHROOT.
The reason you can't chroot as a user is pretty simple. Assume you have a setuid program such as sudo that checks /etc/sudoers if you are allowed to do something. Now put it in a chroot chroot with your own /etc/sudoers. Suddenly you have an instant privilege escalation.
It is possible to design a program to chroot itself and run it as a setuid process, but this is generally considered bad design. The extra security of the chroot does not motivate the security issues with the setuid.
Solution 2:
@imz--IvanZakharyaschev comments on pehrs's answer that it may be possible with the introduction of namespaces, but this hasn't been tested and posted as an answer. Yes, that does indeed make it possible for a non-root user to use chroot.
Given a statically-linked dash, and a statically-linked busybox, and a running bash shell running as non-root:
$ mkdir root
$ cp /path/to/dash root
$ cp /path/to/busybox root
$ unshare -r bash -c 'chroot root /dash -c "/busybox ls -al /"'
total 2700
drwxr-xr-x 2 0 0 4096 Dec 2 19:16 .
drwxr-xr-x 2 0 0 4096 Dec 2 19:16 ..
drwxr-xr-x 1 0 0 1905240 Dec 2 19:15 busybox
drwxr-xr-x 1 0 0 847704 Dec 2 19:15 dash
The root user ID in that namespace is mapped to the non-root user ID outside of that namespace, and vice versa, which is why the system shows files owned by the current user as owned by user ID 0. A regular ls -al root, without unshare, does show them as owned by the current user.
Note: it's well-known that processes that are capable of using chroot, are capable of breaking out of a chroot. Since unshare -r would grant chroot permissions to an ordinary user, it would be a security risk if that was allowed inside a chroot environment. Indeed, it is not allowed, and fails with:
unshare: unshare failed: Operation not permitted
which matches the unshare(2) documentation:
EPERM (since Linux 3.9)
CLONE_NEWUSER was specified in flags and the caller is in a chroot environment (i.e., the caller's root directory does not match the root directory of the mount namespace in which it resides).
Solution 3:
These days, you want to be looking at LXC (Linux Containers) instead of chroot/BSD jail. It's somewhere between a chroot and a virtual machine, giving you a lot of security control and general configurability. I believe all you need to run it as a user is to be a member of the group that owns the necessary files/devices, but there might also be capabilities/system permissions involved. Either way, it should be very doable, since LXC is quite recent, long after SELinux etc. was added to the Linux kernel.
Also, bear in mind that you can just write scripts as root but give users secure permission to run those scripts (without a password if you like, but make sure the script is secure) using sudo.
Solution 4:
The combination of fakeroot / fakechroot gives a simulacre of chroot for simple needs such as producing tar archives where files appear to be owned by root. Fakechroot manpage is http://linux.die.net/man/1/fakechroot.
You don't get any new permission though, but if you own a directory (e.g. fake-distro) before invoking
fakechroot fakeroot chroot ~/fake-distro some-command
it now look for some-command like you're root and owning everything within fake-distro.