Medusa is a kernel patch that improves security by providing a seamless protective layer between system resources and applications, providing access control to system resources.

Brief


A project called Medusa provides a Linux kernel patch that intercepts certain kernel routines and queries an extra-kernel security provider.  While this is similar to PAM, it has a number of advantages.  First and foremost, applications are ignorant of the security system; they don't have to be specially coded to take advantage of the system.  Second, security applies to a wide range of system resources, with a high level of granularity.  Medusa, therefore, provides not only file-level access control, but can also be configured to control access to processes, or virtually any other system resource.

Detailed


Introduction


Security in Linux, for a long time, has been no better than Unix in general; that is to say, "not good".  Linux security has been better than for manyother common operating systems, but suffers from one fundamental flaw: the superuser.

Linux vs. MVS security


In Unix, if you compromise one user in particular, 'root', you have access to the entire system; no actions are denied you. You can hack the system and then cover your tracks, erasing log files and emplacing back-doors.  This is a greater problem than it initially appears, because of the fact that many daemons run as root.  Bugs in the daemons often lead to exploits which leave the intruder with root access, without the intruder ever having to have dealt with the normal Linux authentication mechanism.  Fixing security problems by addressing each bug in the daemons is akin to cutting heads off a hydra.  The bugs need to be addressed, but a better solution is one where it the amount of damage that can be caused by the exploit of a bug in a program is minimized.

MVS does not have this problem.  Root's responsibilities are divided up among multiple administrative users, so that no one user alone can compromise a system.  It does this through a mechanism in the kernel that queries an external security manager program when certain kernel routines are called. Examples of these routines are exec(), kill(), nice(), and the various file access methods.  If the security manager allows the action, the kernel goes ahead and performs the action.

Taking the security manager out of the kernel has numerous advantages.  It allows the security manager to be updated without recompiling the kernel, it allows systems administrators to (more) easily implement their own security extensions, and in decoupling the kernel from security decisions, it makes the system more objectified.

There are several things that can be done with MVS-style security that simply can't be done with vanilla Unix, and which are not available with any one extension mechanism.  PAM allows Linux to swap out authentication mechanisms, but the software that uses PAM must be PAM aware, and PAM's functionality domain is strictly in authentication.  You can not, for instance, provide file system ACLs using PAM alone.  While there are some file systems and extensions to file systems which implement ACLs, they do not provide ACL control of processes.  There are few, if any, process control extensions, and those that do exist generally don't provide the ability to restrict root's god-like powers over the system.

Enter Medusa


Medusa, at FORNAX Magazín | Články o produktoch a službách na internete, is a project to provide MVS-like security management for Linux.  At this point, Medusa only exists for the Linux kernel.  Together with PAM, Medusa provides all of the tools that are needed to make Linux as secure as MVS.

Medusa consists primarily of a kernel patch and a security agent.  The kernel patch provides intercepts for certain kernel functions.  When one of these kernel functions is called, Medusa takes over and passes state information to the security agent process which uses the information to decide whether or not to allow the action.  The security agent, called "constable", can choose to allow or deny the action, as well as redirect the action. Redirecting simply means performing some other action than the one requested.

With Medusa in place, the granularity of control over system security is much better than that of vanilla Linux.  One of the most important ways that Medusa can help secure a system is in restricting root.  For example, a new user, called "logadmin" could be created.  This user would be given complete control over the log files and the syslog daemon.  Even root would not be able to delete log files or kill the syslog daemon.  Therefore, even if root were compromised, the intruder would not be able to cover his or her tracks.  Obviously, a secure system would require more than just this, and would require a number of security checks for certain actions which alone could compromise a system.  Another example of what can be done with Medusa is a configuration that could allow all local processes access to /etc/passwd, but all network processes that try to access /etc/passwd can be redirected to /net/passwd.  Yet another feature of Medusa is the ability to grant access in a way impossible with vanilla Linux security: user-defined ACLs.  For example, user X could configure an ACL which would allow users Y and Z to renice X's "setiathome" process during the hours of 9:00 to 17:00, M-F.  File level ACLs are also possible with Medusa.  The advantage here is that Medusa ACLs are compatible across file systems, whereas most ACL mechanisms work by patching the file system code and therefore only work on one type of file system. Rudimentary tests show that it contributes little overhead, and Medusa can be configured to bypass itself if the constable daemon is not running.  This means that you can install Medusa and play with the constable configuration file, restarting the constable daemon, without worrying too much about locking up your system; if you feel like not using Medusa while you are testing it, simply don't run constable.  When you have your system configured the way you want it, and you are comfortable with your security model, you can replace the init daemon with an init wrapper supplied by Medusa which first runs constable and then runs the standard init daemon, thus ensuring that your security mechanism can't be bypassed with a simple reboot.

Summary


Medusa is easy to install, it is small, and it is powerful.  Medusa provides high granularity in the control over system security.  It also provides the mechanism by which the greatest security hole that Linux inherited from Unix can be solved: the root user.

Disclaimer


I have no association with the Medusa development group, aside from the
fact that I use their software.

Return To LinuxSecurity.com