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

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`.

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...

>
> Thanks,
>