Detecting a Chroot Jail from Within

Detecting a chroot jail from within

The inode for / will always be 2 if it's the root directory of an ext2/ext3/ext4 filesystem, but you may be chrooted inside a complete filesystem. If it's just chroot (and not some other virtualization), you could run mount and compare the mounted filesystems against what you see. Verify that every mount point has inode 2.

Create a Chroot Jail and copy all system files into jail

Executables like ls/cd/gcc/g++, they depend on shared library (unless you didn't build them to be statically). So, what you need to do is copy all those shared library dependencies to appropriate location into your chroot jail, also you need to find what are those shared dependencies are. To find out you need help from "ldd".

To see what shared dependencies gcc has, do the following:

           ldd /usr/bin/gcc

On my system it shows the following output:

linux-vdso.so.1 =>  (0x00007fffd9bff000)
libc.so.6 => /lib64/libc.so.6 (0x00000030c9c00000)
/lib64/ld-linux-x86-64.so.2 (0x00000030c9800000)

So, gcc has the dependency of standard c library libc.so and it also needs ld (executable loader), place these shared libraries into appropriate place (i.e libc under /lib64) into your chroot jail, along with gcc. So gcc can load necessary stuffs while you call gcc.

What Jail/Chroot/Sandbox-like mechanisms are available on OpenBSD?

Currently OpenBSD doesn't support any "chroot on steroid" mechanism. In the past, same jail feature (named sysjail) was in ports, but removed in 2007 because it was not easy to maintain and pretty insecure. You can find more information about it on stackexchange and with your search engine.

Historically, OpenBSD only support chroot(8) and work exactly like other system:

1. create an alternative root with userland on it

# create your target chroot
target="/tmp/chroot"
mkdir ${target}

# now build and install your userland
cd /usr
cvs -qz3 -d${repository} co src -r${openbsd_release}
cd /usr/src
make obj && make && make install DESTDIR=${target}

2. start your daemon or your soft in it

# in root
chroot /tmp/chroot

# run your daemon here
# note: you need to init also dev directory
#       and, eventually, customize /etc/fstab
#       /tmp is currently not allowed to have dev on it
#       please see fstab(5) man page

Lot of software in base support chroot feature, openntpd, openssh, httpd and many others are configured by default in isolated directory.

Now, since OpenBSD 5.9, you can use vmm(4) hypervisor and vmctl(8) in base. You can start your vmd daemon and create isolated container like any other hypervisor (bhyve, xen or kvm).

# from openbsd vmctl man page example
vmctl create disk.img -s 4.5G
vmctl start "myvm" -m 512M -i 1 -d disk.img -k /bsd
vmctl stop 1

You can also use another approach based on software in ports, qemu work pretty well but have poor performance on OpenBSD, due to lake of kernel acceleration support and in parts because of filesystem structure.

Now, concerning your main issue (offer a way of remote compiling source code), I guess the better idea is to truly isolate your code from main system, and using something like vmctl or qemu could be the good answer. Perhaps qemu would be the better, because you can use standard user to execute it, without kernel feature and with lot of network features, but compilation would be really slow.

Is it possible let chroot jails share directories(read-only) outside the jail?

You can use the new bind mounts support to make identical directory structures available through multiple paths.

mount --bind /usr/bin /path/to/chroot/jail/usr/bin
mount -o remount,ro /path/to/chroot/jail/usr/bin

For more details, see mount(8).

You can get really clever with mounting on Linux systems these days; for more details, see the Linux kernel source file Documentation/filesystems/sharedsubtree.txt.

What's the difference between a Linux chroot jail and a FreeBSD jail?

Actually, they have almost nothing in common.

A Linux "chroot environment" is just what / resolves to for a single process. Anything the process can do with access to that tree, it can do. So in general it can (e.g.) enumerate other processes on the system, and if it is a "root" process, it can still take over the machine.

A FreeBSD jail, on the other hand, is more like a virtual machine than a Linux chroot jail. It is a partition of the system with its own file system, user accounts, etc. The root user inside the jail only has administrative access to other objects in the jail; it cannot access anything outside of its jail.

I will not respond to the "more secure" or "more flexible" questions since those are weasel words. The mechanisms are just completely different by design, that's all.

---

Related Topics