From owner-trustedbsd-discuss@freebsd.org Tue Nov 24 06:06:07 2020 Return-Path: Delivered-To: trustedbsd-discuss@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E480047A5B4 for ; Tue, 24 Nov 2020 06:06:07 +0000 (UTC) (envelope-from 01000175f8d4f28a-a7beaaa1-4e3d-4b73-94cb-ea01b88329c0-000000@amazonses.com) Received: from cyrus.watson.org (cyrus.watson.org [204.107.128.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4CgD6R20Vhz3pQs for ; Tue, 24 Nov 2020 06:06:07 +0000 (UTC) (envelope-from 01000175f8d4f28a-a7beaaa1-4e3d-4b73-94cb-ea01b88329c0-000000@amazonses.com) Received: from a9-34.smtp-out.amazonses.com (a9-34.smtp-out.amazonses.com [54.240.9.34]) by cyrus.watson.org (Postfix) with ESMTPS id 2C4F31B082 for ; Tue, 24 Nov 2020 05:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1606197506; h=Date:To:From:Reply-To:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type:Feedback-ID; bh=8KYJZqwYDkMEu/wdJsnfQNhmHn5bag9hiEqNEwnKQNE=; b=cg+EzWfe8ooUz4D2TZoh48rzv+oQnM4NpYPAdh5qB/zL0HBabfSNfb3+Tx86HZtc d60qgR06J9zTfkzMxsN/INesPRqbwVDS/GcPYfpbYTC0HDzNdhALkxlQBJNKgQB/XLY +JuwXHRiqXLHyu9T8cBCoXQJ5XqSQGuDEmJD2MSA= Date: Tue, 24 Nov 2020 05:58:26 +0000 To: trustedbsd-discuss@trustedbsd.org From: Protective Supply Plus Reply-To: Protective Supply Plus Subject: Lysol Disinfecting Wipes 80-Count 12pk, 48pk Message-ID: <01000175f8d4f28a-a7beaaa1-4e3d-4b73-94cb-ea01b88329c0-000000@email.amazonses.com> X-Mailer: Sendy (https://sendy.co) X-SES-Outgoing: 2020.11.24-54.240.9.34 Feedback-ID: 1.us-east-1.RTkVlVss2raM7wDWWhOx+0W68/4zoRImF6RxgXPSLsE=:AmazonSES X-Rspamd-Queue-Id: 4CgD6R20Vhz3pQs X-Spamd-Bar: ++++++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=cg+EzWfe; dmarc=none; spf=fail (mx1.freebsd.org: domain of 01000175f8d4f28a-a7beaaa1-4e3d-4b73-94cb-ea01b88329c0-000000@amazonses.com does not designate 204.107.128.30 as permitted sender) smtp.mailfrom=01000175f8d4f28a-a7beaaa1-4e3d-4b73-94cb-ea01b88329c0-000000@amazonses.com X-Spamd-Result: default: False [10.06 / 15.00]; HAS_REPLYTO(0.00)[web@protectivesupplyplus.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-0.83)[-0.827]; FORGED_SENDER(0.30)[web@protectivesupplyplus.com,01000175f8d4f28a-a7beaaa1-4e3d-4b73-94cb-ea01b88329c0-000000@amazonses.com]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[204.107.128.30:from]; FORGED_RECIPIENTS(2.00)[m:trustedbsd-discuss@trustedbsd.org,s:trustedbsd-discuss@freebsd.org]; ASN(0.00)[asn:11288, ipnet:204.107.128.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[web@protectivesupplyplus.com,01000175f8d4f28a-a7beaaa1-4e3d-4b73-94cb-ea01b88329c0-000000@amazonses.com]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all:c]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=224i4yxa5dv7c2xz3womw6peuasteono]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; HTML_SHORT_LINK_IMG_2(1.00)[]; PREVIOUSLY_DELIVERED(0.00)[trustedbsd-discuss@trustedbsd.org]; DMARC_NA(0.00)[protectivesupplyplus.com]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[204.107.128.30:from:127.0.2.255]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; VIOLATED_DIRECT_SPF(3.50)[]; FROM_SERVICE_ACCT(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; MIME_HTML_ONLY(0.20)[]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,body]; MAILMAN_DEST(0.00)[trustedbsd-discuss] X-Spam: Yes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 06:06:07 -0000 From owner-trustedbsd-discuss@freebsd.org Thu Nov 26 16:51:38 2020 Return-Path: Delivered-To: trustedbsd-discuss@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 126F6468CB4 for ; Thu, 26 Nov 2020 16:51:38 +0000 (UTC) (envelope-from 010001760570e5fe-1095f86a-058a-41a9-a8fc-6ad61f83bca3-000000@amazonses.com) Received: from cyrus.watson.org (cyrus.watson.org [204.107.128.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4ChkLK417hz4k9g for ; Thu, 26 Nov 2020 16:51:37 +0000 (UTC) (envelope-from 010001760570e5fe-1095f86a-058a-41a9-a8fc-6ad61f83bca3-000000@amazonses.com) Received: from a9-114.smtp-out.amazonses.com (a9-114.smtp-out.amazonses.com [54.240.9.114]) by cyrus.watson.org (Postfix) with ESMTPS id 3CEB25C73A for ; Thu, 26 Nov 2020 16:44:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1606409053; h=Date:To:From:Reply-To:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type:Feedback-ID; bh=inJ82bgRsT5OqtkmIdTmtH8drJaY60hbpHTa6o0BqQg=; b=M80zUTx/gHg6G1P6HeTgRzEyee7c8vcWSvc4eSb9RZgDGYTT32vHtQutnWtkRfYF QXLeL0nsvdvHEnXAloT2LneZOQDhQGn2dT1ZGGqOxskHS47QYulCKaT7suHjNekLHWI nlop3M7PTbODasVETeXwhTL011tTJeea+rte7kGA= Date: Thu, 26 Nov 2020 16:44:13 +0000 To: trustedbsd-discuss@trustedbsd.org From: Protective Supply Plus Reply-To: Protective Supply Plus Subject: Sale $25 OFF Lysol Disinfectant Spray 19 oz. Message-ID: <010001760570e5fe-1095f86a-058a-41a9-a8fc-6ad61f83bca3-000000@email.amazonses.com> X-Mailer: Sendy (https://sendy.co) X-SES-Outgoing: 2020.11.26-54.240.9.114 Feedback-ID: 1.us-east-1.RTkVlVss2raM7wDWWhOx+0W68/4zoRImF6RxgXPSLsE=:AmazonSES X-Rspamd-Queue-Id: 4ChkLK417hz4k9g X-Spamd-Bar: +++++++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=M80zUTx/; dmarc=none; spf=fail (mx1.freebsd.org: domain of 010001760570e5fe-1095f86a-058a-41a9-a8fc-6ad61f83bca3-000000@amazonses.com does not designate 204.107.128.30 as permitted sender) smtp.mailfrom=010001760570e5fe-1095f86a-058a-41a9-a8fc-6ad61f83bca3-000000@amazonses.com X-Spamd-Result: default: False [11.01 / 15.00]; HAS_REPLYTO(0.00)[web@protectivesupplyplus.com]; SUBJECT_HAS_CURRENCY(1.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-0.88)[-0.878]; FORGED_SENDER(0.30)[web@protectivesupplyplus.com,010001760570e5fe-1095f86a-058a-41a9-a8fc-6ad61f83bca3-000000@amazonses.com]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[204.107.128.30:from]; FORGED_RECIPIENTS(2.00)[m:trustedbsd-discuss@trustedbsd.org,s:trustedbsd-discuss@freebsd.org]; ASN(0.00)[asn:11288, ipnet:204.107.128.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[web@protectivesupplyplus.com,010001760570e5fe-1095f86a-058a-41a9-a8fc-6ad61f83bca3-000000@amazonses.com]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all:c]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=224i4yxa5dv7c2xz3womw6peuasteono]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; HTML_SHORT_LINK_IMG_2(1.00)[]; DMARC_NA(0.00)[protectivesupplyplus.com]; PREVIOUSLY_DELIVERED(0.00)[trustedbsd-discuss@trustedbsd.org]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[204.107.128.30:from:127.0.2.255]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; VIOLATED_DIRECT_SPF(3.50)[]; FROM_SERVICE_ACCT(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; MIME_HTML_ONLY(0.20)[]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,body]; MAILMAN_DEST(0.00)[trustedbsd-discuss] X-Spam: Yes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 16:51:38 -0000 From owner-trustedbsd-discuss@freebsd.org Fri Nov 27 08:31:44 2020 Return-Path: Delivered-To: trustedbsd-discuss@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2DC474A1F0B for ; Fri, 27 Nov 2020 08:31:44 +0000 (UTC) (envelope-from 0100017608cbfd2f-d9efdfd8-403e-4f85-9fc1-829412e6eda7-000000@amazonses.com) Received: from cyrus.watson.org (cyrus.watson.org [204.107.128.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4Cj7C33Fhqz4lSP for ; Fri, 27 Nov 2020 08:31:43 +0000 (UTC) (envelope-from 0100017608cbfd2f-d9efdfd8-403e-4f85-9fc1-829412e6eda7-000000@amazonses.com) Received: from a9-54.smtp-out.amazonses.com (a9-54.smtp-out.amazonses.com [54.240.9.54]) by cyrus.watson.org (Postfix) with ESMTPS id B8B6D598F5 for ; Fri, 27 Nov 2020 08:22:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1606465355; h=Date:To:From:Reply-To:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=oev6wnV0fWkngjRZ9MHVaMa2AmjTQLUdSxjNHgWxaFY=; b=JxrQMKcPhWz7c4xKH1s2QSy+ghbppKngC7HOS9y5eQUmvCmbsOzxzV99nMPs3XVa sDalyc26mWhOeWW9VKd0iOh6CkNovsGDe78Czi1uq2l88QrKQK/C+Mt3wjKTsNpspjm PKUxbKHF8XRB8Q+wzcfEJPMla17+PYG6As45Tuj0= Date: Fri, 27 Nov 2020 08:22:35 +0000 To: trustedbsd-discuss@trustedbsd.org From: Protective Supply Plus Reply-To: Protective Supply Plus Subject: Sale $25 OFF Lysol Disinfectant Spray 19 oz. -12pk, 48 pk Message-ID: <0100017608cbfd2f-d9efdfd8-403e-4f85-9fc1-829412e6eda7-000000@email.amazonses.com> X-Mailer: Sendy (https://sendy.co) X-SES-Outgoing: 2020.11.27-54.240.9.54 Feedback-ID: 1.us-east-1.RTkVlVss2raM7wDWWhOx+0W68/4zoRImF6RxgXPSLsE=:AmazonSES X-Rspamd-Queue-Id: 4Cj7C33Fhqz4lSP X-Spamd-Bar: ++++++++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=JxrQMKcP; dmarc=none; spf=fail (mx1.freebsd.org: domain of 0100017608cbfd2f-d9efdfd8-403e-4f85-9fc1-829412e6eda7-000000@amazonses.com does not designate 204.107.128.30 as permitted sender) smtp.mailfrom=0100017608cbfd2f-d9efdfd8-403e-4f85-9fc1-829412e6eda7-000000@amazonses.com X-Spamd-Result: default: False [12.65 / 15.00]; HAS_REPLYTO(0.00)[web@protectivesupplyplus.com]; SUBJECT_HAS_CURRENCY(1.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[amazonses.com:+]; FORGED_SENDER(0.30)[web@protectivesupplyplus.com,0100017608cbfd2f-d9efdfd8-403e-4f85-9fc1-829412e6eda7-000000@amazonses.com]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[204.107.128.30:from]; FORGED_RECIPIENTS(2.00)[m:trustedbsd-discuss@trustedbsd.org,s:trustedbsd-discuss@freebsd.org]; ASN(0.00)[asn:11288, ipnet:204.107.128.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[web@protectivesupplyplus.com,0100017608cbfd2f-d9efdfd8-403e-4f85-9fc1-829412e6eda7-000000@amazonses.com]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all:c]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=224i4yxa5dv7c2xz3womw6peuasteono]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.76)[0.763]; HTML_SHORT_LINK_IMG_2(1.00)[]; DMARC_NA(0.00)[protectivesupplyplus.com]; PREVIOUSLY_DELIVERED(0.00)[trustedbsd-discuss@trustedbsd.org]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[204.107.128.30:from:127.0.2.255]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; VIOLATED_DIRECT_SPF(3.50)[]; FROM_SERVICE_ACCT(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; MIME_HTML_ONLY(0.20)[]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,body]; MAILMAN_DEST(0.00)[trustedbsd-discuss] X-Spam: Yes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 08:31:44 -0000 From owner-trustedbsd-discuss@freebsd.org Fri Nov 27 12:15:33 2020 Return-Path: Delivered-To: trustedbsd-discuss@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C40504A6E2B; Fri, 27 Nov 2020 12:15:33 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjD9K51VHz3Gf7; Fri, 27 Nov 2020 12:15:33 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6FE772C816; Fri, 27 Nov 2020 12:15:33 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 83A418D4A166; Fri, 27 Nov 2020 12:15:31 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id F0212E708C0; Fri, 27 Nov 2020 12:15:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gr15yS49_aqm; Fri, 27 Nov 2020 12:15:29 +0000 (UTC) Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:a426:5154:d8c0:5efb]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 321FEE707C0; Fri, 27 Nov 2020 12:15:29 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Kyle Evans" Cc: freebsd-jail , freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets Date: Fri, 27 Nov 2020 12:15:27 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 12:15:33 -0000 On 27 Nov 2020, at 5:04, Kyle Evans wrote: > (Cross-posting to -arch and -jail for maximum reach) and trustedbsd now as that is where priv(9) came from [ http://www.trustedbsd.org/privileges.html ] > A couple of times recently, I've had a need or desire to increase or > decrease privileges available to jails I create to some extent. You > can write a MAC policy for this, but at some point the downsides of > MAC policies for this became clear: it's either non-trivial to allow > the kind of flexibility you may need in configuring some of these > jails, and you have to rebuild the module otherwise. > > I've got a generally functional patch at [1] that is an approach I'd > like to request comments on for refining jail privileges. It creates a > privset that can be assigned on a per-jail basis, and a creator with > PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of the > parent prison. > > If no privset was specified at creation time, then we use the default > logic that was previously in prison_priv_check(). prison_priv_check() > has been replaced with a much simpler check of the prison's privset > for the given privilege. > > As I was writing this, I identified the first problem with it: it > doesn't currently respond to ALLOW_* updates and grant the appropriate > privileges after initialization time -- this is a pretty easy fix, and > I will do so if anyone else finds this useful. > > The other caveat is that I have no idea if there's a useful way to > expose this to jail(8) users, but they're not really the primary > target for this -- the primary target is system application developers > that want more fine control over what a jail they're creating can do. > > This is an excellent foot-gun, but with great power comes great > responsibility. While I like the idea I am not sure I like the way it is done. I think it was a long-time goal of Robert (which just never happened to day) to make priv(9) configurable from user space. I am just not sure if hanging it off jails is the right answer. The jail-set is certainly the most extensive in the system, but the priv checks are everywhere and hanging them off, say a thread or credential, would allow people to do a lot more (also non-foot-shooting) than just modifying jails. That said, jails pretty much tie into the entire td/cred concept already so we could happily use them as a jumping platform for experimenting before extending it to the entire system if we are clear that this might not be the final stable way of doing things? Lots of health, /bz From owner-trustedbsd-discuss@freebsd.org Fri Nov 27 14:41:51 2020 Return-Path: Delivered-To: trustedbsd-discuss@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 603894A9138; Fri, 27 Nov 2020 14:41:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjHQ72JMHz3NNB; Fri, 27 Nov 2020 14:41:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 422F52D50A; Fri, 27 Nov 2020 14:41:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f175.google.com with SMTP id t5so3363851qtp.2; Fri, 27 Nov 2020 06:41:51 -0800 (PST) X-Gm-Message-State: AOAM532y6KUvdTnZlYJ/PnxCpsVWuleUXmVQ64fcSUr7s0iL+mjEiAgL mhG/DuoYJbDDYrV/3PueGPrU94HRsNzTER9ceTs= X-Google-Smtp-Source: ABdhPJx8fH10l06qJCrMy5S2BJgnmoiLQONDyYU2hGGgLq4cvXSSON0uGDwSQxykXlFV5UePS4DYZqacfqGazWfzn7o= X-Received: by 2002:ac8:5345:: with SMTP id d5mr8761413qto.60.1606488110643; Fri, 27 Nov 2020 06:41:50 -0800 (PST) MIME-Version: 1.0 References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> In-Reply-To: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> From: Kyle Evans Date: Fri, 27 Nov 2020 08:41:39 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Jail privsets To: "Bjoern A. Zeeb" Cc: freebsd-jail , "freebsd-arch@freebsd.org" , trustedbsd-discuss@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 14:41:51 -0000 On Fri, Nov 27, 2020 at 6:15 AM Bjoern A. Zeeb wrote: > > On 27 Nov 2020, at 5:04, Kyle Evans wrote: > > > (Cross-posting to -arch and -jail for maximum reach) > > and trustedbsd now as that is where priv(9) came from [ > http://www.trustedbsd.org/privileges.html ] > > > A couple of times recently, I've had a need or desire to increase or > > decrease privileges available to jails I create to some extent. You > > can write a MAC policy for this, but at some point the downsides of > > MAC policies for this became clear: it's either non-trivial to allow > > the kind of flexibility you may need in configuring some of these > > jails, and you have to rebuild the module otherwise. > > > > I've got a generally functional patch at [1] that is an approach I'd > > like to request comments on for refining jail privileges. It creates a > > privset that can be assigned on a per-jail basis, and a creator with > > PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of the > > parent prison. > > > > If no privset was specified at creation time, then we use the default > > logic that was previously in prison_priv_check(). prison_priv_check() > > has been replaced with a much simpler check of the prison's privset > > for the given privilege. > > > > As I was writing this, I identified the first problem with it: it > > doesn't currently respond to ALLOW_* updates and grant the appropriate > > privileges after initialization time -- this is a pretty easy fix, and > > I will do so if anyone else finds this useful. > > > > The other caveat is that I have no idea if there's a useful way to > > expose this to jail(8) users, but they're not really the primary > > target for this -- the primary target is system application developers > > that want more fine control over what a jail they're creating can do. > > > > This is an excellent foot-gun, but with great power comes great > > responsibility. > > While I like the idea I am not sure I like the way it is done. > > I think it was a long-time goal of Robert (which just never happened to > day) to make priv(9) configurable from user space. > > I am just not sure if hanging it off jails is the right answer. > The jail-set is certainly the most extensive in the system, but the priv > checks are everywhere and hanging them off, say a thread or credential, > would allow people to do a lot more (also non-foot-shooting) than just > modifying jails. > > That said, jails pretty much tie into the entire td/cred concept already > so we could happily use them as a jumping platform for experimenting > before extending it to the entire system if we are clear that this might > not be the final stable way of doing things? > Hi, So, FWIW, I had mapped this out a little further in my head but hadn't quite decided on the best approach so I had stuck to jails for the time being because that's the scenario that crops up the most for me thus far. Here's the line of reasoning I went through up to this point, for full disclosure: cred-based seems like a good approach, but the caveat is that they're a little more difficult to target in a meaningful way to the admin, AFAICT. I really like cpuset(1) and the accompanying interfaces, as there's a lot of flexibility to be had there. It uses relatable concepts that have obvious semantics: - You can restrict a jail, it cascades down - You can restrict a process, it cascades down - You can restrict a thread So I started there at the first level, because it doesn't actually preclude the later levels. As you step down the tree, I think you simply step away from the need to have prison_priv_check() at all and just naturally push it all down into priv_check() because the fact that they're in a jail has either already been accounted for or is now completely irrelevant. Thanks, Kyle Evans From owner-trustedbsd-discuss@freebsd.org Sat Nov 28 05:56:51 2020 Return-Path: Delivered-To: trustedbsd-discuss@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2DDFD477097 for ; Sat, 28 Nov 2020 05:56:51 +0000 (UTC) (envelope-from 010001760d66d241-80b0ff59-8f1b-4c5b-b705-4f72583c22d8-000000@amazonses.com) Received: from cyrus.watson.org (cyrus.watson.org [204.107.128.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4Cjgjt4hsDz3FDx for ; Sat, 28 Nov 2020 05:56:50 +0000 (UTC) (envelope-from 010001760d66d241-80b0ff59-8f1b-4c5b-b705-4f72583c22d8-000000@amazonses.com) Received: from a9-99.smtp-out.amazonses.com (a9-99.smtp-out.amazonses.com [54.240.9.99]) by cyrus.watson.org (Postfix) with ESMTPS id 90F2A62690 for ; Sat, 28 Nov 2020 05:50:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1606542611; h=Date:To:From:Reply-To:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type:Feedback-ID; bh=wlfkWotfQvq5IhfxU/VSZAehGrCo7pKE+UQRbVSB/YY=; b=iaRbh6279GJqUvgTn5kFPBhrLt7/693YZxYDDkCJ+W9Ilo46o646MHjeKajXt/bm 31zBYlQq8y0cb3AfPa18ErxRbY/G/K8I3Y0ODdhfLFqzjwmFtQsqT9huqonhHay51c4 zkDkYLVPS3gAzesTtYCgN9v8jgsgU8LrWvMBkDyA= Date: Sat, 28 Nov 2020 05:50:11 +0000 To: trustedbsd-discuss@trustedbsd.org From: Protective Supply Plus Reply-To: Protective Supply Plus Subject: Sale $25 OFF Lysol Disinfectant Spray 19 oz. -12pk, 48 pk Message-ID: <010001760d66d241-80b0ff59-8f1b-4c5b-b705-4f72583c22d8-000000@email.amazonses.com> X-Mailer: Sendy (https://sendy.co) X-SES-Outgoing: 2020.11.28-54.240.9.99 Feedback-ID: 1.us-east-1.RTkVlVss2raM7wDWWhOx+0W68/4zoRImF6RxgXPSLsE=:AmazonSES X-Rspamd-Queue-Id: 4Cjgjt4hsDz3FDx X-Spamd-Bar: ++++++++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=iaRbh627; dmarc=none; spf=fail (mx1.freebsd.org: domain of 010001760d66d241-80b0ff59-8f1b-4c5b-b705-4f72583c22d8-000000@amazonses.com does not designate 204.107.128.30 as permitted sender) smtp.mailfrom=010001760d66d241-80b0ff59-8f1b-4c5b-b705-4f72583c22d8-000000@amazonses.com X-Spamd-Result: default: False [12.89 / 15.00]; HAS_REPLYTO(0.00)[web@protectivesupplyplus.com]; SUBJECT_HAS_CURRENCY(1.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[amazonses.com:+]; FORGED_SENDER(0.30)[web@protectivesupplyplus.com,010001760d66d241-80b0ff59-8f1b-4c5b-b705-4f72583c22d8-000000@amazonses.com]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[204.107.128.30:from]; FORGED_RECIPIENTS(2.00)[m:trustedbsd-discuss@trustedbsd.org,s:trustedbsd-discuss@freebsd.org]; ASN(0.00)[asn:11288, ipnet:204.107.128.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[web@protectivesupplyplus.com,010001760d66d241-80b0ff59-8f1b-4c5b-b705-4f72583c22d8-000000@amazonses.com]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all:c]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=224i4yxa5dv7c2xz3womw6peuasteono]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; HTML_SHORT_LINK_IMG_2(1.00)[]; PREVIOUSLY_DELIVERED(0.00)[trustedbsd-discuss@trustedbsd.org]; DMARC_NA(0.00)[protectivesupplyplus.com]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[204.107.128.30:from:127.0.2.255]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; VIOLATED_DIRECT_SPF(3.50)[]; FROM_SERVICE_ACCT(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; MIME_HTML_ONLY(0.20)[]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,body]; MAILMAN_DEST(0.00)[trustedbsd-discuss] X-Spam: Yes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 05:56:51 -0000 From owner-trustedbsd-discuss@freebsd.org Sat Nov 28 13:19:08 2020 Return-Path: Delivered-To: trustedbsd-discuss@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9EDDD4A1372; Sat, 28 Nov 2020 13:19:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjsXD3mk0z3qHk; Sat, 28 Nov 2020 13:19:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 440E8824A; Sat, 28 Nov 2020 13:19:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 265988D4A222; Sat, 28 Nov 2020 13:19:06 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 80E3BE707EC; Sat, 28 Nov 2020 13:19:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id VUKhagN7Sp-T; Sat, 28 Nov 2020 13:19:03 +0000 (UTC) Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:501c:cc48:65a0:381e]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D2DBCE707D6; Sat, 28 Nov 2020 13:19:02 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Kyle Evans" Cc: freebsd-jail , freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets Date: Sat, 28 Nov 2020 13:19:01 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> In-Reply-To: References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 13:19:08 -0000 On 27 Nov 2020, at 14:41, Kyle Evans wrote: > On Fri, Nov 27, 2020 at 6:15 AM Bjoern A. Zeeb wrote: >> >> On 27 Nov 2020, at 5:04, Kyle Evans wrote: >> >>> (Cross-posting to -arch and -jail for maximum reach) >> >> and trustedbsd now as that is where priv(9) came from [ >> http://www.trustedbsd.org/privileges.html ] >> >>> A couple of times recently, I've had a need or desire to increase or >>> decrease privileges available to jails I create to some extent. You >>> can write a MAC policy for this, but at some point the downsides of >>> MAC policies for this became clear: it's either non-trivial to allow >>> the kind of flexibility you may need in configuring some of these >>> jails, and you have to rebuild the module otherwise. >>> >>> I've got a generally functional patch at [1] that is an approach I'd >>> like to request comments on for refining jail privileges. It creates >>> a >>> privset that can be assigned on a per-jail basis, and a creator with >>> PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of >>> the >>> parent prison. >>> >>> If no privset was specified at creation time, then we use the >>> default >>> logic that was previously in prison_priv_check(). >>> prison_priv_check() >>> has been replaced with a much simpler check of the prison's privset >>> for the given privilege. >>> >>> As I was writing this, I identified the first problem with it: it >>> doesn't currently respond to ALLOW_* updates and grant the >>> appropriate >>> privileges after initialization time -- this is a pretty easy fix, >>> and >>> I will do so if anyone else finds this useful. >>> >>> The other caveat is that I have no idea if there's a useful way to >>> expose this to jail(8) users, but they're not really the primary >>> target for this -- the primary target is system application >>> developers >>> that want more fine control over what a jail they're creating can >>> do. >>> >>> This is an excellent foot-gun, but with great power comes great >>> responsibility. >> >> While I like the idea I am not sure I like the way it is done. >> >> I think it was a long-time goal of Robert (which just never happened >> to >> day) to make priv(9) configurable from user space. >> >> I am just not sure if hanging it off jails is the right answer. >> The jail-set is certainly the most extensive in the system, but the >> priv >> checks are everywhere and hanging them off, say a thread or >> credential, >> would allow people to do a lot more (also non-foot-shooting) than >> just >> modifying jails. >> >> That said, jails pretty much tie into the entire td/cred concept >> already >> so we could happily use them as a jumping platform for experimenting >> before extending it to the entire system if we are clear that this >> might >> not be the final stable way of doing things? >> > > Hi, > > So, FWIW, I had mapped this out a little further in my head but hadn't > quite decided on the best approach so I had stuck to jails for the > time being because that's the scenario that crops up the most for me > thus far. > > Here's the line of reasoning I went through up to this point, for full > disclosure: > > cred-based seems like a good approach, but the caveat is that they're > a little more difficult to target in a meaningful way to the admin, > AFAICT. > > I really like cpuset(1) and the accompanying interfaces, as there's a > lot of flexibility to be had there. It uses relatable concepts that > have obvious semantics: > > - You can restrict a jail, it cascades down > - You can restrict a process, it cascades down > - You can restrict a thread > > So I started there at the first level, because it doesn't actually > preclude the later levels. As you step down the tree, I think you > simply step away from the need to have prison_priv_check() at all and > just naturally push it all down into priv_check() because the fact > that they're in a jail has either already been accounted for or is now > completely irrelevant. To finish this for jails, like devfs rules or cpuset or FIB (though different interfaces), we’d have a one or two “default” priv_sets defined in user space for jails then (if I understand you correctly), and jail(8)/jail_conf/jail syscalls would simply apply that (and it could be changed while running). And yes, that would indeed simplify our jail and network stack (and some other) code quite a bit. I’d love this (step-by-step or in whole right away) :-) Bjoern From owner-trustedbsd-discuss@freebsd.org Sat Nov 28 14:39:26 2020 Return-Path: Delivered-To: trustedbsd-discuss@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CFAEB4A2552; Sat, 28 Nov 2020 14:39:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjvJt5Q0zz3t43; Sat, 28 Nov 2020 14:39:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id A79E08DC2; Sat, 28 Nov 2020 14:39:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f180.google.com with SMTP id i199so6872975qke.5; Sat, 28 Nov 2020 06:39:26 -0800 (PST) X-Gm-Message-State: AOAM533hOCQuzFjxxUQM9PpKSLXjxHrOQLviobxI0jJf2ei8h73xZh6p dlcXsy7VQ1rFNjKJ2y54B+nqqpibEBpcmSbhGaM= X-Google-Smtp-Source: ABdhPJzTBuG5KrgkFhRcsL7UoVItLgBHwf8OiaTkcsENJuIpNDInWtEojOKeRWvoERbhh7eJK3WkRXB5r4xhosOOSsI= X-Received: by 2002:ae9:e00e:: with SMTP id m14mr13764876qkk.34.1606574365869; Sat, 28 Nov 2020 06:39:25 -0800 (PST) MIME-Version: 1.0 References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> In-Reply-To: <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> From: Kyle Evans Date: Sat, 28 Nov 2020 08:39:08 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Jail privsets To: "Bjoern A. Zeeb" Cc: freebsd-jail , "freebsd-arch@freebsd.org" , trustedbsd-discuss@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 14:39:26 -0000 On Sat, Nov 28, 2020 at 7:19 AM Bjoern A. Zeeb wrote: > > On 27 Nov 2020, at 14:41, Kyle Evans wrote: > > > On Fri, Nov 27, 2020 at 6:15 AM Bjoern A. Zeeb wrote: > >> > >> On 27 Nov 2020, at 5:04, Kyle Evans wrote: > >> > >>> (Cross-posting to -arch and -jail for maximum reach) > >> > >> and trustedbsd now as that is where priv(9) came from [ > >> http://www.trustedbsd.org/privileges.html ] > >> > >>> A couple of times recently, I've had a need or desire to increase or > >>> decrease privileges available to jails I create to some extent. You > >>> can write a MAC policy for this, but at some point the downsides of > >>> MAC policies for this became clear: it's either non-trivial to allow > >>> the kind of flexibility you may need in configuring some of these > >>> jails, and you have to rebuild the module otherwise. > >>> > >>> I've got a generally functional patch at [1] that is an approach I'd > >>> like to request comments on for refining jail privileges. It creates > >>> a > >>> privset that can be assigned on a per-jail basis, and a creator with > >>> PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of > >>> the > >>> parent prison. > >>> > >>> If no privset was specified at creation time, then we use the > >>> default > >>> logic that was previously in prison_priv_check(). > >>> prison_priv_check() > >>> has been replaced with a much simpler check of the prison's privset > >>> for the given privilege. > >>> > >>> As I was writing this, I identified the first problem with it: it > >>> doesn't currently respond to ALLOW_* updates and grant the > >>> appropriate > >>> privileges after initialization time -- this is a pretty easy fix, > >>> and > >>> I will do so if anyone else finds this useful. > >>> > >>> The other caveat is that I have no idea if there's a useful way to > >>> expose this to jail(8) users, but they're not really the primary > >>> target for this -- the primary target is system application > >>> developers > >>> that want more fine control over what a jail they're creating can > >>> do. > >>> > >>> This is an excellent foot-gun, but with great power comes great > >>> responsibility. > >> > >> While I like the idea I am not sure I like the way it is done. > >> > >> I think it was a long-time goal of Robert (which just never happened > >> to > >> day) to make priv(9) configurable from user space. > >> > >> I am just not sure if hanging it off jails is the right answer. > >> The jail-set is certainly the most extensive in the system, but the > >> priv > >> checks are everywhere and hanging them off, say a thread or > >> credential, > >> would allow people to do a lot more (also non-foot-shooting) than > >> just > >> modifying jails. > >> > >> That said, jails pretty much tie into the entire td/cred concept > >> already > >> so we could happily use them as a jumping platform for experimenting > >> before extending it to the entire system if we are clear that this > >> might > >> not be the final stable way of doing things? > >> > > > > Hi, > > > > So, FWIW, I had mapped this out a little further in my head but hadn't > > quite decided on the best approach so I had stuck to jails for the > > time being because that's the scenario that crops up the most for me > > thus far. > > > > Here's the line of reasoning I went through up to this point, for full > > disclosure: > > > > cred-based seems like a good approach, but the caveat is that they're > > a little more difficult to target in a meaningful way to the admin, > > AFAICT. > > > > I really like cpuset(1) and the accompanying interfaces, as there's a > > lot of flexibility to be had there. It uses relatable concepts that > > have obvious semantics: > > > > - You can restrict a jail, it cascades down > > - You can restrict a process, it cascades down > > - You can restrict a thread > > > > So I started there at the first level, because it doesn't actually > > preclude the later levels. As you step down the tree, I think you > > simply step away from the need to have prison_priv_check() at all and > > just naturally push it all down into priv_check() because the fact > > that they're in a jail has either already been accounted for or is now > > completely irrelevant. > > > To finish this for jails, like devfs rules or cpuset or FIB (though > different interfaces), > we=E2=80=99d have a one or two =E2=80=9Cdefault=E2=80=9D priv_sets define= d in user space > for jails then > (if I understand you correctly), and jail(8)/jail_conf/jail syscalls > would simply > apply that (and it could be changed while running). > Yeah, so jail sets are a little tricky, and to be honest I haven't really thought about how to cope with common jail sets. The complication arises because you have various allow flags that typically default to off and turn privileges on, but your common sets would have to include them. So, you'd probably end up with: privset 0: All privs available to the superuser (not considering superuser policy just yet) privset 1: All privs available to jails (assuming most permissive, all allow flags on and assuming a new vnet on VIMAGE systems) So jails would typically inherit privset 1, but they'd have to mask out based on vnet/allow flags out of necessity. Now, that's not terrible, but I think we'd have to do a couple more things to reduce maintenance burden on folks introducing privs: 1.) Clearly define a central table that maps pr_flags <-> privs where there's a 1:1 mapping (most common, though PRIV_VFS_*MOUNT* are a little more complicated) 2.) Walk said table when we're defining privs in privset 1 3.) Walk said table when we're determining what to mask out I suspect the vnet set is large enough that we'd just have a separate kernel-internal mask for "vnet privs". In any event, for most people, there will be one of three places that you might touch when adding a new priv flag or pr_flag mapping to a priv, but it should still be obvious what you want: either you want a conditionally added flag, you want to influence the default jail policy, or you want to change the vnet policy. The latter two scenarios might even be a little easier, because you don't need to wade through these gigantic switch statements with a lot of cases to determine where you really want it to go. > And yes, that would indeed simplify our jail and network stack (and some > other) > code quite a bit. > > I=E2=80=99d love this (step-by-step or in whole right away) :-) > :-) I'm looking to see if I can define a useful abstraction from cpuset/domainset that would limit the amount of duplication needed for this, then I'll post a v2 to Phabricator. Thanks, Kyle Evans