Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Nov 2020 12:09:16 -0800
From:      James Gritton <jamie@freebsd.org>
To:        "Bjoern A. Zeeb" <bz@freebsd.org>
Cc:        Kyle Evans <kevans@freebsd.org>, freebsd-jail <freebsd-jail@freebsd.org>, freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org
Subject:   Re: RFC: Jail privsets
Message-ID:  <782331951af5589aac5d6225a274cc60@freebsd.org>
In-Reply-To: <BAD5CA23-A4B6-4C22-B095-F89217476825@FreeBSD.org>
References:  <CACNAnaEKoBppjG8HH0KgYQv0EHPUcHmB3teyw1PQrjG3xsbXYQ@mail.gmail.com> <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <CACNAnaGdn4o84UmKfA=m-fWvaUSHj-1zTVsBe9cdZZy0JMzEKg@mail.gmail.com> <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> <CACNAnaGUEZqg_4WOgZ2zAOCboBGeeOY45ie_PSkVSK=3ct4b0g@mail.gmail.com> <BAD5CA23-A4B6-4C22-B095-F89217476825@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?782331951af5589aac5d6225a274cc60>