Protection matrixes in Minix
From Erights
This page documents some of the concrete examples of the protection matrix concept. In this case, from the Minix world. We first describe lightly describe the structure of the Minix operating system and then we list various different protection matrixes that define certain security policies.
Contents |
Minix structure
Minix3 operating system provides classical UNIX-like environment. It provides usual UNIX system calls (fork, exec, exit, kill, open, read, write, etc.) From this point of view, we would have no reason it to prefer it over, say, Linux or FreeBSD.
The goal of the Minix project is to improve the internal quality of the operating system implementation. Why and how is it done is described in the Minix book.
The following figure captures the structure of the Minix operating system:
Processes in Layer 1 run in the kernel space. Processes in Layers 2, 3 and 4 run in the user space. Ordinary user space processes run in Layer 4. Processes that together actually implement the UNIX-like services run in Layers 1, 2 and 3.
Layer 1 contains:
- the KERNEL task (it implements the scheduler, it provides the inter-process communications primitives used by other processes, it is hooked to IRQs, it enforces security policies defined by protection matrices described below, etc)
- the SYSTEM task provides various services to user space processes from layers 2 and 3 that must be performed in the kernel space (I/O operations and such). In Minix terminology, they are called "kernel calls".
- the CLOCK task is actually a device driver of the PIT (Programmable Interface Timer chip) that would be hard to move to user space so it runs in the kernel space.
In Minix terminology, processes running in Layer 1 are called tasks.
Layer 2 contains various processes that behave as device drivers (DRV).
Layer 3 contains various higher level subsystems:
- The process manager (PM) implements most of the UNIX services that are related to processes.
- The file system (FS) implements most of the UNIX services that are related to files.
- The reincarnation server (RS) periodically checks whether particular device drivers run. It restarts those that crashed (e.g. due to a segmentation fault).
- The data server (DS) can be used by device drivers to store their internal state so that restart of the device driver does not disrupt the on-going services provided by this driver.
- etc.
Ordinary processes run in Layer 4.
The following section describe various examples of protection matrixes present internally within Minix. Each of them is enforced by the KERNEL task. Subjects can try to perform any operation on any objects, but the KERNEL task subsequently checks whether a given subject has permission to perform a chosen operation. Minix is thus an ambient authority system.
Protection matrix that defines which processes can use which IPC mechanisms
The KERNEL task provides five different IPC primitives:
- send
- receive
- sendrec
- notify
- echo
The following protection matrix defines which processes (grouped by layer) can use which particular IPC primitives.
The table is defined by lines 06053--06058 in the Minix source code.
Protection matrix that defines which processes can talk to which other processes
The operating system is composed from multiple processes:
- SYSTEM (the system task)
- PM (the process manager)
- FS (the file system)
- RS (the reincarnation server)
- MEM (the memory driver)
- LOG (the logging driver)
- TTY (the terminal driver)
- DS (the data server)
- INIT (the init process)
- CLOCK (the clock driver)
The following matrix defines allwed interaction (via IPC primitives) among them.
The table is defined by 06060--06071 in the Minix source code.
Protection matrix that defines which processes can use which "kernel calls"
Even though most of the Minix operating system is implemented by a set of user-space processes, there are actions that cannot be done by user space processes. They were refactored to SYSTEM task which runs in the kernel space and, when these services are invoked, it performs them on behalf of the invoker. The SYSTEM task supports the following services:
- sys_fork
- sys_exec
- sys_exit
- sys_nice
- ...
The protection matrix defines which services of the SYSTEM task can be invoked by which processes.
The table is defined by 06073--06086 in the Minix source code.
Known problems
The Minix version 3.1.1 distributed with the book has some known problems. They were reported and addressed in the subsequent Minix version.
A trivial denial of service (DoS) attack
Any device driver can cause deadlock (denial of service) of the whole operating system. Let us consider the following trivial device driver code:
#include "../drivers.h"
void main(void)
{
message mess;
while (TRUE)
receive(ANY, &mess);
}
If we compile it and register it as a new device driver then the system will work until someone tries to invoke services of that device driver---e.g. by opening appropriate special file. If we try to do that, the file system server (FS) will remain in a deadlock forever and subsequently all user space processes that will request some operation from the file system server will block forever too.
Newer version of Minix will have to offer slightly different IPC primitives that enable file system server (FS) to guard itself from such malbehaving device drivers and continue providing expected services.
Device drivers in Minix have the authority to overwrite any part of the memory
Moving as much services of the operating system to a user space is a step forward. However, what we should ultimately seek is the ability to follow the principle of least authority. We should try to infer authority from permissions of particular subjects. This should be done at design time as well as during security audit.
If we inspect protection matrixes we reveal that:
- all device drivers are allowed to use the sendrec IPC primitive
- all device drivers are allowed to talk to the SYSTEM task
- all device drivers are allowed to invoke the sys_physcopy service of the SYSTEM task
These are permissions. Translated to human speach---all device drivers have the authority to overwrite any byte in the physical memory.
This is one of many instances of the confused deputy probem. It is impossible to solve the problem by some trivial extension of the protection matrices described above. The problem will be elegantly solved by memory-capabilities ("memory grants" in Minix terminology). Processes can create capabilities to regions of their own address space and pass these capabilities to other processes which will be able to read or write to given memory region.
