Date: Tue, 29 Mar 2022 15:46:09 -0400 From: Mathieu <sigsys@gmail.com> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <e934eda4-5d6e-1d86-9002-7a1e4a2102b1@gmail.com> In-Reply-To: <20220329181428.n3db2x57nnn64yfx@mutt-hbsd> References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <20220329181428.n3db2x57nnn64yfx@mutt-hbsd>
next in thread | previous in thread | raw e-mail | index | archive | help
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, >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e934eda4-5d6e-1d86-9002-7a1e4a2102b1>