On 2025-08-31 20:27, Kyle Evans wrote:
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.
I'm not quite seeing the use case, which may obvious this, but the
only safe filesystem setup is the jail having its own filesystem. It
could have other filesystems mounted, but no nullfs, unionfs, or nfs.
The jail root could be protected similarly to the processes - outside
unprivileged processes can't see past it, bascially a virtual 700
permission from outside even if it's something more traditional like
755 as seen inside the jail.
- Jamie
