Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Nov 2020 08:41:39 -0600
From:      Kyle Evans <kevans@freebsd.org>
To:        "Bjoern A. Zeeb" <bz@freebsd.org>
Cc:        freebsd-jail <freebsd-jail@freebsd.org>,  "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, trustedbsd-discuss@freebsd.org
Subject:   Re: RFC: Jail privsets
Message-ID:  <CACNAnaGdn4o84UmKfA=m-fWvaUSHj-1zTVsBe9cdZZy0JMzEKg@mail.gmail.com>
In-Reply-To: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org>
References:  <CACNAnaEKoBppjG8HH0KgYQv0EHPUcHmB3teyw1PQrjG3xsbXYQ@mail.gmail.com> <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 27, 2020 at 6:15 AM Bjoern A. Zeeb <bz@freebsd.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaGdn4o84UmKfA=m-fWvaUSHj-1zTVsBe9cdZZy0JMzEKg>