Idea about 'skeleton jail

[security at revolutionsp.com]

Very nice idea!! This greatly improves jail management on FreeBSD. There
is a possibility for a minor drawback -- if one can change a system binary
in the host system, them all jails are compromised -- but assuming one
would need root access on the host to change the binary, he would have
power to change any jail anyway, so this is rather redundant.

Great feature here, when can we see this added to the system?


> On Mon, Jan 31, 2005 at 09:39:52PM +0800, Xin LI wrote:
>> Dear folks,
>>
>> The recent discussion about whether we should have the perl port to
>> touch/install /usr/bin/perl.  While I'm not interested in joining the
>> discussion, it inspired me that we can make use of the fact that ports
>> should not install things to "system" area and take advantage from it.
>> Finally these ideas results me to hack up something that might be
>> valuable to share with our users.
>>
>> What I am going to proposal is a concept that I call it "skeleton jail",
>> or "skeljail" for short.  A skel jail is something that shares most base
>> system binaries/libraries with the host, through read-only mount_null's.
>>
>> I have already done some experiments.  Basically we want the following
>> directories to be mount_null'ed:
>> 	/bin, /sbin, /lib, /libexec, /usr/bin, /usr/sbin, /usr/include,
>> 	/usr/lib, /usr/libdata, /usr/libexec, /usr/sbin, /usr/share
>>
>> To get most of what we want the jail to do, to work, this includes
>> ssh(1) and something else.  Optionally, we may want to mount_nullfs a
>> read-write /usr/ports/distfiles, a readonly /usr/ports, and something
>> like /usr/game to be mounted into the skeljail.
>>
>> In order to avoid having to do something magic instead of "make
>> installworld", I have a patchset against src/Makefile and
>> src/Makefile.incl to make the work a bit easier.  It adds a so-called
>> "installskel" target that creates a skeljail that contains necessary
>> directory hierarchy, and a set of /etc configuration files that will be
>> useful to start the jail.  The target must be used after a ``make
>> buildworld''
>>
>> The two major benefits for the skeljail are:
>> - Reduces the ordinary management cost because many base system files
>> are shared, hence you patch only once to get all jails patched.
>> - Reduces the space cost that needed for a newly created jail.  It used
>> to need about 110MB and with skeljail you will only need no more than
>> 3MB.
>>
>> Apparantly skeljail is not suitable for those who want:
>> - Run different FreeBSD releases on a single box.
>> - Run ports that does touch system area.
>>
>> But having it doesn't hurt the ability for you to run a full jail.
>>
>> I have some handcrafted shell scripts to implement skeljail by having
>> everything automatically mounted/dismounted.  However, I think it might
>> be better if we can have jail_<name>_skeljail="YES" switch in our jail
>> rc.d(8) startup script.  Please let me know if you are interested in the
>> idea and I'll post a patch for review if there's enough people that
>> wants this.
>
> Sold !  I just use the same setup you described in order to reduce disk
> usage and synchonize automatically jails with base system.  It would be
> indeed a great step forward for jail management IMHO.
>
> Why don't you simply call the target "installjail" instead of
> "installskel" ?
>
> --
> Jeremie Le Hen
> jeremie at le-hen.org
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>