Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
JAIL(8)			FreeBSD	System Manager's Manual		       JAIL(8)

     jail -- create or modify a	system jail

     jail [-dhi] [-J jid_file] [-l -u username | -U username] [-c | -m]
	  [parameter=value ...]
     jail [-hi]	[-n jailname] [-J jid_file] [-s	securelevel]
	  [-l -u username | -U username] [path hostname	[ip[,..]] command ...]
     jail [-r jail]

     The jail utility creates a	new jail or modifies an	existing jail, option-
     ally imprisoning the current process (and future descendants) inside it.

     The options are as	follows:

     -d	     Allow making changes to a dying jail.

     -h	     Resolve the host.hostname parameter (or hostname) and add all IP
	     addresses returned	by the resolver	to the list of ip addresses
	     for this prison.  This may	affect default address selection for
	     outgoing IPv4 connections of prisons.  The	address	first returned
	     by	the resolver for each address family will be used as primary
	     address.  See the ip4.addr	and ip6.addr parameters	further	down
	     for details.

     -i	     Output the	jail identifier	of the newly created jail.

     -n	jailname
	     Set the jail's name.  This	is deprecated and is equivalent	to
	     setting the name parameter.

     -J	jid_file
	     Write a jid_file file, containing jail identifier,	path, host-
	     name, IP and command used to start	the jail.

     -l	     Run program in the	clean environment.  The	environment is dis-
	     carded except for HOME, SHELL, TERM and USER.  HOME and SHELL are
	     set to the	target login's default values.	USER is	set to the
	     target login.  TERM is imported from the current environment.
	     The environment variables from the	login class capability data-
	     base for the target login are also	set.

     -s	securelevel
	     Set the kern.securelevel MIB entry	to the specified value inside
	     the newly created jail.  This is deprecated and is	equivalent to
	     setting the securelevel parameter.

     -u	username
	     The user name from	host environment as whom the command should

     -U	username
	     The user name from	jailed environment as whom the command should

     -c	     Create a new jail.	 The jid and name parameters (if specified)
	     must not refer to an existing jail.

     -m	     Modify an existing	jail.  One of the jid or name parameters must
	     exist and refer to	an existing jail.

     -cm     Create a jail if it does not exist, or modify a jail if it	does

     -r	     Remove the	jail specified by jid or name.	All jailed processes
	     are killed, and all children of this jail are also	removed.

     At	least one of the -c, -m	or -r options must be specified.

     Parameters	are listed in ``name=value'' form, following the options.
     Some parameters are boolean, and do not have a value but are set by the
     name alone	with or	without	a ``no'' prefix, e.g.  persist or nopersist.
     Any parameters not	set will be given default values, often	based on the
     current environment.

     The pseudo-parameter command specifies that the current process should
     enter the new (or modified) jail, and run the specified command.  It must
     be	the last parameter specified, because it includes not only the value
     following the `=' sign, but also passes the rest of the arguments to the

     Instead of	supplying named	parameters, four fixed parameters may be sup-
     plied in order on the command line: path, hostname, ip, and command.  As
     the jid and name parameters aren't	in this	list, this mode	will always
     create a new jail,	and the	-c and -m options don't	apply (and must	not

     Jails have	a set a	core parameters, and modules can add their own jail
     parameters.  The current set of available parameters can be retrieved via
     ``sysctl -d security.jail.param''.	 The core parameters are:

     jid     The jail identifier.  This	will be	assigned automatically to a
	     new jail (or can be explicitly set), and can be used to identify
	     the jail for later	modification, or for such commands as jls(8)
	     or	jexec(8).

     name    The jail name.  This is an	arbitrary string that identifies a
	     jail (except it may not contain a `.').  Like the jid, it can be
	     passed to later jail commands, or to jls(8) or jexec(8).  If no
	     name is supplied, a default is assumed that is the	same as	the

     path    Directory which is	to be the root of the prison.  The command (if
	     any) is run from this directory, as are commands from jexec(8).

	     A comma-separated list of IPv4 addresses assigned to the prison.
	     If	this is	set, the jail is restricted to using only these
	     address.  Any attempts to use other addresses fail, and attempts
	     to	use wildcard addresses silently	use the	jailed address
	     instead.  For IPv4	the first address given	will be	kept used as
	     the source	address	in case	source address selection on unbound
	     sockets cannot find a better match.  It is	only possible to start
	     multiple jails with the same IP address, if none of the jails has
	     more than this single overlapping IP address assigned to itself.

     ip4     Control the availablity of	IPv4 addresses.	 Possible values are
	     ``inherit'' to allow unrestricted access to all system addresses,
	     ``new'' to	restrict addresses via ip4.addr	above, and ``disable''
	     to	stop the jail from using IPv4 entirely.	 Setting the ip4.addr
	     parameter implies a value of ``new''.

     ip6.addr, ip6
	     A list of IPv6 addresses assigned to the prison, the counterpart
	     to	ip4.addr and ip4 above.

	     Hostname of the prison.  Other similar parameters are
	     host.domainname, host.hostuuid and	host.hostid.

     host    Set the origin of hostname	and related information.  Possible
	     values are	``inherit'' to use the system information and ``new''
	     for the jail to use the information from the above	fields.	 Set-
	     ting any of the above fields implies a value of ``new''.

	     The value of the jail's kern.securelevel sysctl.  A jail never
	     has a lower securelevel than the default system, but by setting
	     this parameter it may have	a higher one.  If the system
	     securelevel is changed, any jail securelevels will	be at least as

	     The number	of child jails allowed to be created by	this jail (or
	     by	other jails under this jail).  This limit is zero by default,
	     indicating	the jail is not	allowed	to create child	jails.	See
	     the Hierarchical Jails section for	more information.

	     The number	of descendents of this jail, including its own child
	     jails and any jails created under them.

	     This determines which information processes in a jail are able to
	     get about mount points.  It affects the behaviour of the follow-
	     ing syscalls: statfs(2), fstatfs(2), getfsstat(2) and fhstatfs(2)
	     (as well as similar compatibility syscalls).  When	set to 0, all
	     mount points are available	without	any restrictions.  When	set to
	     1,	only mount points below	the jail's chroot directory are	visi-
	     ble.  In addition to that,	the path to the	jail's chroot direc-
	     tory is removed from the front of their pathnames.	 When set to 2
	     (default),	above syscalls can operate only	on a mount-point where
	     the jail's	chroot directory is located.

	     Setting this boolean parameter allows a jail to exist without any
	     processes.	 Normally, a jail is destroyed as its last process
	     exits.  A new jail	must have either the persist parameter or
	     command pseudo-parameter set.
	     The ID of the cpuset associated with this jail (read-only).

     dying   This is true if the jail is in the	process	of shutting down

     parent  The jid of	the parent of this jail, or zero if this is a top-
	     level jail	(read-only).

	     Some restrictions of the jail environment may be set on a per-
	     jail basis.  With the exception of	allow.set_hostname, these
	     boolean parameters	are off	by default.

		     The jail's	hostname may be	changed	via hostname(1)	or

		     A process within the jail has access to System V IPC
		     primitives.  In the current jail implementation, System V
		     primitives	share a	single namespace across	the host and
		     jail environments,	meaning	that processes within a	jail
		     would be able to communicate with (and potentially	inter-
		     fere with)	processes outside of the jail, and in other

		     The prison	root is	allowed	to create raw sockets.	Set-
		     ting this parameter allows	utilities like ping(8) and
		     traceroute(8) to operate inside the prison.  If this is
		     set, the source IP	addresses are enforced to comply with
		     the IP address bound to the jail, regardless of whether
		     or	not the	IP_HDRINCL flag	has been set on	the socket.
		     Since raw sockets can be used to configure	and interact
		     with various network subsystems, extra caution should be
		     used where	privileged access to jails is given out	to
		     untrusted parties.

		     Normally, priveleged users	inside a jail are treated as
		     unprivileged by chflags(2).  When this parameter is set,
		     such users	are treated as privileged, and may manipulate
		     system file flags subject to the usual constraints	on

		     privileged	users inside the jail will be able to mount
		     and unmount file system types marked as jail-friendly.
		     The lsvfs(1) command can be used to find file system
		     types available for mount from within a jail.

		     The prison	root may administer quotas on the jail's
		     filesystem(s).  This includes filesystems that the	jail
		     may share with other jails	or with	non-jailed parts of
		     the system.

		     Sockets within a jail are normally	restricted to IPv4,
		     IPv6, local (UNIX), and route.  This allows access	to
		     other protocol stacks that	have not had jail functional-
		     ity added to them.

     Jails are typically set up	using one of two philosophies: either to con-
     strain a specific application (possibly running with privilege), or to
     create a ``virtual	system image'' running a variety of daemons and	ser-
     vices.  In	both cases, a fairly complete file system install of FreeBSD
     is	required, so as	to provide the necessary command line tools, daemons,
     libraries,	application configuration files, etc.  However,	for a virtual
     server configuration, a fair amount of additional work is required	so as
     to	configure the ``boot'' process.	 This manual page documents the	con-
     figuration	steps necessary	to support either of these steps, although the
     configuration steps may be	refined	based on local requirements.

   Setting up a	Jail Directory Tree
     To	set up a jail directory	tree containing	an entire FreeBSD distribu-
     tion, the following sh(1) command script can be used:

     cd	/usr/src
     mkdir -p $D
     make world	DESTDIR=$D
     make distribution DESTDIR=$D
     mount -t devfs devfs $D/dev

     NOTE: It is important that	only appropriate device	nodes in devfs be
     exposed to	a jail;	access to disk devices in the jail may permit pro-
     cesses in the jail	to bypass the jail sandboxing by modifying files out-
     side of the jail.	See devfs(8) for information on	how to use devfs rules
     to	limit access to	entries	in the per-jail	devfs.	A simple devfs ruleset
     for jails is available as ruleset #4 in /etc/defaults/devfs.rules.

     In	many cases this	example	would put far more in the jail than needed.
     In	the other extreme case a jail might contain only one file: the exe-
     cutable to	be run in the jail.

     We	recommend experimentation and caution that it is a lot easier to start
     with a ``fat'' jail and remove things until it stops working, than	it is
     to	start with a ``thin'' jail and add things until	it works.

   Setting Up a	Jail
     Do	what was described in Setting Up a Jail	Directory Tree to build	the
     jail directory tree.  For the sake	of this	example, we will assume	you
     built it in /data/jail/, named for the jailed IP address.
     Substitute	below as needed	with your own directory, IP address, and host-

   Setting up the Host Environment
     First, you	will want to set up your real system's environment to be
     ``jail-friendly''.	 For consistency, we will refer	to the parent box as
     the ``host	environment'', and to the jailed virtual machine as the	``jail
     environment''.  Since jail	is implemented using IP	aliases, one of	the
     first things to do	is to disable IP services on the host system that lis-
     ten on all	local IP addresses for a service.  If a	network	service	is
     present in	the host environment that binds	all available IP addresses
     rather than specific IP addresses,	it may service requests	sent to	jail
     IP	addresses if the jail did not bind the port.  This means changing
     inetd(8) to only listen on	the appropriate	IP address, and	so forth.  Add
     the following to /etc/rc.conf in the host environment:

	   inetd_flags="-wW -a"
	   rpcbind_enable="NO"	is the native IP address for the host system, in this example.
     Daemons that run out of inetd(8) can be easily set	to use only the	speci-
     fied host IP address.  Other daemons will need to be manually config-
     ured--for some this is possible through the rc.conf(5) flags entries; for
     others it is necessary to modify per-application configuration files, or
     to	recompile the applications.  The following frequently deployed ser-
     vices must	have their individual configuration files modified to limit
     the application to	listening to a specific	IP address:

     To	configure sshd(8), it is necessary to modify /etc/ssh/sshd_config.

     To	configure sendmail(8), it is necessary to modify

     For named(8), it is necessary to modify /etc/namedb/named.conf.

     In	addition, a number of services must be recompiled in order to run them
     in	the host environment.  This includes most applications providing ser-
     vices using rpc(3), such as rpcbind(8), nfsd(8), and mountd(8).  In gen-
     eral, applications	for which it is	not possible to	specify	which IP
     address to	bind should not	be run in the host environment unless they
     should also service requests sent to jail IP addresses.  Attempting to
     serve NFS from the	host environment may also cause	confusion, and cannot
     be	easily reconfigured to use only	specific IPs, as some NFS services are
     hosted directly from the kernel.  Any third-party network software	run-
     ning in the host environment should also be checked and configured	so
     that it does not bind all IP addresses, which would result	in those ser-
     vices' also appearing to be offered by the	jail environments.

     Once these	daemons	have been disabled or fixed in the host	environment,
     it	is best	to reboot so that all daemons are in a known state, to reduce
     the potential for confusion later (such as	finding	that when you send
     mail to a jail, and its sendmail is down, the mail	is delivered to	the
     host, etc.).

   Configuring the Jail
     Start any jail for	the first time without configuring the network inter-
     face so that you can clean	it up a	little and set up accounts.  As	with
     any machine (virtual or not) you will need	to set a root password,	time
     zone, etc.	 Some of these steps apply only	if you intend to run a full
     virtual server inside the jail; others apply both for constraining	a par-
     ticular application or for	running	a virtual server.

     Start a shell in the jail:

	   jail	path=/data/jail/ host.hostname=testhostname \
		   ip4.addr=	command=/bin/sh

     Assuming no errors, you will end up with a	shell prompt within the	jail.
     You can now run /usr/sbin/sysinstall and do the post-install configura-
     tion to set various configuration options,	or perform these actions manu-
     ally by editing /etc/rc.conf, etc.

	   +o   Create an empty /etc/fstab to quell startup warnings about
	       missing fstab (virtual server only)
	   +o   Disable the port	mapper (/etc/rc.conf: rpcbind_enable="NO")
	       (virtual	server only)
	   +o   Configure /etc/resolv.conf so that name resolution within the
	       jail will work correctly
	   +o   Run newaliases(1) to quell sendmail(8) warnings.
	   +o   Disable interface configuration to quell	startup	warnings about
	       ifconfig(8) (network_interfaces="") (virtual server only)
	   +o   Set a root password, probably different from the	real host sys-
	   +o   Set the timezone
	   +o   Add accounts for	users in the jail environment
	   +o   Install any packages the	environment requires

     You may also want to perform any package-specific configuration (web
     servers, SSH servers, etc), patch up /etc/syslog.conf so it logs as you
     would like, etc.  If you are not using a virtual server, you may wish to
     modify syslogd(8) in the host environment to listen on the	syslog socket
     in	the jail environment; in this example, the syslog socket would be
     stored in /data/jail/

     Exit from the shell, and the jail will be shut down.

   Starting the	Jail
     You are now ready to restart the jail and bring up	the environment	with
     all of its	daemons	and other programs.  If	you are	running	a single
     application in the	jail, substitute the command used to start the appli-
     cation for	/etc/rc	in the examples	below.	To start a virtual server
     environment, /etc/rc is run to launch various daemons and services.  To
     do	this, first bring up the virtual host interface, and then start	the
     jail's /etc/rc script from	within the jail.

	   ifconfig ed0	inet alias
	   mount -t procfs proc	/data/jail/
	   jail	path=/data/jail/ host.hostname=testhostname \
		   ip4.addr=	command=/bin/sh	/etc/rc

     A few warnings will be produced, because most sysctl(8) configuration
     variables cannot be set from within the jail, as they are global across
     all jails and the host environment.  However, it should all work prop-
     erly.  You	should be able to see inetd(8),	syslogd(8), and	other pro-
     cesses running within the jail using ps(1), with the `J' flag appearing
     beside jailed processes.  To see an active	list of	jails, use the jls(8)
     utility.  You should also be able to telnet(1) to the hostname or IP
     address of	the jailed environment,	and log	in using the accounts you cre-
     ated previously.

     It	is possible to have jails started at boot time.	 Please	refer to the
     ``jail_*''	variables in rc.conf(5)	for more information.  The rc(8) jail
     script provides a flexible	system to start/stop jails:

     /etc/rc.d/jail start
     /etc/rc.d/jail stop
     /etc/rc.d/jail start myjail
     /etc/rc.d/jail stop myjail

   Managing the	Jail
     Normal machine shutdown commands, such as halt(8),	reboot(8), and
     shutdown(8), cannot be used successfully within the jail.	To kill	all
     processes in a jail, you may log into the jail and, as root, use one of
     the following commands, depending on what you want	to accomplish:

	   kill	-TERM -1
	   kill	-KILL -1

     This will send the	SIGTERM	or SIGKILL signals to all processes in the
     jail from within the jail.	 Depending on the intended use of the jail,
     you may also want to run /etc/rc.shutdown from within the jail.  To kill
     processes from outside the	jail, use the jexec(8) utility in conjunction
     with the one of the kill(1) commands above.  You may also remove the jail
     with jail -r, which will killall the jail's processes with	SIGKILL.

     The /proc/pid/status file contains, as its	last field, the	name of	the
     jail in which the process runs, or	``-'' to indicate that the process is
     not running within	a jail.	 The ps(1) command also	shows a	`J' flag for
     processes in a jail.

     You can also list/kill processes based on their jail ID.  To show pro-
     cesses and	their jail ID, use the following command:

	   ps ax -o pid,jid,args

     To	show and then kill processes in	jail number 3 use the following	com-

	   pgrep -lfj 3
	   pkill -j 3

	   killall -j 3

   Jails and File Systems
     It	is not possible	to mount(8) or umount(8) any file system inside	a jail
     unless the	file system is marked jail-friendly and	the jail's allow.mount
     parameter is set.

     Multiple jails sharing the	same file system can influence each other.
     For example a user	in one jail can	fill the file system also leaving no
     space for processes in the	other jail.  Trying to use quota(1) to prevent
     this will not work	either as the file system quotas are not aware of
     jails but only look at the	user and group IDs.  This means	the same user
     ID	in two jails share the same file system	quota.	One would need to use
     one file system per jail to make this work.

   Sysctl MIB Entries
     The read-only entry security.jail.jailed can be used to determine if a
     process is	running	inside a jail (value is	one) or	not (value is zero).

     The variable security.jail.max_af_ips determines how may address per
     address family a prison may have.	The default is 255.

     Some MIB variables	have per-jail settings.	 Changes to these variables by
     a jailed process do not effect the	host environment, only the jail	envi-
     ronment.  These variables are kern.securelevel, kern.hostname,
     kern.domainname, kern.hostid, and kern.hostuuid.

   Hierarchical	Jails
     By	setting	a jail's children.max parameter, processes within a jail may
     be	able to	create jails of	their own.  These child	jails are kept in a
     hierarchy,	with jails only	able to	see and/or modify the jails they cre-
     ated (or those jails' children).  Each jail has a read-only parent	param-
     eter, containing the jid of the jail that created it; a jid of 0 indi-
     cates the jail is a child of the current jail (or is a top-level jail if
     the current process isn't jailed).

     Jailed processes are not allowed to confer	greater	permissions than they
     themselves	are given, e.g.	if a jail is created with allow.nomount, it is
     not able to create	a jail with allow.mount	set.  Similarly, such restric-
     tions as ip4.addr and securelevel may not be bypassed in child jails.

     A child jail may in turn create its own child jails if its	own
     children.max parameter is set (remember it	is zero	by default).  These
     jails are visible to and can be modified by their parent and all ances-

     Jail names	reflect	this hierarchy,	with a full name being an MIB-type
     string separated by dots.	For example, if	a base system process creates
     a jail ``foo'', and a process under that jail creates another jail
     ``bar'', then the second jail will	be seen	as ``'' in the base
     system (though it is only seen as ``bar'' to any processes	inside jail
     ``foo'').	Jids on	the other hand exist in	a single space,	and each jail
     must have a unique	jid.

     Like the names, a child jail's path is relative to	its creator's own
     path.  This is by virtue of the child jail	being created in the chrooted
     environment of the	first jail.

     killall(1), lsvfs(1), newaliases(1), pgrep(1), pkill(1), ps(1), quota(1),
     chroot(2),	jail_set(2), jail_attach(2), procfs(5),	rc.conf(5),
     sysctl.conf(5), devfs(8), halt(8),	inetd(8), jexec(8), jls(8), mount(8),
     named(8), reboot(8), rpcbind(8), sendmail(8), shutdown(8),	sysctl(8),
     syslogd(8), umount(8)

     The jail utility appeared in FreeBSD 4.0.	Hierarchical/extensible	jails
     were introduced in	FreeBSD	8.0.

     The jail feature was written by Poul-Henning Kamp for R&D Associates who contributed it to FreeBSD.

     Robert Watson wrote the extended documentation, found a few bugs, added a
     few new features, and cleaned up the userland jail	environment.

     Bjoern A. Zeeb added multi-IP jail	support	for IPv4 and IPv6 based	on a
     patch originally done by Pawel Jakub Dawidek for IPv4.

     James Gritton added the extensible	jail parameters	and hierchical jails.

     Jail currently lacks the ability to allow access to specific jail infor-
     mation via	ps(1) as opposed to procfs(5).	Similarly, it might be a good
     idea to add an address alias flag such that daemons listening on all IPs
     (INADDR_ANY) will not bind	on that	address, which would facilitate	build-
     ing a safe	host environment such that host	daemons	do not impose on ser-
     vices offered from	within jails.  Currently, the simplest answer is to
     minimize services offered on the host, possibly limiting it to services
     offered from inetd(8) which is easily configurable.

FreeBSD	8.0			 July 25, 2009			   FreeBSD 8.0


Want to link to this manual page? Use this URL:

home | help