From owner-svn-src-head@FreeBSD.ORG Tue Feb 4 14:10:34 2014 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6B0E3B2; Tue, 4 Feb 2014 14:10:34 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8401183; Tue, 4 Feb 2014 14:10:34 +0000 (UTC) Received: from c0216.aw.cl.cam.ac.uk (c0216.aw.cl.cam.ac.uk [128.232.100.216]) by cyrus.watson.org (Postfix) with ESMTPSA id B5EC446B2A; Tue, 4 Feb 2014 09:10:30 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 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: <52F0E9E9.2080402@freebsd.org> Date: Tue, 4 Feb 2014 14:10:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <888199BA-9D75-4144-A8E2-BE2B1E06E110@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> <6AF2ADA6-8BAD-4875-8B15-A859B41DDCC0@FreeBSD.org> <52F0E9E9.2080402@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1827) Cc: src-committers@FreeBSD.org, Doug Ambrisko , svn-src-all@FreeBSD.org, Gleb Smirnoff , James Gritton , svn-src-head@FreeBSD.org, Alexander Leidinger X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:10:35 -0000 On 4 Feb 2014, at 13:23, Julian Elischer wrote: > On 2/4/14, 3:40 PM, Robert N. M. Watson wrote: >> On 3 Feb 2014, at 23:53, Doug Ambrisko wrote: >>=20 >>> 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. >=20 >> 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 one thing that always worries me is with priv models is that I = have a nagging suspicion that to do them right > you end up having to enumerate 7,567,342 different separate privs.. = "Is allowed to take puppies for a walk", etc. > (and "is allowed to take puppies for a walk in Scotland"). Well, we've done the privilege decomposition phase already, and the = number is more around 240-250 than 7,567,342. Solaris lives in the = 90-100 range. Linux has a smaller number as they limit the bits to a = 32-bit word. In FreeBSD we selected to use the same privilege for = 'near-identical semantics' where priv_check() (previously suser()) was = called -- with the exceptions of catchalls such as PRIV_DRIVER. In = Linux, CAP_SYS_ADMIN tends to be a much broader catchall for 'things = that used to require root and have something to do with administration'. = Solaris lives between. None of these systems specialise device-driver = privileges -- instead they focus on core OS functions. Likewise, the = definition of privilege in this case is 'global' across all objects of = some type: when we bind policy to specific objects, we call it = 'permissions', 'ACLs', 'labels', etc which narrows the scope quite a = bit. Robert=