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

On Tue, Mar 29, 2022 at 03:46:09PM -0400, Mathieu wrote:
> On 3/29/22 14:14, Shawn Webb wrote:
> > On Mon, Mar 28, 2022 at 05:37:44AM -0400, Mathieu wrote:
> > > Hello list.  Since a while I've been working on and off on a
> > > pledge()/unveil() implementation for FreeBSD.  I also wanted it to be able
> > > to sandbox arbitrary programs that might not expect it with no (or very
> > > minor) modifications.  So I just kept adding to it until it could do that
> > > well enough.  I'm still working on it, and there are some known issues and
> > > some things I'm not sure are done correctly, but overall it's in a very
> > > functional state now. It can run unmodified most utilities and desktop apps
> > > (though dbus/dconf/etc are trouble), server daemons, buildworld and whole
> > > shell/desktop sessions sandboxed.
> > > 
> > > https://github.com/Math2/freebsd-pledge
> > > https://github.com/Math2/freebsd-pledge/blob/main/CURTAIN-README.md
> > > 
> > > It can be broken up in 4 parts: 1) A MAC module that implements most of the
> > > functionality.  2) The userland library, sandboxing utility, configs and
> > > tests.  3) Various kernel changes needed to support it (including new MAC
> > > handlers and extended syscall filtering).  4) Small changes/fixes to the
> > > base userland (things like adding reporting to ps and modifying some
> > > utilities to use $TMPDIR so that they can be properly sandboxed).  So 1) and
> > > 2) could be in a port.  And I tried to minimize 3) and 4) as much as
> > > possible.
> > > 
> > > I noted some problems/limitations in the CURTAIN-ISSUES file.  At this point
> > > I'm mostly wondering about the general design being acceptable for merging
> > > eventually.  Because most of this could be part of a port, but not all of
> > > it.  And the way that it deals with filesystem access restrictions in
> > > particular is kludgy.  So any feedback/testing welcome.
> > > 
> > > It still lacks documentation (in part because I'm not sure of what could
> > > still change) so I'm going to give an overview of it here and show some
> > > examples and that's going to be the documentation for now.  And I'll
> > > describe the kernel changes that it needed.  So that's going to be a bit of
> > > a long email.
> > Hey Mathieu,
> > 
> > Thanks a lot for working on this! I'm incredibly excited to see this
> > work progress and mature.
> 
> 
> Hey! Thanks, nice to hear that.
> 
> 
> > I'd love to start reviewing your work. One thing that would make it
> > easier to review would be if you used a feature branch rather than
> > relying on the main branch. That way, a simple `git diff` command
> > could be used to generate a diff between your code and stock freebsd.
> > 
> > If you'd like an example of that, take a look at HardenedBSD's
> > repo[0]. We have two relevant branches:
> > 
> > freebsd/current/main <- FreeBSD's sources
> > hardened/current/main <- HardenedBSD's patches applied on top of
> >      FreeBSD's sources
> > 
> > Users can then simply run `git diff origin/freebsd/current/main` to
> > see all the changes we've made (assuming the user is currently working
> > on the hardened/current/master branch.)
> > 
> > [0]: https://git.hardenedbsd.org/HardenedBSD/hardenedbsd
> 
> 
> I gotta be honest, I'm never too sure if I understand what git is doing. So
> I try to keep it simple. I'm going to create a "stock" branch and keep it
> pointing *exactly* to what I've been merging from. Lemme know if that works.
> I'm not too sure I'd be using a more elaborate branch layout correctly...
> This is going to be a lot of work to review so yeah I'd try to set this up
> to make it easier but I could just make it worse too heh. The way I've been
> comparing my changes to stock so far was with 3 dots diff: `git diff
> freebsd/main...main`.

I quickly forked your repo, and created two branches:
freebsd/current/main and curtain/current/main:

https://github.com/lattera/freebsd-pledge

So now freebsd/current/main can be updated first, then you can merge
in freebsd/current/main into curtain/current/main. Hopefully you find
that useful.

> 
> Also, I gotta warn you, the lack of comments is just terrible in some
> places. This project turned out to be a lot more complicated than I had
> hoped. Correctly handling "slots" and inheritance/masking between sandboxes
> was harder than I thought. Most of the complexity are in the library and MAC
> module. But I think it probably was necessary complexity to get the (mostly)
> seamlessly nestable sandboxing system that I wanted...

Totally understood. This is a work in progress and there's likely a
lot to still be worked out (as you've already mentioned.)

My work load at ${DAYJOB} is a bit tight at the moment, but I do plan
on taking some time off soon. During that time off, I'll start peeking
at the code. I'll make sure to keep an eye on the project in the
meantime, though.

Thanks again!

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

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