From nobody Tue Mar 29 17:32:41 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 7B8E61A4EDA5 for ; Tue, 29 Mar 2022 17:32:45 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 4KSc8X1S0cz4hGr for ; Tue, 29 Mar 2022 17:32:44 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qk1-x72a.google.com with SMTP id 1so14662878qke.1 for ; Tue, 29 Mar 2022 10:32:44 -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:from:subject:to:references :content-language:in-reply-to:content-transfer-encoding; bh=CUd3jkUnKZvbVjOgpcj4qNXvSK/R7Vqwt4RR/kZHwEA=; b=H70hILbzoRMPpxiRHOyCH51fE+WgkyGVSmJNMa28BBTSOyHRirszFQ4I5/HhTzN5je QqCtbsxpP0l//w8iPkrhOXntw3trWV7aCAhVMMcKZ00tAw1TfVDiMqBgiOOOB/w5pt+D rY1D2wNiLx1PABsGcoEXlt72Kc/cYDOj7dymy0Q4nh48/xHGRuwYXITDvw9cJZxPXI1y 1ExHNJqUKIVCUTOx2TNz+eqnwFaHSi4MtliCdGy5SC63v4AjWw7/uQpEtT+jG1xC+Yml zkY3rowjyZjlyX6S+NZ/UqZfl+Hw0cOEDC5/SjyQIfsKfx/OG3DeG9XzJQKeFS/0z6jy UyBw== 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:from :subject:to:references:content-language:in-reply-to :content-transfer-encoding; bh=CUd3jkUnKZvbVjOgpcj4qNXvSK/R7Vqwt4RR/kZHwEA=; b=iPK66bz0ermezRoQ/ItPMJp142ke95kh7kJRxbjWNX7qePFh7JsGFVN1NapWiXcjtN 3wi5DDU+mKEJTdXjSReuU8IY58uq9Ky0h+YgUKXqiAbi6umK0iUn+ifCaVmM3UxqIMMb +h1n3KHbB7hhmsgbyJjhhduD7wAexTcad2Ps7Fi117V338r1TUtli9Yn141zMyXi1got 7NmN9OaiU+DAXlGYFruvr5ddvJRSuy6U0h2uOlXSQ/MeEDYqhKPvyjNBVTJFEGCeDCkf /uFK2t+KE/ice+DLguq3H78wpcUWxORF23jDSOKJIAV089hePJNeZXZZfNCjhohPwa0C DOVQ== X-Gm-Message-State: AOAM5338lcUayCwZkuM1CikgtgG4H1pxAFaDGjDwz90XW5NS6/mKEiGs VJgAP5YJnDLnsDSEkfrvPLXZQ6qgvwk= X-Google-Smtp-Source: ABdhPJyflwnj5hz550HlJ0G03jgz9rOdR2Lat7jOuZA5iPtCE01+PlxD74xVBnuifW2vzsp3RzkQNQ== X-Received: by 2002:a05:620a:25a:b0:67d:43a6:8892 with SMTP id q26-20020a05620a025a00b0067d43a68892mr21233699qkn.659.1648575163215; Tue, 29 Mar 2022 10:32:43 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id 188-20020a3709c5000000b0067b147584c2sm9764208qkj.102.2022.03.29.10.32.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Mar 2022 10:32:42 -0700 (PDT) Message-ID: <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> Date: Tue, 29 Mar 2022 13:32:41 -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 From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support To: freebsd-hackers@FreeBSD.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> Content-Language: en-US In-Reply-To: <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KSc8X1S0cz4hGr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=H70hILbz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::72a as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-3.23 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; 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)[-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(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.23)[-0.226]; 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::72a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/29/22 04:34, David Chisnall wrote: > Hi, > > Does pledge actually require kernel support?  I'd have thought that it > could be implemented on top of Capsicum as a purely userland > abstraction (more easily with libc help, but even with an LD_PRELOADed > library along the lines of libpreopen).  In Verona, we're able to use > Capsicum to run unmodified libraries in a sandbox, for example, > including handling raw system calls: > > https://github.com/microsoft/verona/tree/master/experiments/process_sandbox > > > It would be good to understand why this needs more kernel attack surface. > > David If it can work like that then it's pretty cool.  It could be a lot more secure.  But it's just not the way I went with. Re-implementing so much kernel functionality in userland seems like a lot of work. Because I wanted my module to be able to sandbox (almost) everything that the OS can run.  Including whole process hierarchies that execute other programs and use process management and shared memory, etc.  That's a lot of little details to get right...  So I went with the same route that jails, other MAC modules and even Capsicum are implemented: with access checks in the kernel itself.  And most of these checks were already in place with MAC hooks. pledge()/unveil() are usually used for fairly well-disciplined applications that either don't run other programs or run very specific programs that are also well-disciplined and don't expect too much (unless you just drop the pledges on execve()). Pledged applications usually reduce the kernel attack surface a lot, but you don't run arbitrary programs with pledge (and that wasn't one of its goals AFAIK).  But that's what I wanted my module to be able to do.  I'd say it has become a bit of a weird hybrid between a "container" framework and an exploit mitigation framework at this point.  You can run a `make buildworld` with it, build/install/run random programs isolated in your project directories, sandbox shell/desktop sessions as a whole, etc.  And then within those sandboxes, nested applications can do their own sandboxing on top of it (with this module (and its pledge/unveil compat) or Capsicum (and possibly other compat layers built on top of it)).  The "inner" programs can use more restrictive sandboxes that don't expose as much kernel functionality.  But for the "outer" programs the whole thing slides more towards being "containers"/"jails" (and the more complex it would have been to do purely in userland I believe).