Comparisons with other systems
Contents
SELinux, AppArmor
SELinux and AppArmor are based around the concept of having a global, static security policy, defined by an administrator. That approach has some inherent limitations. In some cases it leads to giving applications much more authority than they actually need, which violates the principle of least authority.
Consider, for example, using an e-mail application to send a file as an attachment. In a system that allows authority to be granted dynamically, such as Plash, you can grant the e-mail application process the ability to read the file you want to send. With Plash this happens through the FilePowerbox.
If authority cannot be granted dynamically, the static security policy would have to grant the e-mail application read access to all of your files, just in case you wanted to be able to send any one of them as an attachment.
Machine-level virtualization: Xen, KVM
Systems that virtualize at the machine level such as Xen and KVM tend to be heavyweight. Each virtual machine runs its own instance of the Linux kernel. Each machine tends to have its own partition with its own filesystem. Each kernel instance manages its own memory, so common files (e.g. shared libraries) do not get shared in memory between virtual machines and usually do not get shared on disc either.
This means that it is not practical to have one VM for each application on your desktop.
Xen
A similarity between Plash and Xen is that both use paravirtualization, though at different levels of the system. See HowPlashWorks.
Chroot jails
Plash is more flexible, lighterweight and more secure than chroot jails (although Plash currently uses a chroot jail as part of its implementation; see ChrootSetuidJail).
The chroot() system call can only be used by root, because of its interaction with setuid executables. Plash allows sandboxed processes to be launched by regular users. (Note that Plash does not implement setuid executables.)
The mechanisms for setting up the contents of a chroot() jail are limited:
- Files can be copied or hard-linked into the jail directory
- Files and directories can be bound using "mount --bind".
- Currently, this does not allow granting read-only access, although some work is being done to add that feature.
- Bind mounts do not compose properly. For example:
mount --bind /foo /a/foocopy mount --bind /a /bar
- You will not see /foo mounted under /bar/foocopy
These mechanisms are relatively heavyweight. They must be torn down when the jail is no longer needed (files unlinked and mounts unmounted). In contrast, Plash namespaces will be freed when no process is using them.
chroot() jails are not secure by themselves. A chrooted process can take over other processes outside the chroot running with the same UID by using ptrace(). To be secure, the jailed process must be given a different UID/GID.