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.

2. Concepts

        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:

• 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.