
#############
# jail tuning
security.jail.set_hostname_allowed=0     # default = 1
security.jail.enforce_statfs=1           # default = 2
security.jail.allow_raw_sockets=0        # default = 0
security.jail.socket_unixiproute_only=1  # default = 1
security.jail.sysvipc_allowed=0          # default = 0
security.jail.chflags_allowed=0          # default = 0


# STRAIGHT FROM THE MAN PAGE
############################
#
#     There are currently two MIB related variables that have per-jail set-
#     tings.  Changes to these variables by a jailed process do not effect the
#     host environment, only the jail environment.  The variables are
     kern.securelevel and kern.hostname.

#
#     security.jail.set_hostname_allowed
#          This MIB entry determines whether or not processes within a jail are
#          allowed to change their hostname via hostname(1) or sethostname(3).
#          In the current jail implementation, the ability to set the hostname
#          from within the jail can impact management tools relying on the
#          accuracy of jail information in /proc.  As such, this should be dis-
#          abled in environments where privileged access to jails is given out
#          to untrusted parties.
#
#     security.jail.enforce_statfs
#          This MIB entry determines which information processes in a jail are
#          able to get about mount-points.  It affects the behaviour of the
#          following 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
#          visible.  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.
#
#     security.jail.allow_raw_sockets
#          This MIB entry determines whether or not prison root is allowed to
#          create raw sockets.  Setting this MIB to 1 allows utilities like
#          ping(8) and traceroute(8) to operate inside the prison.  If this MIB
#          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.  As such, by default this option is
#          disabled.
#
#     security.jail.socket_unixiproute_only
#          The jail functionality binds an IPv4 address to each jail, and lim-
#          its access to other network addresses in the IPv4 space that may be
#          available in the host environment.  However, jail is not currently
#          able to limit access to other network protocol stacks that have not
#          had jail functionality added to them.  As such, by default, pro-
#          cesses within jails may only access protocols in the following
#          domains: PF_LOCAL, PF_INET, and PF_ROUTE, permitting them access to
#          UNIX domain sockets, IPv4 addresses, and routing sockets.  To enable
#          access to other domains, this MIB variable may be set to 0.
#
#     ikenote: postgres requires:
#     security.jail.sysvipc_allowed
#          This MIB entry determines whether or not processes within a jail
#          have access to System V IPC primitives.  In the current jail imple-
#          mentation, 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 interfere with)
#          processes outside of the jail, and in other jails.  As such, this
#          functionality is disabled by default, but can be enabled by setting
#          this MIB entry to 1.
#
#     security.jail.chflags_allowed
#          This MIB entry determines how a privileged user inside a jail will
#          be treated by chflags(2).  If zero, such users are treated as
#          unprivileged, and are unable to set or clear system file flags; if
#          non-zero, such users are treated as privileged, and may manipulate
#          system file flags subject to the usual constraints on
#          kern.securelevel.
#
