From owner-svn-src-all@FreeBSD.ORG Tue Feb 4 13:24:16 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54D8FDA8; Tue, 4 Feb 2014 13:24:16 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3081BFA; Tue, 4 Feb 2014 13:24:15 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s14DNw5D043486 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 4 Feb 2014 05:24:01 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52F0E9E9.2080402@freebsd.org> Date: Tue, 04 Feb 2014 21:23:53 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Robert N. M. Watson" , Doug Ambrisko Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <20140129134344.GW66160@FreeBSD.org> <52E906CD.9050202@freebsd.org> <20140129222210.0000711f@unknown> <20140131223011.0000163b@unknown> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> <6AF2ADA6-8BAD-4875-8B15-A859B41DDCC0@FreeBSD.org> In-Reply-To: <6AF2ADA6-8BAD-4875-8B15-A859B41DDCC0@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Gleb Smirnoff , James Gritton , svn-src-head@FreeBSD.org, Alexander Leidinger X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 13:24:16 -0000 On 2/4/14, 3:40 PM, Robert N. M. Watson wrote: > On 3 Feb 2014, at 23:53, Doug Ambrisko 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 >