From nobody Tue Mar 29 23:27:56 2022
X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ECAC21A3DC7E
for <freebsd-hackers@mlmmj.nyi.freebsd.org>; Tue, 29 Mar 2022 23:27:59 +0000 (UTC)
(envelope-from sigsys@gmail.com)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4KSm2Q4Y28z4dNd
for <freebsd-hackers@freebsd.org>; Tue, 29 Mar 2022 23:27:58 +0000 (UTC)
(envelope-from sigsys@gmail.com)
Received: by mail-qt1-x833.google.com with SMTP id b18so16703958qtk.13
for <freebsd-hackers@freebsd.org>; Tue, 29 Mar 2022 16:27:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20210112;
h=message-id:date:mime-version:user-agent:content-language:to:cc
:references:from:subject:in-reply-to:content-transfer-encoding;
bh=quQf/LEBBYM+rB9MEVZwcyXgy9EIqnonXf66hMcfskA=;
b=hB0xBJCxzkiFks3YTImovLVjciyOdtwB30sHlvQooPQv0zsnpul8cUzw3DIwRaPJop
2sSr3A/dR8OZ9zozeRtlR3RavBc3KTzjbArH+lrp64aL6VzNOSS6Ld2NzCj4JEwSwcSx
t/eLKHdYfTi19MrwXPpr4hN+d0dU5eWCNq+Ubcul9T8R+4Jsixap4hwi3okQB5Cc2tJI
laFo/QP8oq0hHulvZju+QqyP9eMRakh0bfc5pmGGVeZAqSFcGM5aY8/psu6fTQKM1LeZ
WsXl3mQ6X9Lz76S8mNKnMRZZUe+Fdg7jMlf6R26DU1D+/jgMhyy+EHiG+Xasj50YT+9A
s9aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:message-id:date:mime-version:user-agent
:content-language:to:cc:references:from:subject:in-reply-to
:content-transfer-encoding;
bh=quQf/LEBBYM+rB9MEVZwcyXgy9EIqnonXf66hMcfskA=;
b=0samX9otyDTZuaMuipXz3/u//RIBtnbD50iOJv5NJPzBZbOwBBz/I9blsH1YtgNvP4
P8495893Z+Vss/98Kg1PyIiYwVD4R+GYWH2Uhpn+qS1DoupEBmGmp/8FKb4Eybg2INya
qcUdN2IGhrJ69UsP37HXxFDJ1WbfoVA56tDPSGtjaDE8obvW714u3QRxl1uo53M4cjY7
IA0h7U3c88d+wkGijMAKynN3oU1iILSHxmUJCpFgroOQ+6RkggQxxi87aRUSnod/Woku
4NE1gP8gs3GKJmxeItgWMkzBYoVrq5tJX19CxdaY5gCPEI/qe9RPko96gLy656APCZfH
Z8Jw==
X-Gm-Message-State: AOAM5334nDM84D/i8DBP5/+eDubTpaozZj1Z/YzIj4HYozig6JgxagP0
9lXcH7rwsyO7+3sUA3ECVcI=
X-Google-Smtp-Source: ABdhPJwpb0AxP3uVItjddSQ4kA3WbU8kCxcxo1lR4PtglRy5kyPceMGCb5L3/QBB1djLKHDJGgXWSg==
X-Received: by 2002:a05:622a:3c7:b0:2e1:cdf9:666b with SMTP id k7-20020a05622a03c700b002e1cdf9666bmr30389949qtx.438.1648596477930;
Tue, 29 Mar 2022 16:27:57 -0700 (PDT)
Received: from [10.0.0.2] ([162.156.254.107])
by smtp.gmail.com with ESMTPSA id b17-20020a05622a021100b002e1f86db385sm15865351qtx.68.2022.03.29.16.27.57
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Tue, 29 Mar 2022 16:27:57 -0700 (PDT)
Message-ID: <bfcb1a67-fd17-20c2-a60d-8ebdf769f41c@gmail.com>
Date: Tue, 29 Mar 2022 19:27:56 -0400
List-Id: Technical discussions relating to FreeBSD <freebsd-hackers.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-hackers
List-Help: <mailto:freebsd-hackers+help@freebsd.org>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Subscribe: <mailto:freebsd-hackers+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-hackers+unsubscribe@freebsd.org>
Sender: owner-freebsd-hackers@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Content-Language: en-US
To: Shawn Webb <shawn.webb@hardenedbsd.org>
Cc: freebsd-hackers@FreeBSD.org
References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com>
<20220329181428.n3db2x57nnn64yfx@mutt-hbsd>
<e934eda4-5d6e-1d86-9002-7a1e4a2102b1@gmail.com>
<20220329211230.2dufhnikhaqyovwc@mutt-hbsd>
From: Mathieu <sigsys@gmail.com>
Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support
In-Reply-To: <20220329211230.2dufhnikhaqyovwc@mutt-hbsd>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4KSm2Q4Y28z4dNd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=gmail.com header.s=20210112 header.b=hB0xBJCx;
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::833 as permitted sender) smtp.mailfrom=sigsys@gmail.com
X-Spamd-Result: default: False [-3.41 / 15.00];
RCVD_VIA_SMTP_AUTH(0.00)[];
TO_DN_SOME(0.00)[];
R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
FREEMAIL_FROM(0.00)[gmail.com];
RCVD_COUNT_THREE(0.00)[3];
DKIM_TRACE(0.00)[gmail.com:+];
RCPT_COUNT_TWO(0.00)[2];
DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
NEURAL_HAM_SHORT(-1.00)[-1.000];
FROM_EQ_ENVFROM(0.00)[];
MIME_TRACE(0.00)[0:+];
FREEMAIL_ENVFROM(0.00)[gmail.com];
ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
MID_RHS_MATCH_FROM(0.00)[];
DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
ARC_NA(0.00)[];
NEURAL_HAM_MEDIUM(-0.41)[-0.406];
R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
FROM_HAS_DN(0.00)[];
NEURAL_HAM_LONG(-1.00)[-1.000];
MIME_GOOD(-0.10)[text/plain];
PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org];
TO_MATCH_ENVRCPT_SOME(0.00)[];
RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::833:from];
MLMMJ_DEST(0.00)[freebsd-hackers];
RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
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