Date: Tue, 4 Feb 2014 14:10:28 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Julian Elischer <julian@freebsd.org> Cc: src-committers@FreeBSD.org, Doug Ambrisko <ambrisko@ambrisko.com>, 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: <888199BA-9D75-4144-A8E2-BE2B1E06E110@FreeBSD.org> In-Reply-To: <52F0E9E9.2080402@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> <52F0E9E9.2080402@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Feb 2014, at 13:23, Julian Elischer <julian@freebsd.org> wrote: > 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: >>=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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?888199BA-9D75-4144-A8E2-BE2B1E06E110>