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. 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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
