svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail

Robert N. M. Watson rwatson at FreeBSD.org
Tue Feb 4 14:10:35 UTC 2014


On 4 Feb 2014, at 13:23, Julian Elischer <julian at 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 at 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 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.
> 
>> 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


More information about the svn-src-head mailing list