From owner-freebsd-arch@freebsd.org Fri Nov 27 12:15:33 2020 Return-Path: Delivered-To: freebsd-arch@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: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture 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