Escape consists of a kernel, drivers, libraries and user applications. The kernel is responsible for processes, threads, memory management, a virtual file system (VFS) and some other things. Drivers run in user space and work via message passing. They do not necessarily access the hardware and should therefore more seen as an instance that provides a service.
The VFS is one of the central points of Escape. Besides the opportunity to create files and folders in it, it is used to provide information about the state of the system for the user space (memory usage, CPU, running processes, ...). Most important, the VFS is used to communicate with devices, which are registered and handled by drivers. That means, each device gets a node in the VFS over which it can be accessed. So, for example an open("/dev/zero",...) would open the device "zero". Afterwards one can use the received file descriptor to communicate with it.
Basically, the communication works over messages. Escape provides the system calls send and receive for that purpose. Additionally, Escape defines standard messages for open, read, write and close, which devices may support. For example, when using the read system call with a file descriptor for a device, Escape will send the read message to the corresponding device and handle the communication for the user program. As soon as the answer is available, the result is passed back to the user program that called read. Because of this mechanism the user space doesn't have to distinguish between virtual files, "real" files and devices. So, for example the tool cat can simply do an open and use read to read from that file and write to write to stdout.
The same mechanism is used for filesystems, which can be mounted somewhere in the VFS. If a file is opened which belongs to one of these mounted filesystems, the kernel will handle the communication with the driver that has been registers as being responsible for this filesystem. This does not only serve for getting filesystems out of the kernel, but does also provide the possibility to use the filesystem interface whenever it fits. For example, Escape has a ftpfs that allows you to access a FTP server by mounting it somewhere and a tarfs to access and/or change a tar file.
Escape has also an interesting sandboxing mechanism, which causes no performance overhead, can be used by unprivileged users (non-root) and is nestable (sandboxed processes can create sandboxes). In general, Escape does not allow to upgrade privileges, but only to downgrade them. To downgrade permissions, the sandbox application can be used. It allows to leave groups to restrict the access to drivers and services. And it allows to remount directories in the filesystem to reduce the permissions of entire subtrees. Let's consider a (non-existing) music player as an example. We could use sandbox to:
- leave all groups, except audio
- remove all access to the filesystem, except read+exec permission to its own directory containing the executable, libraries, etc. and read permission to the directory that contains the music library.
Although the music player runs with our user, which makes sandboxing simple, it can't cause any harm to the rest of the system.
