# Capability-based security > Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Capability-based_security > Markdown URL: https://mediated.wiki/source/Capability-based_security.md > Source: https://en.wikipedia.org/wiki/Capability-based_security > Source revision: 1342003344 > License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/) Computer safety concept **Capability-based security** is a concept in the design of [secure computing](/source/Computer_security) systems, one of the existing [security models](/source/Computer_security_model). A **capability** (known in some systems as a **key**) is a communicable, unforgeable [token](/source/Access_token) of authority. It refers to a value that [references](/source/Reference_(computer_science)) an [object](/source/Object_(computer_science)) along with an associated set of [access rights](/source/Access_control). A [user](/source/User_(computing)) [program](/source/Computer_program) on a [capability-based operating system](/source/Capability-based_operating_system) must use a capability to access an object. Capability-based security refers to the principle of designing user programs such that they directly share capabilities with each other according to the [principle of least privilege](/source/Principle_of_least_privilege), and to the operating system infrastructure necessary to make such transactions efficient and secure. Capability-based security is to be contrasted with an approach that uses [traditional UNIX permissions](/source/File-system_permissions) and [access control lists](/source/Access-control_list). Although most operating systems implement a facility which resembles capabilities, they typically do not provide enough support to allow for the exchange of capabilities among possibly mutually untrusting entities to be the primary means of granting and distributing access rights throughout the system. A capability-based system, in contrast, is designed with that goal in mind. ## Introduction Capabilities achieve their objective of improving system security by being used in place of forgeable [references](/source/Reference_(computer_science)). A forgeable reference (for example, a [path name](/source/Path_(computing))) identifies an object, but does not specify which access rights are appropriate for that object and the user program which holds that reference. Consequently, any attempt to access the referenced object must be validated by the operating system, based on the [ambient authority](/source/Ambient_authority) of the requesting program, typically via the use of an [access-control list](/source/Access-control_list) (ACL). Instead, in a system with capabilities, the mere fact that a user program possesses that capability entitles it to use the referenced object in accordance with the rights that are specified by that capability. In theory, a system with capabilities removes the need for any access control list or similar mechanism by giving all entities all and only the capabilities they will actually need. A capability is typically implemented as a [privileged](/source/Privilege_(computing)) [data structure](/source/Data_structure) that consists of a section that specifies access rights, and a section that uniquely identifies the object to be accessed. The user does not access the data structure or object directly, but instead via a [handle](/source/Handle_(computing)). In practice, it is used much like a [file descriptor](/source/File_descriptor) in a traditional operating system (a traditional handle), but to access every object on the system. Capabilities are typically stored by the operating system in a list, with some mechanism in place to prevent the program from directly modifying the contents of the capability (so as to forge access rights or change the object it points to). Some systems have also been based on [capability-based addressing](/source/Capability-based_addressing) (hardware support for capabilities), such as [Plessey System 250](/source/Plessey_System_250). Programs possessing capabilities can perform functions on them, such as passing them on to other programs, converting them to a less-privileged version, or deleting them. The operating system must ensure that only specific operations can occur to the capabilities in the system, in order to maintain the integrity of the security policy. Capabilities as discussed in this article should not be confused with Portable Operating System Interface ([POSIX](/source/POSIX)) 1e/2c "[Capabilities](#POSIX_capabilities)". The latter are coarse-grained privileges that cannot be transferred between processes. ## Examples A capability is defined to be a protected [object](/source/Object_(computer_science)) reference which, by virtue of its possession by a user process, grants that process the capability (hence the name) to interact with an object in certain ways. Those ways might include reading data associated with an object, modifying the object, executing the data in the object as a process, and other conceivable access rights. The capability logically consists of a reference that uniquely identifies a particular object and a set of one or more of these rights. Suppose that, in a user process's memory space, there exists the following string: /etc/passwd Although this identifies a unique object on the system, it does not specify access rights and hence is not a capability. Suppose there is instead the following pair of values: /etc/passwd O_RDWR This pair identifies an object along with a set of access rights. The pair, however, is still not a capability because the user process's *possession* of these values says nothing about whether that access would actually be legitimate. Now suppose that the user program successfully executes the following statement: int fd = open("/etc/passwd", O_RDWR); The variable fd now contains the index of a file descriptor in the process's file descriptor table. This file descriptor *is* a capability. Its existence in the process's file descriptor table is sufficient to show that the process does indeed have legitimate access to the object. A key feature of this arrangement is that the file descriptor table is in [kernel memory](/source/Kernel_(operating_system)) and cannot be directly manipulated by the user program. ## Sharing between processes In traditional operating systems, programs often communicate with each other and with storage using references like those in the first two examples. Path names are often passed as command-line parameters, sent via sockets, and stored on disk. These references are not capabilities, and must be validated before they can be used. In these systems, a central question is "on whose *authority* is a given reference to be evaluated?" This becomes a critical issue especially for processes which must act on behalf of two different authority-bearing entities. They become susceptible to a programming error known as the [confused deputy problem](/source/Confused_deputy_problem), very frequently resulting in a [security hole](/source/Security_hole). In a capability-based system, the capabilities themselves are passed between processes and storage using a mechanism that is known by the operating system to maintain the integrity of those capabilities. One novel approach to solving this problem involves the use of an [orthogonally persistent](/source/Orthogonal_persistence) operating system. In such a system, there is no need for entities to be discarded and their capabilities be invalidated, and hence require an ACL-like mechanism to restore those capabilities at a later time. The operating system maintains the integrity and security of the capabilities contained within all storage, both volatile and nonvolatile, at all times; in part by performing all [serialization](/source/Serialization) tasks by itself, rather than requiring user programs to do so, as is the case in most operating systems. Because user programs are relieved of this responsibility, there is no need to trust them to reproduce only legal capabilities, nor to validate requests for access using an [access control](/source/Access_control) mechanism. An example implementation is the [Flex machine](/source/Flex_machine) from the early 1980s. ## POSIX capabilities Portable Operating System Interface (POSIX) draft 1003.1e specifies a concept of permissions called "capabilities". However, POSIX capabilities differ from capabilities in this article. A POSIX capability is not associated with any object; a process having CAP_NET_BIND_SERVICE capability can listen on any TCP port under 1024. This system is found in Linux.[1] In contrast, [Capsicum](/source/Capsicum_(Unix)) Unix hybridizes a true capability-system model with a Unix design and POSIX API. Capsicum capabilities are a refined form of file descriptor, a delegable right between processes and additional object types beyond classic POSIX, such as processes, can be referenced via capabilities. In Capsicum capability mode, processes are unable to utilize global namespaces (such as the filesystem namespace) to look up objects, and must instead inherit or be delegated them. This system is found natively in FreeBSD, but patches are available to other systems.[2] ## Implementations Notable research and commercial systems employing capability-based security include the following: - [Tahoe-LAFS](/source/Tahoe-LAFS), an open-source capability-based filesystem - [FreeBSD](/source/FreeBSD) [Capsicum](/source/Capsicum_(Unix))[3][4] - [Genode](/source/Genode)[5] - [Fuchsia](/source/Fuchsia_(operating_system))[6] - [HarmonyOS](/source/HarmonyOS) ([OpenHarmony](/source/OpenHarmony)) [7][8][9] - [Phantom OS](/source/Phantom_OS)[10] - [RedoxOS](/source/RedoxOS) - [L4 microkernel family](/source/L4_microkernel_family): - OKL4 from Open Kernel Labs - [seL4](/source/SeL4) from NICTA - Fiasco.OC and NOVA from [TU Dresden](/source/TU_Dresden) - [WebAssembly](/source/WebAssembly) System Interface (WASI) ### Discontinued - [Amoeba](/source/Amoeba_(operating_system)) distributed operating system - [GNOSIS](/source/GNOSIS), an operating system developed at [Tymshare](/source/Tymshare) - [KeyKOS](/source/KeyKOS), successor to GNOSIS - EROS, The [Extremely Reliable Operating System](/source/Extremely_Reliable_Operating_System), successor to KeyKOS - [Cambridge CAP computer](/source/Cambridge_CAP_computer) - [Hydra (operating system)](/source/Hydra_(operating_system)), part of the [C.mmp](/source/C.mmp) project at [Carnegie Mellon University](/source/Carnegie_Mellon_University) - IBM [System/38](/source/System%2F38) and [AS/400](/source/AS%2F400) - [Intel iAPX 432](/source/Intel_iAPX_432) - [Plessey System 250](/source/Plessey_System_250) - [Flex](/source/Flex_machine) ## See also - [Privilege separation](/source/Privilege_separation) - [Role-based access control](/source/Role-based_access_control) ## References 1. **[^](#cite_ref-1)** [capabilities(7)](https://man7.org/linux/man-pages/man7/capabilities.7.html) – [Linux](/source/Linux) Programmer's [Manual](/source/Man_page) – Overview, Conventions and Miscellanea 1. **[^](#cite_ref-2)** [capsicum(4)](https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4) – [FreeBSD](/source/FreeBSD) Kernel Interfaces [Manual](/source/Man_page) 1. **[^](#cite_ref-3)** ["Capsicum(4)"](https://www.freebsd.org/cgi/man.cgi?capsicum(4)). 1. **[^](#cite_ref-4)** [Capsicum: practical capabilities for UNIX](https://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf). Retrieved 9 July 2024 1. **[^](#cite_ref-5)** ["Genode OS: a breath of fresh air in operating system and software security"](https://rudd-o.com/linux-and-free-software/genode-os-a-breath-of-fresh-air-in-operating-system-and-software-security). *Rudd-O.com*. Retrieved 2023-12-21. 1. **[^](#cite_ref-6)** ["Google's Fuchsia operating system runs on virtually anything"](https://www.engadget.com/2016-08-13-google-fuchsia-operating-system.html). *Engadget*. 2016-08-14. Retrieved 2023-12-21. 1. **[^](#cite_ref-7)** Děcký, Martin. ["Microkernel-based and Capability-based Operating Systems"](https://d3s.mff.cuni.cz/files/teaching/nswi161/martin-decky-microkernels-capabilities.pdf) (PDF). *D3S*. Retrieved 23 December 2023. 1. **[^](#cite_ref-8)** ["docs/en/application-dev/security/accesstoken-overview.md at master · openharmony/docs"](https://github.com/openharmony/docs/blob/master/en/application-dev/security/accesstoken-overview.md). *GitHub*. Retrieved 2024-05-04. 1. **[^](#cite_ref-9)** DARKNAVY (2024-06-11). ["AVSS Report: System Security Adversarial Capability Preliminary Evaluation of iOS, Android, and HarmonyOS - Kernel"](https://www.darknavy.org/blog/avss_report_kernel/). *DARKNAVY*. Retrieved 2024-07-04. 1. **[^](#cite_ref-10)** Dziuba, Ted. ["Russian rides Phantom to OS immortality"](https://www.theregister.com/2009/02/03/phantom_russian_os/). *The Register*. Retrieved 31 December 2023. - Levy, Henry M., **[Capability-Based Computer Systems](http://portal.acm.org/citation.cfm?id=538134&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618)*, Digital Equipment Corporation 1984. [ISBN](/source/ISBN_(identifier)) [0-932376-22-3](https://en.wikipedia.org/wiki/Special:BookSources/0-932376-22-3). An electronic version is available [here](http://www.cs.washington.edu/homes/levy/capabook/). - [The EROS Project](https://web.archive.org/web/20031029002231/http://www.eros-os.org/) - [E](/source/E_programming_language), a programming language based around capability security ([ERights.org](http://www.erights.org/)) - Mark S. Miller, Ka-Ping Yee, Jonathan Shapiro. *Capability Myths Demolished*, Technical Report SRL2003-02, Systems Research Laboratory, Johns Hopkins University. [Available online.](https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf) - [The Cambridge CAP Computer](https://www.cs.washington.edu/homes/levy/capabook/Chapter5.pdf), Levy, 1988 ## Further reading - [Capability-based addressing](/source/Capability-based_addressing): Theodore A. Linden (December 1976). "Operating System Structures to Support Security and Reliable Software". *[ACM Computing Surveys](/source/ACM_Computing_Surveys)*. **8** (4): 409–445. [doi](/source/Doi_(identifier)):[10.1145/356678.356682](https://doi.org/10.1145%2F356678.356682). [hdl](/source/Hdl_(identifier)):[2027/mdp.39015086560037](https://hdl.handle.net/2027%2Fmdp.39015086560037). [ISSN](/source/ISSN_(identifier)) [0360-0300](https://search.worldcat.org/issn/0360-0300). [S2CID](/source/S2CID_(identifier)) [16720589](https://api.semanticscholar.org/CorpusID:16720589). - [Li Gong](/source/Li_Gong_(computer_scientist)), *[A Secure Identity-Based Capability System](https://doi.ieeecomputersociety.org/10.1109/SECPRI.1989.36277)*, sp, p. 56, 1989 IEEE Symposium on Security and Privacy, 1989 - [Capability-based addressing](http://portal.acm.org/citation.cfm?id=361070&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618) - [A hardware implementation of capability-based addressing](http://portal.acm.org/citation.cfm?id=850709&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618) - [An implementation of capabilities on the PDP-11/45](http://portal.acm.org/citation.cfm?id=850701&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618) - [IBM System/38 support for capability-based addressing](http://portal.acm.org/citation.cfm?id=801885&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618) - [EROS: a fast capability system](http://portal.acm.org/citation.cfm?id=319163&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618) POSIX "capabilities" in Linux: - [POSIX Capabilities & Files](http://www.friedhoff.org/posixfilecaps.html) - [POSIX file capabilities: Parceling the power of root](https://www.ibm.com/developerworks/library/l-posixcap/) - [Making Root Unprivileged](https://www.linuxjournal.com/magazine/making-root-unprivileged) - [Security issues and new risks linked to POSIX file capabilities](https://www.sevagas.com/?POSIX-file-capabilities-the-dark) - [Linux manual page for "capabilities(7)"](https://man7.org/linux/man-pages/man7/capabilities.7.html) - [Working with Linux capabilities](https://www.vultr.com/docs/working-with-linux-capabilities) ## External links - ["What is a Capability?"](https://archive.today/20130112225523/http://www.eros-os.org/essays/capintro.html) - [Reviews of 'Capability Myths Demolished'](https://archive.today/20130414162939/http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html) - [Capability Theory by Sound Bytes](http://www.cap-lore.com/CapTheory/index.html) v t e Object-capability security Concepts Principle of least privilege (PoLP) Confused deputy problem Ambient authority File descriptor C-list Object-capability model Capability-based security Capability-based addressing Zooko's triangle Petnames Operating systems, kernels Capsicum Fuchsia Genode GNOSIS → KeyKOS → EROS → CapROS Hydra iMAX 432 Midori NLTSS seL4 HarmonyOS (HarmonyOS NEXT) Phantom OS Programming languages Caja–Cajita E Joe-E Joule File systems Tahoe-LAFS Specialised hardware BiiN Cambridge CAP CHERI Flex IBM System/38 Intel iAPX 432 Plessey System 250 --- Adapted from the Wikipedia article [Capability-based security](https://en.wikipedia.org/wiki/Capability-based_security) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Capability-based_security?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.