Plash's sandboxing mechanism
Plash virtualizes access to the filesystem. Operations by sandboxed processes on the file namespace, such as opening a file, are mediated by a user-space process. This works by modifying library calls (such as open()) so that they make remote procedure calls (RPCs) to another process instead of making the usual Linux system calls.
Plash modifies library calls by providing a modified version of glibc, PlashGlibc. Most executables are dynamically linked to glibc, so they do not need to be recompiled in order to run under Plash.
Sandboxed processes do not use the kernel's filename-based system calls, such as "open". Plash effectively disables these system calls by putting the sandboxed process in a minimal chroot() jail, and by running the process under a dynamically-allocated user ID and group ID. See ChrootSetuidJail for details.
A sandboxed process communicates with a ServerProcess via a Unix domain socket. Plash relies heavily on the ability to send file descriptors across sockets between processes running under different UIDs. When a sandboxed process sends a request to open a file to the ServerProcess, the ServerProcess can grant the request by sending a file descriptor in reply. Once a sandboxed process has obtained a file descriptor for a file, it uses the file descriptor with no further mediation by the ServerProcess. PlashGlibc does not modify functions that operate only on file descriptors (read(), write(), mmap(), etc.), and these continue to use the usual Linux system calls.
Plash does not replace glibc for the whole system: only processes running inside a sandbox get linked with PlashGlibc. Processes outside the sandbox continue to use the regular version of glibc provided by the host GNU/Linux distribution.
Plash does not require any special Linux kernel features. The sandboxing mechanism works on unmodified Linux kernels.
Paravirtualization
Plash can be seen as a paravirtualization system. We can compare it to Xen.
Xen changes the interface between the kernel and the machine, and consequently it requires changes to the kernel. The kernel must use the Xen virtual machine's interface (which involves Xen hypervisor calls) instead of the interface provided by the real hardware. You cannot evade Xen's restrictions by running a regular kernel; the Xen hypervisor enforces the restrictions. While the kernel must be changed, userland code running under the kernel mostly requires no modification.
In contrast, Plash changes the system call interface between the sandboxed userland processes and the kernel, and consequently it requires changes to glibc, which most programs go through for making system calls. Plash disables some system calls and requires sandboxed processes to do RPCs using sendmsg()/recvmsg() instead. You cannot evade the restrictions by using a regular glibc; the restrictions are enforced by ChrootSetuidJail via the kernel. While glibc must be changed, most executables and libraries do not need to be changed.