Linux Study Argues Monolithic OS Design Leads To Critical Exploits (osnews.com)
Long-time Slashdot reader Mike Bouma shares a paper (via OS News) making the case for "a small microkernel as the core of the trusted computing base, with OS services separated into mutually-protected components (servers) -- in contrast to 'monolithic' designs such as Linux, Windows or MacOS."
While intuitive, the benefits of the small trusted computing base have not been quantified to date. We address this by a study of critical Linux CVEs [PDF] where we examine whether they would be prevented or mitigated by a microkernel-based design. We find that almost all exploits are at least mitigated to less than critical severity, and 40% completely eliminated by an OS design based on a verified microkernel, such as seL4....
Our results provide very strong evidence that operating system structure has a strong effect on security. 96% of critical Linux exploits would not reach critical severity in a microkernel-based system, 57% would be reduced to low severity, the majority of which would be eliminated altogether if the system was based on a verified microkernel. Even without verification, a microkernel-based design alone would completely prevent 29% of exploits...
The conclusion is inevitable: From the security point of view, the monolithic OS design is flawed and a root cause of the majority of compromises. It is time for the world to move to an OS structure appropriate for 21st century security requirements.
Our results provide very strong evidence that operating system structure has a strong effect on security. 96% of critical Linux exploits would not reach critical severity in a microkernel-based system, 57% would be reduced to low severity, the majority of which would be eliminated altogether if the system was based on a verified microkernel. Even without verification, a microkernel-based design alone would completely prevent 29% of exploits...
The conclusion is inevitable: From the security point of view, the monolithic OS design is flawed and a root cause of the majority of compromises. It is time for the world to move to an OS structure appropriate for 21st century security requirements.
Maybe Tanenbaum was right. 26 years isn't that long for this debate to come back around again.
...si hoc legere nimium eruditionis habes...
Consider QNX and its vulnerabilities (the entire software stack) and here's what we have for the Linux kernel (again, kernel alone) whose source is ostensibly verified by millions of eyes.
And here's another almost shameful development: Linux and Open Source are all the rage amongst Open Source fans, yet for some reasons it's been hinted that Google is transitioning from the monolithic Linux kernel (lacking internal stable API/ABI) to its own microkernel, Fuchsia (with stable API/ABI).
After 28 years, you think someone would have finished the GNU Hurd kernel. By now, it is so old it is probably full of potential exploits, too.
These days, the largest security threat is probably web browsers: They usually have direct access to the most critical information a user has (passwords, all personal files under their user account, data from all the external services the user accesses, etc.) Under the very same OS user account, web browsers also download and run thousands of untrusted programs from random locations on the internet every day (we'll ignore the handful of hardcore geeks who run Noscript).
The boundary separating these two realms is enormous and incredibly convoluted, involves many layers of abstraction (some of which can be breached by a single misplaced bracket or quote character), and is enforced entirely by the web browser itself. It presents a massive attack surface that dwarfs even the most monolithic OS API.
NTOSKRNL runs its filesystems, object manager, executive, etc. in kernel space. In what way was this ever a microkernel design by any commonly accepted definition of the term?
Security isn't just confidentiality. It's Confidentiality, Integrity, and Availably (CIA). If the machine isn't running, it isn't provide secure services to the users.
The micro-kernel architecture ala Tanenbaum fails the security requirement of Availability; micro-kernel systems don't provide what people need. People use Linux because the design works well for building what people need.
Congratulations on finding one oddball application for which someone decided to use a micro-kernel. Specifically where it's not a general-purpose computer, performance doesn't matter, and there's no need to run more than one application at a time.
The next time I'm trying to build a slow as hell access KVM on specially designed hardware, I'll consider a micro-kernel. Only, of course, if I can't use a GPL kernel because I'm trying to keep everything secret.