From owner-trustedbsd-discuss@freebsd.org Sun Nov 29 20:09:23 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 C6AF54ABCBA; Sun, 29 Nov 2020 20:09:23 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [199.192.165.131]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ckfb74nkjz3MJs; Sun, 29 Nov 2020 20:09:23 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org ([127.0.0.131]) (authenticated bits=0) by gritton.org (8.15.2/8.15.2) with ESMTPA id 0ATK9Ggf019835; Sun, 29 Nov 2020 12:09:16 -0800 (PST) (envelope-from jamie@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 29 Nov 2020 12:09:16 -0800 From: James Gritton To: "Bjoern A. Zeeb" Cc: Kyle Evans , freebsd-jail , freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets In-Reply-To: References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> User-Agent: Roundcube Webmail/1.4.1 Message-ID: <782331951af5589aac5d6225a274cc60@freebsd.org> X-Sender: jamie@freebsd.org X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (gritton.org [127.0.0.131]); Sun, 29 Nov 2020 13:09:16 -0700 (MST) X-Rspamd-Queue-Id: 4Ckfb74nkjz3MJs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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: Sun, 29 Nov 2020 20:09:23 -0000 On 2020-11-29 04:51, Bjoern A. Zeeb wrote: > On 28 Nov 2020, at 14:39, Kyle Evans wrote: > > Hi, > > Cc: jamie explicitly as he might have thoughts as well. Heh - I've been following along, and my thought have mostly consisted of "well this is interesting and complicated." :-) >> 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. > > I think this is all terribly too complicated. > > If we’ll have manageable fine-grained priv system, them retire allow > and > vnet checks for PRIV_* checks and be done with it. If we need new > PRIV_* > checks to accomplish that adding PRIV_* is semi-cheap to add. > > The big switch statements in kern_jail.c will go as the applied priv > set > will do the right thing already, which means at this point we’d have > a base-system-privset, a classic-jail-privset, a vnet-jail-privset by > default probably. > > If we want to keep allow* in jails we can probably make them compat > code > to adjust PRIV_* but I am not sure I’d want jail to still do that or a > separate priv command (a la cpuset). > > Means jails become simple again and a lot of the complicate logic can > drop out. I'm not against deprecating the allow.* hooks, but I suspect they'll end up sticking around a long time (forever) in deprecated form. I've considered removing the old global security.jail.whatever_allowed sysctls that cause more confusion than anything else, and kind of had to give it up against a wall of concern that somebody out there still used it. I'll admit that the proliferation of allow.mount.foofs is kind of abomination, but that's kind of how things grew up, and there isn't a good fit with the current priv system. It could well be that all of those are unnecessary and we either trust jails to mount all of the filesystems of none of the filesystems. However it works out, I agree that a single view of privilege management makes more sense than multiple ways of saying the same thing. So I (without having studied it much) tend to agree with the idea of reducing the jail/priv shim layer as much as possible. I'm just not sure how possible it will be. - Jamie