> > > I was recently reading an article that claimed Linux is insecure, because > > of it's monolithic kernel codebase: > > > https://threatpost.com/researchers-blame-monolithic-linux-code-base-for-critical-vulnerabilities/136785/ > > I read the article. The big takeaways for me are:
1. "They found that 96 percent of critical Linux compromises would no longer be critical with a microkernel-based design, 40 percent would be completely eliminated by an OS based on a verified microkernel and 29 percent would be gone even with an unverified microkernel." 2. "security researchers noted that embracing microkernels as a panacea doesn’t take into account other challenges.' “The usage of limited function OS and/or distributed component OS is fine, but this introduces new risks and expands the attack surface that complicates security monitoring and association of various moving parts that become unmanageable for humans,” Joseph Kucic, chief security officer at Cavirin, told Threatpost. “While artificial intelligence/machine learning can aid in this security validation process, I expect hackers will have the advantage for 12 to 24 months if the paradigm is changed for OSes. 3. "He also pointed out that new hacks are focusing on runtime and memory exploits – and that these will see limited benefit from the proposed changes." 4. "While one may reduce attack surface of a monolithic OS, one increases complexity and security validation requirements for additional micro-services.” From which I draw the following conclusions. 1. Microkernel architecture by design is more secure than monolithic OSs such as MS WIn, Linux, MAC OS. 2. Microkernel architecture has flaws, challenges and isn't more secure against all attack vectors such as runtine and memory exploits. This comes down to the classic the "the evil you know is better than the evil you don't". The best thing about Linux is that it's not a one size fits all OS. If security is of paramount concern for a user or user base there is a plethora of ways to reduce the attach surface of the computing environment and/or data. As someone mentioned computers are about getting work done. This is what most developers and users have been thinking about and doing since the first computer. IT security is still a relatively new thing on the computer time line and in most cases it's still an afterthought. Microkernel architecture wasn't created to be secure. " Microkernels were meant as a response to changes in the computer world, and to several challenges adapting existing "mono-kernels <https://en.wikipedia.org/wiki/Mono-kernel>" to these new systems. New device drivers, protocol stacks, file systems and other low-level systems were being developed all the time. This code was normally located in the monolithic kernel, and thus required considerable work and careful code management to work on. Microkernels were developed with the idea that all of these services would be implemented as user-space programs, like any other, allowing them to be worked on monolithically and started and stopped like any other program. This would not only allow these services to be more easily worked on, but also separated the kernel code to allow it to be finely tuned without worrying about unintended side effects. Moreover, it would allow entirely new operating systems to be "built up" on a common core, aiding OS research." It just so happens that overtime those ideas lead to a more secure OS design. And now, 3rd generation microkernels are "characterised by a security-oriented API with resource access controlled by capabilities <https://en.wikipedia.org/wiki/Capability-based_security>, virtualization <https://en.wikipedia.org/wiki/Virtual_machines#System_virtual_machines> as a first-class concern, novel approaches to kernel resource management,[32] <https://en.wikipedia.org/wiki/Microkernel#cite_note-Elkaduwe_DE_08-32> and a design goal of suitability for formal analysis <https://en.wikipedia.org/wiki/Formal_methods>, besides the usual goal of high performance. Examples are Coyotos <https://en.wikipedia.org/w/index.php?title=Coyotos&action=edit&redlink=1>, seL4 <https://en.wikipedia.org/wiki/L4_microkernel_family#High_assurance:_seL4>, Nova,[33] <https://en.wikipedia.org/wiki/Microkernel#cite_note-TUD-33>[34] <https://en.wikipedia.org/wiki/Microkernel#cite_note-Steinberg_Kauer_EuroSys_2010-34> Redox <https://en.wikipedia.org/wiki/Redox_(operating_system)>and Fiasco.OC.[33] <https://en.wikipedia.org/wiki/Microkernel#cite_note-TUD-33> [35] <https://en.wikipedia.org/wiki/Microkernel#cite_note-Lackor_Warg_IIES_09-35> In the case of seL4, complete formal verification of the implementation has been achieved,[31] <https://en.wikipedia.org/wiki/Microkernel#cite_note-Klein_EHACDEEKNSTW_09-31> i.e. a mathematical proof that the kernel's implementation is consistent with its formal specification. This provides a guarantee that the properties proved about the API actually hold for the real kernel, a degree of assurance which goes beyond even CC EAL7. It was followed by proofs of security-enforcement properties of the API, and a proof demonstrating that the executable binary code is a correct translation of the C implementation, taking the compiler out of the TCB. Taken together, these proofs establish an end-to-end proof of security properties of the kernel. [36] <https://en.wikipedia.org/wiki/Microkernel#cite_note-Klein_AEMSKH_14-36>" The last part on formal analysis and mathematical proofs is new to me. _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
