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.
vimage was not originally tied to jails. I can't remember why we
decided to do that :-)
Something I've wanted to do for a while (>15 years)
{takes deep breath)
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.
oh is that all... had been imagining "climb Mount Everest",
"Photograph a giant Squid" or similar..
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 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").
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"
