Medusa features GENERAL The kernel part of Medusa communicates with the security daemon via a character device with major number 111 and minor number 0. This communication is based on exchanging packets which are defined in the Medusa communication protocol. During startup, the security daemon should send its supported version of communication protocol to the kernel. If the version equals the version supported by the kernel, communication is possible. If not, the security daemon should exit. The security daemon can reset the communication interface at any time, which causes invalidation of any data cached by the kernel (inode info, etc.) and the reset of packet exchange statistics. There is a character device with major number 111 and minor number 1, which provides statistics of how many packets and bytes were exchanged. You can do some profiling using this. Use of character device implies that the security daemon has to wait for data being available for reading from the device. The kernel then normally wakes it up and calls the scheduler. When the security daemon writes its answer to the device, it sleeps again. For these reasons, it is recommended that the security daemon use a real time process scheduling policy, thus it will not have to wait for other normal average priority processes, but, rather, it will be scheduled immediately. When Medusa asks the security daemon for confirmation of some operation, it provides a fair amount of information about the current process and/or file. This information includes, for example: uid, gid, luid etc., virtual spaces information, and others. As an answer to a request, the communication protocol defines five possible values: ERR error - indicates security daemon does not know how to handle the request, so everything will proceed without change as if the entire Medusa package did not exist YES permit operation NO forbid operation SKIP forbid operation, but return success OK permit operation, but proceed with standard system permission check if any (so permission could be still denied by standard system security mechanisms) FILESYSTEM ACCESS CONTROL In the VFS, Medusa assigns a bitmap of virtual spaces to every file (inode). Currently, 32 virtual spaces are supported. These indicate where a given file belongs. Every file also has an assigned bitmap of operations that will need confirmation by Medusa plus some additional information for the security daemon. This provides a great speed-up, because access to files that are not marked for control of certain operations on them is equally as fast as under normal (no Medusa) conditions. The slowdown in the kernel, when requesting confirmation from the the security daemon is also very little, but overall performance depends on the performance of the security daemon. When a new VFS inode entry is to be created in the kernel, Medusa asks the security daemon to fill up necessary information about inode so the security daemon has complete control of this speed-up and everything depends on its configuration. Medusa asks the security daemon to confirm these file operations: access, create, delete, rename, link, execute. PROCESS ACTIONS CONTROL Medusa assigns some additional information to every process in the kernel. This information includes: a bitmap of virtual spaces to which the process belongs (other processes that can see these virtual spaces also see that the process exists), which the process can see (the process sees that processes or files in these virtual spaces exist and is able to interact with them), read from and write to, a bitmap of process and filesystem operations which need to be confirmed by Medusa (These are implemented for the same performance reasons as above) and login uid. Login uid can be set via system call only once (usually when logging in), so it effectively saves identification of user, who ran the process, independently of what privileges the process can use. Medusa asks the security daemon to confirm these process operations: fork, exec, send signal execute set uid program, set{re,s}uid, capability check, ptrace. AUTHORIZATION MODEL Wherever in the kernel, where Medusa is used for authorization, this is the standard order of events: 1. Virtual spaces check This phase checks whether the current process' virtual spaces related to the type of requested operation match at least one of the virtual spaces of the target object. (For example, when writing to a file, the "write" virtual spaces of the current process are checked against the virtual spaces to which the file belongs. If they match, then continue to phase 2, but if they do not, then deny the operation. 2. Confirmation status check Checks whether the requested type of operation is confirmed by Medusa. The result depends on the corresponding kernel records of the related objects, as explained above. If Medusa confirms the requested operation, then continue to phase 3, but if Medusa does not confirm the operation, then go on to phase 4. If the security daemon is not running, then phase 3 is always skipped. 3. Security daemon check The kernel sends a request describing the operation to the security daemon (as explained above) and waits for an answer. If the answer is YES, then continue at phase 5. If the answer is NO, then deny the operation. If the answer is SKIP, then continue to phase 6. The result of SKIP depends on the type of operation: Sometimes it is equal to OK (in case that operation cannot return proper data without really being executed). If the answer is OK, then continue at phase 4. If the answer is ERR, then continue at phase 4 (just like OK), but do not apply any changes to the kernel data structures, so everything will go as if there were no Medusa at all. 4. System permission check This is the usual kernel permission check based on standard Linux security model. Of course, this one executes only if present in the original code. 5. Execution of the operation 6. Return PLATFORM SPECIFIC OPTIONS On some architectures, you can use two other features. The first is syscall tracing. This means that every process has assigned a bitmap of syscalls, which are traced. When a process, with tracing of some syscall enabled, makes the syscall, Medusa asks the security daemon for confirmation. Medusa sends the usual information about the process plus all the parameters of the traced syscall to the security daemon. This way you can have unlimited control over everything that user space processes do. Another feature is arbitrary code forcing. The security daemon can force processes to execute arbitrary code through the kernel Medusa interface. This mechanism is similar to signal handling: Code is copied to the stack and executed. This allows the security daemon theoretically to perform any action as a response to behavior of the process. Unfortunately, these features require changes to architecture dependent parts of the Linux kernel, so only the i386 architecture is currently supported. DEFAULTS Medusa assigns default values to the kernel variables that describe (Medusa specific) security information about related objects. A description of these defaults follows: The initial process has all virtual spaces classes set to all (0xFFFFFFFF), it has control of fork and exec enabled, control of all filesystem actions disabled, user specific info is set to 0 and, if compiled in, tracing of all syscalls is disabled. All these values copy to new processes on fork. Every new VFS inode has virtual spaces set to all and has control of all filesystem actions disabled.