Configuration differences for jails

[c0ldbyte]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 20 Apr 2005, Jeremie Le Hen wrote:

>> I'm trying to untangle myself on this issue. I have different
>> filesystems for /, /usr, and /usr/local, mounted in unusual places:
>>
>> 504,p0,1$ ls -l /usr{,/X11R6,/local}
>> lrwxr-xr-x  1 root  wheel  18  7 nov  2003 /usr -> fs/base/mount/usr/
>> lrwxr-xr-x  1 root  wheel  25  8 nov  2003 /usr/X11R6 ->
>> ../../../apps/mount/X11R6
>> lrwxr-xr-x  1 root  wheel  25 18 abr 20:40 /usr/local ->
>> ../../../apps/mount/local
>>
>> I know I want to share /usr, but not /usr/local, and only parts of /. So
>> I mount_unionfs /fs/base inside the jail:
>>
>> <above>:/fs/base/mount on /fs/jaildata/mount/fs/base/mount (unionfs,
>> local, read-only, noclusterw)
>>
> mount_nullfs(8) will mount one directory and all its content onto another
> one, but there is no way to exclude one of the subdirectory.  You
> will instead have to mount each subdirectory you need, not more.  One
> other way do achieve this is to make a second null mount over the
> directory you don't wan't to share (/usr/local) but I'm not aware of
> the consequences of such setup in term of performance and stability.
>
>
>> But this way I don't get the "automagically upgrade virtual hosts"
>> behaviour I want, since I'm missing /{,s}bin, /lib and /libexec and I
>> definitely don't want to share /etc.
>
> You won't have a one to one mapping between jail and null mounts.  There
> are generally multiple null mounts for a unique jail.
>
> Considering your jail root is /jail/test, and you enabled the
> jail_$jail_mount (jail_test_mount here) rc.conf(5) variable, here is
> the content of /etc/fstab.test :
> %%%
>  /bin                    /jail/test/bin          nullfs  ro      0       0
>  /sbin                   /jail/test/sbin         nullfs  ro      0       0
>  /lib                    /jail/test/lib          nullfs  ro      0       0
>  /libexec                /jail/test/libexec      nullfs  ro      0       0
>  /usr/bin                /jail/test/usr/bin      nullfs  ro      0       0
>  /usr/sbin               /jail/test/usr/sbin     nullfs  ro      0       0
>  /usr/lib                /jail/test/usr/lib      nullfs  ro      0       0
>  /usr/libexec            /jail/test/usr/libexec  nullfs  ro      0       0
>  /usr/libdata            /jail/test/usr/libdata  nullfs  ro      0       0
>  /usr/share              /jail/test/usr/share    nullfs  ro      0       0
>  /usr/compat             /jail/test/usr/compat   nullfs  ro      0       0
> %%%
>
>> I don't think it's easy to take /etc/ outside the root fs, but I don't
>> see how to share /bin or /lib without leaking info.
>>
>> How do you handle this? What are those distribution targets and how can
>> I use them?
>
> As I said above, null mount each directory.
>
> Regards,

Now I havent caught this whole thread but to my understanding right now
you are talking about mounting nullfs's from the root filesystem "/"
onto the jail correct ?.

Now if that last question is correct and thats the proccess you are using
to create a jail then depending on the situation wouldnt that inturn
defeat some of the main purposes of the jail, like the following. If you
mounted your "/bin" on "/mnt/jail/bin" then if a person that was looking
to break in and effect the system that is currently locked in the "jail"
all he would have to do is just write something to the "jail/bin" which is
actualy your root "/bin" and then the next time a binary is used from your
root directories it could still infect the rest of the system ultimately
defeating the purpose of what you just set up. To my understanding and use
a jail is somewhat totaly independent of the OS that it resides in and
wont be if you are using nullfs to mount root binary directories on it.

With all due respect "This is a bad idea" given allmost any situation
that you would have to create a jail for a unsafe proccess or users.

- -- 
( When in doubt, use brute force. -- Ken Thompson 1998 )
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F
Comment: Fingerprint = D1DC 0AA4 1C4E EAD4 24EB  7E77 B261 50BA F7DF 979F

iD8DBQFCZ5DfsmFQuvffl58RAi6FAJ4n1JeS/MCN2s7zowgWrMAzdnarowCfUQ5n
sVhxoQT+nepoMnj/yYckQbs=
=+Vmn
-----END PGP SIGNATURE-----