Operating system: Difference between revisions

Revision as of 01:06, 6 November 2024

Revision as of 01:39, 18 November 2024

Line 504:

Some operating system designs are more secure than others. Those with no isolation between the kernel and applications are least secure, while those with a [[monolithic kernel]] like most general-purpose operating systems are still vulnerable if any part of the kernel is compromised. A more secure design features [[microkernel]]s that separate the kernel's privileges into many separate security domains and reduce the consequences of a single kernel breach.{{sfn|Tanenbaum|Bos|2023|p=612}} [[Unikernel]]s are another approach that improves security by minimizing the kernel and separating out other operating systems functionality by application.{{sfn|Tanenbaum|Bos|2023|p=612}}

Most operating systems are written in [[C (programming language)|C]] or [[C++]], which create potential vulnerabilities for exploitation. Despite attempts to protect against them, vulnerabilities are caused by [[buffer overflow]] attacks, which are enabled by the lack of [[bounds checking]].{{sfn|Tanenbaum|Bos|2023|pp=648, 657}} <!-- Other types of vulnerability in operating systems written in C and C++ include [[format string attack]]s, which exploit lack of [[type checking]] to [[code injection|inject malicious code]],{{sfn|Tanenbaum|Bos|2023|pp=658, 661}} [[use-after-free attack]]s that rely on [[C dynamic memory allocation|dynamically allocated memory]],{{sfn|Tanenbaum|Bos|2023|p=661}} and [[null pointer dereference attack]]s that an attacker can exploit to crash a computer.{{sfn|Tanenbaum|Bos|2023|p=664}} --> Hardware vulnerabilities, some of them [[TransientSpeculative execution CPU vulnerabilityvulnerabilities|caused by CPU optimizations]], can also be used to compromise the operating system.{{sfn|Tanenbaum|Bos|2023|pp=668–669, 674}} There are known instances of operating system programmers deliberately implanting vulnerabilities, such as [[Backdoor (computing)|back door]]s.{{sfn|Tanenbaum|Bos|2023|pp=679–680}}

Operating systems security is hampered by their increasing complexity and the resulting inevitability of bugs.{{sfn|Tanenbaum|Bos|2023|pp=605, 617–618}} Because [[formal verification]] of operating systems may not be feasible, developers use operating system [[Hardening (computing)|hardening]] to reduce vulnerabilities,{{sfn|Tanenbaum|Bos|2023|pp=681–682}} e.g. [[address space layout randomization]], [[control-flow integrity]],{{sfn|Tanenbaum|Bos|2023|p=683}} [[Access-control list|access restriction]]s,{{sfn|Tanenbaum|Bos|2023|p=685}} and other techniques.{{sfn|Tanenbaum|Bos|2023|p=689}} There are no restrictions on who can contribute code to open source operating systems; such operating systems have transparent change histories and distributed governance structures.{{sfn|Richet|Bouaynaya|2023|p=92}} Open source developers strive to work collaboratively to find and eliminate security vulnerabilities, using [[code review]] and [[type checking]] to expunge malicious code.{{sfn|Richet|Bouaynaya|2023|pp=92–93}}{{sfn|Berntsso|Strandén|Warg|2017|pp=130–131}} [[Andrew S. Tanenbaum]] advises releasing the [[source code]] of all operating systems, arguing that it prevents developers from placing trust in secrecy and thus relying on the unreliable practice of [[security by obscurity]].{{sfn|Tanenbaum|Bos|2023|p=611}}