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

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