1. History of the project
The project itself was born in the summer of 1997. As administrators of a various internet servers we faced the attacks to our machines. They were mostly successful, so we soon got tired from the never-ending installation of newer version software, when the bug appeared. We wanted a solution, which would be versatile and will work against any attack. So the first version of Medusa was born. It was a quick hack to the linux kernel, which mirrored some uid-s and enabled some operations only with the right "mirror" of the uid. However, this solution was not well-designed and lasted only for a couple of months.
For the next version, we borrowed a name from the StarTrek terminology. The Medusa NG (Next Generation) implemented something like 'process capabilities', somewhat similar to the Linux capabilities, which were introduces much later. This solution was better, but its scope was limited. So we tried to create something new.
The new design, with the name from the next StarTrek movie, Medusa DS9 (Deep Space Nine) introduced the concept of virtual spaces, which proven to be universal and flexible and forms the core of todays Medusa.
To achieve some minor improvement, one could go and start adding some restrictions around the code of applications, or operating system. However, this is not a real security improvement, because:
To achieve a real security improvement, we must identify, what the objects and subjects in system are, what are the operations (accesses) in the system and how we can monitor them. The final product of this is a description of a system (which gives us a definition of objects, subjects and access types) and the security model (which says, how the permissions for accesses are granted or revoked). These two often come in couple. We made a distinction between these, because of its impact: one can often find a suitable security model immediately after defining, what the system is. Also, we want to allow user to define his own security model, as we don't want to force him to use our ones. Not saying they are bad! There are many good, proven security models, which we encourage to use.
- noone can say, whether there are no other holes in the application or the operating system
- noone can say, how much the changes really improved the security
To enforce any security model, we must be able to define the permissions, and must be able to define, how the permissions are changed during the lifetime of system. One of the classic papers, Butler Lampson's Protection, defines the access control matrix, which describes all permissions in a system in static state.
The VS model (virtual spaces model), used in Medusa, replaces the access control matrix (which is hard to implement in a real operating system). The objects and subjects are separated into the finite number of domains, named virtual spaces. Each object can be member of any number of virtual spaces at one time. Each subject is assigned a set of abilities, one for each access type. Ability is a set of virtual spaces. Acess is granted, when the object and the subject share at least one common virtual space for the given access type.
The VS model forms one part of the ZP Security Framework. Another part is a Security Decision Center, which is responsible for the dynamic changes of a security model in time. You can find details of a framework in a (yet unpublished) paper (dvi, ps). There is more theory in our thesis, which are available only in slovak language.
The Medusa DS9 is a tool, which implements the ZP Security Framework. The main goal of a project is to implement a framework for implementation of any security model. This is a main difference between Medusa and other (two?) security projects. They are implementing a particular security models and the framework, which makes the final decision. Of course, this does not mean, that you cannot use multiple security models at one time in Medusa. You can join as many models as you need, most likely using AND and OR, which is detailed in the paper above. Medusa DS9 consists of two major parts: the VS monitor, implemented in kernel of a operating system, and Security Decision Center implemented as user-space daemon called Constable. Constable is configured using our own configuration language, which is slightly based on C.