Date: Wed, 30 Mar 2022 14:22:53 -0400 From: Mathieu <sigsys@gmail.com> To: Ed Maste <emaste@freebsd.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <cb6287ea-d979-f2ae-8ef2-8f921ff7941d@gmail.com> In-Reply-To: <CAPyFy2CK1s63-joiTACYnoiOAODHVNDk5Ahyax16BSK8moWxwg@mail.gmail.com> References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <CAPyFy2CK1s63-joiTACYnoiOAODHVNDk5Ahyax16BSK8moWxwg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/30/22 12:14, Ed Maste wrote: > On Mon, 28 Mar 2022 at 05:38, Mathieu <sigsys@gmail.com> 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. > Interesting work - I'm happy to see development with the mac framework > and I plan to take a good look at it once I have a bit more time. Alright! I have to say, it's definitively doing things that MAC wasn't designed for, but that's the best way I found to interface my module with the rest of the kernel. > > I have a couple of quick comments from an initial brief look. First, > the update to pledge's declaration in crypto/openssh/openbsd-compat > belongs upstream in the openssh-portable project; we'll then just pick > it up with a subsequent import. Oh yeah, I think this change used to be necessary when I had put the prototype for pledge() in <unistd.h> (and prototype conflicts led to build failures). Probably not needed anymore. > Second, following on from David > Chisnall's comment about userland abstraction, there's another example > of this concept in the "Super Capsicumizer 9000" at > https://github.com/unrelentingtech/capsicumizer. It interposes libc > and uses LD_PRELOAD, so won't work with statically linked binaries > (and has other limitations) but the example it presents is sandboxing > an unmodified gedit. Yeah I saw that. Maybe I was wrong not to go with that approach. I thought it would be too hard to make it complete enough to run everything I would want it to run. A lot of programs are very finicky. That's what I found out while working on this. I see the advantages that it would have though, this could shield a huge chunk of the kernel's complexity from applications (no matter how much complex functionality the applications demand). I can imagine that it could replace VMs in many cases for the isolation that it brings. If anyone's working on that I think it would be worth it. But in the meantime, my module does it the more conventional way and it's advanced enough to run browsers and whole shell sessions, test suites, etc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cb6287ea-d979-f2ae-8ef2-8f921ff7941d>