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