Jail security: preventing malicious privilege escalation on the host

The handbook chapter on jails contains this warning:

Important: Jails are a powerful tool, but they are not a security panacea. It is particularly important to note that while it is not possible for a jailed process to break out on its own, there are several ways in which an unprivileged user outside the jail can cooperate with a privileged user inside the jail and thereby obtain elevated privileges in the host environment.

Most of these attacks can be mitigated by ensuring that the jail root is not accessible to unprivileged users in the host environment. Regardless, as a general rule, untrusted users with privileged access to a jail should not be given access to the host environment.

I tracked the source of the warning down to these discussions:

  1. http://lists.freebsd.org/pipermail/freebsd-security/2011-May/005886.html
  2. http://lists.freebsd.org/pipermail/freebsd-security/2009-January/005097.html

It would appear that you can patch the suid security hole by ensuring the directory hosting the jail roots is chmod 700, because then regular users on the host cannot see into or execute any binaries in the jail which are suid.

I haven't been able to identify any other obvious gotchas which could let a superuser in a jail and a regular user on the host conspire to achieve root on the host. Can you think of any? Are they likely to exist?

I'm trying to understand how much of a risk it is having a regular user on the host of a machine running jails.
 
bthomson said:
I haven't been able to identify any other obvious gotchas which could let a superuser in a jail and a regular user on the host conspire to achieve root on the host. Can you think of any? Are they likely to exist?
Yes, there are also some issues with shared memory. Both the host and the jail will use the same namespace so it's possible for processes to share data between the host and the jail.
 
Thanks, @SirDice. It seems like shared memory is enabled for jails by setting
Code:
security.jail.sysvipc_allowed=1
That is set to 0 by default, so it's not a concern unless the user explicitly modifies it.

If anyone else knows of any similar issues, please let me know! I would like to get these together and make an update for the handbook warning so it's a little less vague.
 
Last edited by a moderator:
Back
Top