![](/var/ezflow_site/storage/images/archive/2013/18/capsicum-additional-seasoning-for-freebsd/po-16819-creativ_collection_megapack-05_lebensmittel-ccvision-bild_23_05053_der_creativ_collection.png/99051-1-eng-US/PO-16819-Creativ_Collection_Megapack-05_Lebensmittel-ccvision-Bild_23_05053_der_Creativ_Collection.png_medium.png)
Capsicum – Additional seasoning for FreeBSD
Hot and Spicy
Administrators often break into a sweat when they read security bulletins explaining the malicious code that is currently in the wild for the programs they use. Web browsers, email programs, archiving tools, and even Office packages are affected. It is not just negligence in the use of libraries that makes it easy for intruders to execute malicious code, but also targeted attacks on vulnerable applications. The mechanisms known on FreeBSD (chroot or jails) are not really an answer.
One remedy is to lock applications up in a sandbox, an environment that provides only very limited resources. However, because FreeBSD up to version 8 does not provide such a mechanism, the Capsicum environment was created in FreeBSD 9. In addition to a protected environment (sandbox), from which applications can't break out, it supports finely granular allocation of rights.
Traditional Access Authorization
FreeBSD, Linux, and other Unix systems traditionally have had a very simple permissions system. To find the reason for this, you have to look back at early Unix systems, which were not originally designed for a desktop networked into the global Internet. This resulted in two main mechanisms of access control. The first mechanism is discretionary access control (DAC), which depends on the user ID. Here, the decision of whether a resource can be accessed is made solely on the basis of the user's identification. This means that, for each user, access rights to data are set by an administrator or by the user. The best example of this is a home directory, to which only the user has access.
The disadvantage of the method is demonstrated by the passwd
command for changing the user password. Because users can assign themselves a password or change their password in the user database, the passwd
command needs write access to the /etc/passwd
file. Only the root user has