What are the security implications of using allow.sysvipc in a FreeBSD jail

Question

The man page for jail says that allow.sysvipc enables "System V primitives [to] share a single namespace across the host and jail environments..." thus "... processes within a jail would be able to communicate with ... processes outside of the jail, and in other jails."

What are the practical security implications of this? The most extreme interpretation would imply that when using this option, there is little effective security within the entire jail infrastucture. (If processes can interfere with and communicate with other processes on the host and other jails then why bother with the jail at all?)

Answer 1

So, it turns out that the extreme interpretation is correct. Allowing sysvipc "... defeat[s] the whole purpose of having a jail; privileged users from the jail would be able to affect processes outside the jailed environment."

UPDATE Aug 3, 2010: After some serendipitous research, I've been able to flesh out some details. The problem stems from the fact that process permissions are based on UIDs (note that this means the number, not the string identifier). So, even though the user spaces for the host and jail are mutually separate, this division isn't iron-clad and given that root has a UID of 0, we get the quote above. Some options to minimize the risk:

1. Ensure all users across the entire system (host and jails) have different UIDs
2. Disable root login for the jails (won't help with processes run as root so sudo tricks but some is better than none.)