Date: Tue, 04 Feb 2014 21:23:53 +0800 From: Julian Elischer <julian@freebsd.org> To: "Robert N. M. Watson" <rwatson@FreeBSD.org>, Doug Ambrisko <ambrisko@ambrisko.com> Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, James Gritton <jamie@FreeBSD.org>, svn-src-head@FreeBSD.org, Alexander Leidinger <Alexander@Leidinger.net> Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail Message-ID: <52F0E9E9.2080402@freebsd.org> In-Reply-To: <6AF2ADA6-8BAD-4875-8B15-A859B41DDCC0@FreeBSD.org> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <20140129134344.GW66160@FreeBSD.org> <52E906CD.9050202@freebsd.org> <20140129222210.0000711f@unknown> <alpine.BSF.2.00.1401311231490.36707@fledge.watson.org> <20140131223011.0000163b@unknown> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> <6AF2ADA6-8BAD-4875-8B15-A859B41DDCC0@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/4/14, 3:40 PM, Robert N. M. Watson wrote:
> On 3 Feb 2014, at 23:53, Doug Ambrisko <ambrisko@ambrisko.com> wrote:
>
>> It's unfortunate that vimage requires jail. I want to use vimage but
>> not have the security restrictions of a jail. To do this I patched
>> jail to basically let everything through. It would be nice to be
>> able to run jail in an insecure mode which I understand is a contradit=
ion.
>> I do use the jail infrastructure to set the uname*/getosreldate so
>> that a specific jail thinks it is FreeBSD version blah. Then I can ss=
h
>> into that jail and pkg_add things, make ports etc. I use this on
>> my laptop running current on the base. My other jails run various
>> versions of FreeBSD. I don't care about security in this case.
vimage was not originally tied to jails. I can't remember why we=20
decided to do that :-)
> Something I've wanted to do for a while (>15 years)
{takes deep breath)
> is move from a simple privilege model to a privilege-mask model in whic=
h masks of available system privileges can be delegated to jails rather t=
han hard-coding the list of privileges in jails.
oh is that all... had been imagining "climb Mount Everest",=20
"Photograph a giant Squid" or similar..
> I got about 1/3 of the way there with priv(9): enumerating system pri=
vileges, and shifting knowledge of "is it available in jail" out of calli=
ng subsystems into the privilege model itself.
>
> The next phase is to introduce a structured notion of a privilege mask =
(efficiently), and expose masks in limited circumstances -- e.g., Jail co=
nfiguration. This requires introducing an /etc/security/privileges, and a=
default /etc/security/jail.privileges (or similar) that provide a mappin=
g from user-readable privilege names to numbers, and a reasonable default=
subset mask that jail(8) can use when creating a jail. This would allow =
configuration of arbitrary privileges for jails in a generalisable way, r=
ather than lots of custom sysctls and extensions. We could even provide d=
ifferent 'profiles' such as 'jail.default' for the current model, and per=
haps 'jail.allrights' to capture the idea of a child jail that retains al=
l privileges the parent jail held. We might ask users to say --I-am-reall=
y-sure (or something less obnoxious but equally prominent) to create jail=
s to which stronger rights than the default are granted.
The one thing that always worries me is with priv models is that I=20
have a nagging suspicion that to do them right
you end up having to enumerate 7,567,342 different separate privs..=20
"Is allowed to take puppies for a walk", etc.
(and "is allowed to take puppies for a walk in Scotland").
>
> The final phase is to introduce a process-exposed privilege model allow=
ing individual processes to manage privilege masks. In about 2000, Brian =
Feldman and I implemented POSIX.1e privileges [twice] for FreeBSD (not to=
o different from what Linux implemented, and derived form the model in IR=
IX) but were deeply unimpressed. The current Solaris model is probably cl=
osest to what we want, but we'd have to think through it pretty carefully=
=2E One of the reasons we never merged our POSIX.1e implementation was th=
at although the model itself worked OK, various compatibility modes (such=
as the one adopted in Linux) led to serious but quite subtle security vu=
lnerabilities. This is not a phase to embark on without a *lot* of though=
t.
>
> There's a moderate amount of work in doing this, which I've never quite=
found time to chase up. It would be worth doing as it would solve a numb=
er of other problems. The risks involved are significant -- it's very, ve=
ry easy to get wrong (as we convinced ourselves on multiple occasions, an=
d from having looked at problems in other UNIX systems that went this rou=
te) -- so it really does require time and a lot of review of both the mod=
el and implementation. The Jail portion of it is likely the easy bit, but=
does require us to come up with a sensible user<->kernel ABI for masks (=
an extensible one, ideally, since you always find you want more privilege=
s), as well as a sensible kernel<->kernel ABI (one that's relatively stab=
le but perhaps less extensible -- with performance benefits over the exte=
nsible interface).
>
> Robert
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52F0E9E9.2080402>