Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support
Date: Tue, 29 Mar 2022 18:14:28 UTC
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. 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 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc