Date: Tue, 29 Mar 2022 19:27:56 -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: <bfcb1a67-fd17-20c2-a60d-8ebdf769f41c@gmail.com> In-Reply-To: <20220329211230.2dufhnikhaqyovwc@mutt-hbsd> References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <20220329181428.n3db2x57nnn64yfx@mutt-hbsd> <e934eda4-5d6e-1d86-9002-7a1e4a2102b1@gmail.com> <20220329211230.2dufhnikhaqyovwc@mutt-hbsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/29/22 17:12, Shawn Webb wrote: > 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. Ok I think I get it. I'm being confused with what rearranging branches means for a cloned repo on github... I'm sure it's not that complicated but I'm gonna have another look at it later more carefully to make sure I don't break everything. I just noticed that I have a zillion "users"/"projects" branches in that github repo too. They must be from before main FreeBSD repo switched to git. That repo was cloned a while ago. And they're ALL out of date. Ah, I was probably supposed to click an "update upstream" button somewhere on github to keep all of this synchronized... Yeah I'm gonna clean this up and use your branch structure. > >> 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.) Yes. But (hopefully) I think I'm done redesigning it and changing how it integrates with the rest of the kernel (I had tried a few approaches already...). Which should hopefully mean less merge conflicts happening. I'll have a look at what the conflicts are like with HardenedBSD's main after rearranging my branches. > > 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. Alright! Lemme know how this goes. I'd be glad to see this merged in HardenedBSD too. For FreeBSD I was thinking most of this could become a port, but there might be advantages in merging the whole thing in base to make it easier to use sandboxing more places (like base daemons, rc.d/periodic scripts, maybe login.conf support for it, etc). > Thanks again! > Sure thing
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bfcb1a67-fd17-20c2-a60d-8ebdf769f41c>