Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support

On Wed, Mar 30, 2022 at 01:52:09PM -0400, Mathieu wrote:
> On 3/30/22 03:22, Baptiste Daroussin wrote:
> > Hello Mathieu,
> > First of all, thank you for this amazing work, leveraging the mac framework to
> > build curtain is imho an excellent idea, I personnally see a curtain like
> > approach as complementary to a capsicum approach rather than an antagonist
> > feature, I can see many possible usage of curtains in freebsd in particular in
> > the port framework!
> 
> 
> Alright!
> 
> One nice thing with the MAC approach is that many of the checks were already
> carefully placed to not deviate too much from expected behavior for
> applications.  At first I tried to do all of the checks in namei() and this
> often made syscalls fail too early with the wrong errnos and this confuses
> some programs.  When I figured out the right place to add the checks it was
> almost always right next to a MAC check.
> 
> Also, if I hadn't used a MAC module and added a new layer instead, you could
> say that it would have been the fifth (!!!) general access control mechanism
> in the kernel (after traditional UNIX, Capsicum, jails and MAC).  This was
> starting to feel like a bit much.  So the MAC framework, it's not a perfect
> fit for some of what this module wants to do but it could be worse.

While I think using the MAC framework here was definitely the right
choice, I also think it's important to note the one major downside of
the MAC framework: function pointers. A kernel exploit could nullify
one or more MAC calls by overwriting a function pointer. Additionally,
in certain circumstances, a function pointer could be overwritten to
point to another spot in memory. The next time the fptr is called, the
originally intended code isn't executed--rather, a new code path.

Again, I think using MAC here is the right way to go.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc