On 4 Feb 2014, at 13:23, Julian Elischer <jul...@freebsd.org> wrote:
> On 2/4/14, 3:40 PM, Robert N. M. Watson wrote: >> On 3 Feb 2014, at 23:53, Doug Ambrisko <ambri...@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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
