Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am planning to set up a few chroot jails for some users to run/test Java applications (lets just assume each application is untrusted). Is there any risk involved with mounting /dev and /proc into each jail? If there is, what steps can be taken to get rid of this risk?

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

Exposing /proc and /dev exposes some more information and grants more rights to the users inside the jail.

Beware that uids and gids may be different inside and outside the jail. For instance, inside the jail, user "x" may be member of group 123, which in the jail is for "users" while on the system is for "disk". By bind-mounting /dev, you would grant them access to raw disk devices which would allow them virtually root access and get out of the jail.

I would not bind-mount /dev. Only create a few devices in there that the java application may need (null, tty, zero...) with the proper ownership and rights.

Have you considered linux containers instead of chroot jails which would isolate them more (lxcs are just a step further to chroot jails).

share|improve this answer
All of the answers were really informative. I've chosen this one because it was the most complete answer and warned me about the different uid/gid issue. Thanks sch –  David Oct 10 '12 at 5:33
add comment

This is quite a big subject, and quite a lot has been written about it on the web, so I'd encourage you to read around a little.

The basic summary is that chroot was never designed as a security feature. There are many ways a root user can 'escape' a chroot jail, and quite a few ways a normal user can escape. For example, the chroot does not have a separate process space, so a process within the chroot can 'attach' to any external process using the normal debug mechanisms. Some modern distros have protection enabled that would foil that particular attack, but not all. In any case, a root user is immune to almost all such protection devices, and there's nothing to stop it mounting any file-system it chooses.

LXC is better, and is also built-in to many modern distros (I believe) but suffers from some of the same issues (in particular, the /sys filesystem is open to abuse).

OpenVZ is supposedly safer, but it's a lot harder to set up, and I've not tried it myself.

share|improve this answer
add comment

By mounting /proc into a chroot, all users in the chroot can kill processes outside the chroot if they have the same permissions as some user outside. For example a user test can kill processes from outside the chroot by the user test (maybe it's the user-ID and not the username).

By mounting /dev you give access to the available devices, but this can be controlled by the group permissions of every devicefile. If the users inside the chroot aren't members of the according groups, they aren't able to do any harm (or anything at all, if to restricted).

EDIT: Killing processes is possible without having /proc mounted. (thanks sch)

share|improve this answer
You don't let random users run untrusted code as root. If you're running as root, you almost certainly don't need /proc to cause mayhem. –  Michael Kjörling Oct 5 '12 at 8:28
@Michael Kjörling Corrected and improved my answer accordingly. –  FSMaxB Oct 5 '12 at 10:28
@FSMaxB, you don't need /proc to kill a process. Having /proc makes it easier to find out what those processes are though. –  Stephane Chazelas Oct 5 '12 at 10:43
@sch Thanks. I didn't know that. –  FSMaxB Oct 5 '12 at 10:49
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.