Andrew S. Tanenbaum, a computer science professor at the Vrije Universiteit in Amsterdam, is leading the project developing MINIX 3, an operating system meant to be more secure than Windows or Linux.
In his research proposal, which secured him 2.5 M Euros from the European Research Council for the next 5 years, Tanenbaum explains why he considers current operating systems are not secure:
The most serious reliability and security problems are those relating to the operating system. The core problem is that no current system obeys the POLA: the Principle Of Least Authority. The POLA states that a system should be partitioned into components in such a way that an inevitable bug in one component cannot propagate into another component and do damage there. Each component should be given only the authority it needs to do its own job and no more. In particular, it should not be able to read or write data belonging to another component, read any part of the computer’s memory other than its own address space, execute sensitive instructions it has no business executing, touch I/O devices it should not touch, and so on. Current operating systems violate this principle completely, resulting in the reliability and security problems mentioned above.
Device drivers are the main culprit according to Tanenbaum:
About 70% of a typical operating system consists of device drivers, and these are known to have 3-7 times as many bugs per line of code as the rest of the system. It is also well documented that 63% to 85% of Windows XP crashes are due to driver failures and there is no reason to expect that Linux is any different.
MINIX comes with a slightly different approach to OS architecture:
The main difference pointed by Tanenbaum is having the drivers run in user mode conferring higher security:
Above the kernel, running in user mode, are the device drivers, each one running as a separate process tightly restricted by the memory management hardware to accessing only its own memory. Device drivers need to do I/O and they do this by making calls to the microkernel to obtain services (such as issuing commands to a physical device). However, before executing any call, the microkernel first checks to make sure the call is permitted. Thus a call from the audio driver to command the sound card will be accepted and processed but a call from the audio driver to command the disk will be rejected.
The overall goal is to:
… reorganize the operating system as a tiny microkernel that runs in kernel mode, along with some number of user processes that do the real work of the operating system. While a microkernel is by no means a complete operating system, this design achieves a major goal. The goal is getting most of the operating system code into user space where it can be partitioned into processes unable to execute “dangerous” (i.e., control) instructions and prohibited from accessing memory outside itself by the memory management hardware.
Currently, MINIX 3 is at version 3.1.3a and its main features are:
- POSIX compliant
- Networking with TCP/IP
- X Window System
- Languages: cc, gcc, g++, perl, python, etc.
- Over 650 UNIX programs
- Full multiuser and multiprogramming
- Device drivers run as user processes
- High degree of fault tolerance
- Full C source code supplied
Since MINIX is implementing the POSIX standard, it can run most UNIX programs with little or no changes. The project was included in Google’s Summer of Code 2008. A MINIX Discussions Group is set up on Google.
Community comments
How is the performance
by Senaka Suriyaarachchi,
The data is more valuable than the OS or the hardware.
by Jeff Brown,
Linux kernel is bloated
by Dmitry Tsygankov,
How is the performance
by Senaka Suriyaarachchi,
Your message is awaiting moderation. Thank you for participating in the discussion.
What will be the performance comparing Linux or Windows? Do we need to compromise performance because of loosely coupled components in OS.
BR
Senaka
The data is more valuable than the OS or the hardware.
by Jeff Brown,
Your message is awaiting moderation. Thank you for participating in the discussion.
It annoys me that we still speak of OS reliability / security in terms of componentization. This is an old mindset from the era when computers were expensive and had to be shared (safely) by many users. There is more to be done besides that.
Microkernel services and user-mode drivers are means of encapsulation and isolation used by a kernel to mediate interactions among subsystems and to protect them from one another in the event of a localized fault. Nevertheless, the kernel and its subsystems operate within a realm of mutual partial trust and must grant each other priviledged access via capabilities, access control lists and other mechanisms. The isolation is useful but in the end, a malicious or buggy subsystem is usually still able to cause significant real harm to the system as a whole.
An extreme example: A graphics card driver could overclock the GPU or stop the fan and let out the magic blue smoke. Who cares whether the driver itself was running in user mode?
On we go segmenting I/O port ranges, DMA regions, memory, disk and other resources trying to keep one piece of code from clobbering another directly. For the hard stuff, we define safer interfaces or use virtualization to emulate a sandbox.
It works: fatal crashes are less frequent, the system can restore itself from common malfunctions, and as a whole we are better off. Well done!
By now we have achieved adequate reliability. Minor improvements can yet be made by improving the completeness of the encapsulation through ever more elaborate technical means but these are the low-hanging fruits only. The more valuable fruit is to be found higher up the tree: securing the user's data.
I'm not talking about protecting users from themselves (although that's worthwhile to a point). I'm talking about protecting them from millions of buggy, awkward, inconsistent, inscrutable, misunderstood or misused applications that act with a user's (non-administrative) credentials, never alter a single OS protected file, never twiddle an I/O bit, never execute a single priviledged instruction and yet achieve disastrous effects: destroying valuable user state.
It doesn't take much: drag a file to the wrong place and lose track of where it went, run an installer that contains a careless rm -rf and wonder where all your documents went, synchronize your data and find it has been partially overwritten with an older edition, catch one little virus and suddenly all of your secrets are in the open.
Not every app should be able to access every user file, setting or secret. The system as a whole should act to preserve the integrity of the document hive and ensure high availability of its contents. The current byzantine tangle of application and OS-enforced access policies is a patently unworkable mess! We can do better than this but we need better coordination from the bottom up.
The data is more valuable than the OS or the hardware. Protecting it is a hard problem. What clever solutions can we devise? What false assumptions can we discard? How can the OS help?
Linux kernel is bloated
by Dmitry Tsygankov,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well, of course, it is less bloated than Windows. But I'm still not quite happy with the way things are. I'm currently using Gentoo Linux on one of my machines, and I'm more or less happy with it since I'm able to do almost everything with its Portage package manager... But I can't do anything with the kernel. The recommended 'true Gentoo' way of doing things is to run 'make menuconfig' after every kernel update and peer at all of those checkboxes, then save the configuration and recompile the whole kernel. I just don't have the time for those things and there are sooo many checkboxes in kernel configuration utility... It might probably be a better idea to move more device drivers out of the kernel and install & update them with the same package manager. That seems to be the approach Minix is following, so maybe I'll try it sometime soon...