RFC: Jail Capsules

Hi,

I've been toying around with this idea for a bit, and I wanted to solicit some opinions on the
design and whether this seems like something that FreeBSD would be find useful outside of my
own tree.

Background:  I've been thinking a lot lately about secure product design and threat models, and
wondering what kinds of things one could incorporate into their design as a defense in depth
kind of thing.  This is, of course, not something I would pitch as a strong isolation mechanism,
but rather as a mechanism to protect against some less sophisticated threats.

The basic idea that I'm proposing is the ability to seal a jail to turn it into a 'capsule'.  You
can either seal it at creation time, or while it's already running.  If you create the jail as a
capsule, you must attach to it at the same time.  Sealing it later is a compromise to give the
system some runway to configure the jail first, presumably before other user activity could
start and try to compromise the capsule before it's sealed.

Once sealed, the capsule has the following properties (that I've thought about, at least):

  - The capsule may not be unsealed
  - Processes outside of the capsule may not attach to it
  - Unprivileged users in the parent cannot see or tamper with processes in the jail, regardless of
     the security.bsd.see_* sysctls.  persist and all of the allow.unprivileged_* jail knobs will be
     forcibly unset and result in errors if one attempts to set them after
  - Privileged processes may see and signal the processes in a capsule if securelevel is <= 0, but it
     cannot attach to, debug, or cpuset individual processes in a capsule at any securelevel

The premise of a capsule is that you (attempt to) seal off access points into the jail besides for a
well-defined (by the software in the capsule) security boundary.  It is naturally not protected if
the kernel is compromised or in some other scenarios, but you eliminate a number of threats where an
attacker can manage to make syscalls but doesn't have the tools available to escalate further.  Capsules
would simply be a building block to a larger secure design.

An obvious elephant in the room here is filesystem access.  A capsule would force an attacker to get
a little more creative if they want to tamper with capsule processes, in particular if it's combined
with a heightened securelevel (or removal of other features like /dev/mem entirely), but it does not
stop an attacker from filesystem tampering to disrupt capsule activities.  This kind of leaves a huge
part of protecting itself up to application design, which arguably eliminates many benefits of the idea.

I don't really have a good answer for how one might solve that.  The rest of the design is fairly
straightforward to implement, but I would rather suspect it might get hairy if you try to block off parts
of the filesystem (even from root, maybe contingent on securelevel) based on whether the path has been
used for a capsule or not.

Comments/questions/tomatoes welcome.  The idea was somewhat inspired by enclaves and a design where one
can slice off some CPUs to dedicate to the capsule alone to try and mitigate some side-channel
possibilities from other user processes, but the initial capsule thought process doesn't go to the
extent of trying to carve out memory to dedicate to a capsule.

Thanks,

Kyle Evans