Date: Sat, 28 Nov 2020 13:19:01 +0000 From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: "Kyle Evans" <kevans@freebsd.org> Cc: freebsd-jail <freebsd-jail@freebsd.org>, freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets Message-ID: <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> In-Reply-To: <CACNAnaGdn4o84UmKfA=m-fWvaUSHj-1zTVsBe9cdZZy0JMzEKg@mail.gmail.com> References: <CACNAnaEKoBppjG8HH0KgYQv0EHPUcHmB3teyw1PQrjG3xsbXYQ@mail.gmail.com> <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <CACNAnaGdn4o84UmKfA=m-fWvaUSHj-1zTVsBe9cdZZy0JMzEKg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Nov 2020, at 14:41, Kyle Evans wrote: > 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6BA03DAD-BDCD-4A53-A80A-4B7B476B803C>