From nobody Thu Mar 31 23:07:37 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 AD1EA1A5FED6 for ; Thu, 31 Mar 2022 23:07:46 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 4KTzV94mjRz3D2H for ; Thu, 31 Mar 2022 23:07:45 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qt1-x829.google.com with SMTP id j21so907542qta.0 for ; Thu, 31 Mar 2022 16:07:45 -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 :references:from:subject:in-reply-to:content-transfer-encoding; bh=mV5weIf8v65fIs6C0cLBFOLzPU+6AjYqEOvQbXSXxJk=; b=KVUB6bBykIx4fZtv1owY97oA/D2jL+DrayrD8pgHPUu4nZCTZKtU+mp8bdVa9K0XbT l2+QxbOmox18JoxBSGJaP07aoOQL50I+CUvn4S69sODUC6+7sbmUt5B1Y5g0QKd/O5Rs FlGwwkK5Lgmz92J1shh8bvOg816sBClpUz2W94D91j/ojG0r5MU0KMwplHq5pTmRjz4Z sRNnDw90g4o/CvAmTOjMokmJH3L+782b716sJV2W9fnDc0PDrODFQEORzqTPXZtXntv+ gDkdfHWcEIvWvF36ETiP/CbJNF0Bft4Qye4DAcqWdHQUNSut/6sytKRQe5rvecTRlGje NMBQ== 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:references:from:subject:in-reply-to :content-transfer-encoding; bh=mV5weIf8v65fIs6C0cLBFOLzPU+6AjYqEOvQbXSXxJk=; b=RgkcRGsU1kBQiOU5NB+twY4sHn1/zt82Svk+tr1W3MWxHNwiwz1hXKgYP+zfKPYq6q fpCfInyOVnHSNTil0IfHS9k0/1tJWoo31cVK7n/8Qqj0NMbnXHnb39clY0mtlDo61IfO ZcgMNbvq/xEA8kjD0AkRGlJNDW2oVMxx85OK1chp76JgEIYH/rCdHm4FRby5I9psJi9Y FqeT3RkZTFBSE/fCWloPh4qWKSpb70HPlKffZMwRsqYr8JL6dTOZX0Hzk1xRNh6a5wk9 yJSeUdamExXLykblSpGAgAX0Pj2t6ROW6H33BIul9CCoM8gMGifnKMH/hZxeM9l9H/pS L/lA== X-Gm-Message-State: AOAM5327Cf5H29hqqIaoyPjEabyfyZACqSNglCoB5eB64vdffNRF42Dg /QNcx+TC1DqjqA5Y8ESFiQYp+xjGhwQ= X-Google-Smtp-Source: ABdhPJzTikWbnF4O7mL6WeC/gX8blcbInBUKPUtbKnFa7fS0HtFO3cYzkaj9GG6SoXfE8aaH4EMOiw== X-Received: by 2002:ac8:4e8b:0:b0:2e2:129b:35f1 with SMTP id 11-20020ac84e8b000000b002e2129b35f1mr6456887qtp.387.1648768059354; Thu, 31 Mar 2022 16:07:39 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id r64-20020a37a843000000b0067b0cf40b18sm390884qke.69.2022.03.31.16.07.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Mar 2022 16:07:38 -0700 (PDT) Message-ID: <93290001-7aaa-4576-170a-6c215eaba6ed@gmail.com> Date: Thu, 31 Mar 2022 19:07:37 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: 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: freebsd-hackers@FreeBSD.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> <20220331193734.3pwhap2443gd33hg@mutt-hbsd> From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-Reply-To: <20220331193734.3pwhap2443gd33hg@mutt-hbsd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KTzV94mjRz3D2H X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KVUB6bBy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::829 as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.998]; 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(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::829:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/31/22 15:37, Shawn Webb wrote: > On Thu, Mar 31, 2022 at 03:33:06PM -0400, Ed Maste wrote: >> On Thu, 31 Mar 2022 at 06:25, David Chisnall wrote: >>> Capsicum simply disallows '..' in paths. >> This is no longer true as of 7359fdcf5ffa. During a lookup the kernel >> checks that each ".." component specifies a directory that has already >> been visited in this name lookup call. >> >>> The execve hole is the reason that I have little interest in pledge as >>> an enforcement mechanism. >> Note that execve is only available if the "exec" keyword is specified. >> The child does not inherit the parent's limits, though. It does not inherit the restrictions passed as pledge()'s first argument, but it gets the restrictions passed as the second argument (if it is non-NULL) and it can't get rid of those ever. If the executed programs then execute other programs, they will also be restricted to a subset of those restrictions. But you have to actually make use of the second argument (but the child program might not be able to tolerate it...). > I wonder if there's opportunity here for a little divergence. I think > inheritance would be a good thing. But this is more a philosophical > and subjective argument than a technical one. > There's divergeance in my module already, but I tried to keep the pledge() implementation compatible. If you use pledge() alone, this (hopefully) makes no significant difference. But if you use curtain(1), curtain(3) directly or the freebsd_simple_sandbox() wrapper I added, sandbox restrictions are all inherited (irreversibly) by default. And if you use pledge() on top of an inherited curtain, the pledged applications can get rid of its own pledge restrictions on-exec, but it cannot get rid of the inherited curtain restrictions in any way.  (Unless I screwed up!) It's this whole pledge() execve() question that made me come up with an altered design that is fully nestable.  Now pledge() support is sort of "emulated" on top of the more general curtain mechanism.