On 9/1/25 12:26, James Gritton wrote:
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.
FWIW, I posted a series of reviews starting at
https://reviews.freebsd.org/D53953
that would facilitate the feature I'm describing, but doing so by adding some
MAC
entry points and a label to `struct prison` so that one can more generically
implement
something like this as a MAC policy rather than augmenting existing checks to
special-case some jails.
I think the MAC route is more appealing in general: I can have my functionality
here
without having to justify it to the greater community (without having to carry a
larger maintenance burden of patching jail functionality directly), and MAC
adds more
flexibility in case one wants to do other forms of access control with jails.
Thanks,
Kyle Evans
