From owner-svn-src-all@FreeBSD.ORG Tue Feb 4 07:40:34 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 10410B70; Tue, 4 Feb 2014 07:40:34 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id BDD6E1C37; Tue, 4 Feb 2014 07:40:33 +0000 (UTC) Received: from [10.0.1.9] (host31-51-142-185.range31-51.btcentralplus.com [31.51.142.185]) by cyrus.watson.org (Postfix) with ESMTPSA id 7C21C46B09; Tue, 4 Feb 2014 02:40:21 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail From: "Robert N. M. Watson" In-Reply-To: <20140203235336.GA46006@ambrisko.com> Date: Tue, 4 Feb 2014 07:40:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6AF2ADA6-8BAD-4875-8B15-A859B41DDCC0@FreeBSD.org> 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> To: Doug Ambrisko X-Mailer: Apple Mail (2.1827) 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 07:40:34 -0000 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 = contradition. > 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 = ssh > 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. Something I've wanted to do for a while (>15 years) is move from a = simple privilege model to a privilege-mask model in which masks of = available system privileges can be delegated to jails rather than = hard-coding the list of privileges in jails. I got about 1/3 of the way = there with priv(9): enumerating system privileges, and shifting = knowledge of "is it available in jail" out of calling 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 = configuration. This requires introducing an /etc/security/privileges, = and a default /etc/security/jail.privileges (or similar) that provide a = mapping 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, rather than lots of custom sysctls and extensions. We = could even provide different 'profiles' such as 'jail.default' for the = current model, and perhaps 'jail.allrights' to capture the idea of a = child jail that retains all privileges the parent jail held. We might = ask users to say --I-am-really-sure (or something less obnoxious but = equally prominent) to create jails to which stronger rights than the = default are granted. The final phase is to introduce a process-exposed privilege model = allowing individual processes to manage privilege masks. In about 2000, = Brian Feldman and I implemented POSIX.1e privileges [twice] for FreeBSD = (not too different from what Linux implemented, and derived form the = model in IRIX) but were deeply unimpressed. The current Solaris model is = probably closest to what we want, but we'd have to think through it = pretty carefully. One of the reasons we never merged our POSIX.1e = implementation was that although the model itself worked OK, various = compatibility modes (such as the one adopted in Linux) led to serious = but quite subtle security vulnerabilities. This is not a phase to embark = on without a *lot* of thought. 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 = number of other problems. The risks involved are significant -- it's = very, very easy to get wrong (as we convinced ourselves on multiple = occasions, and from having looked at problems in other UNIX systems that = went this route) -- so it really does require time and a lot of review = of both the model 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 privileges), as well as a sensible = kernel<->kernel ABI (one that's relatively stable but perhaps less = extensible -- with performance benefits over the extensible interface). Robert=