Capability-based security

from Wikipedia, the free encyclopedia
This article or section needs to be revised: WP: Wikify - Xneb 20 Disk • Posts 09:22, 28 Jun. 2017 (CEST)
Please help to improve it , then remove this mark.

Capability-based security ( German  rights -based security [-s guidelines] ) is a security concept from the field of computer administration.

An ability / right ( English capability ), which is also known in some systems as a key, is a communicable and unchangeable authentication token. This refers to a value that represents an object and a matching set of access rights. A computer program of the user that runs on a skills-based operating system must have corresponding skills / rights in order to be able to access objects.

Rights-based security refers to the principle that computer programs communicate with each other according to the principle of "minimum rights" ( principle of least privilege ) and accordingly assign capabilities / rights and that the operating system has the right infrastructure to work effectively and safely can. Skills-based security is in contrast to the ring / domain method ( hierarchical protection domains ).

Most operating systems implement tools that are similar to these capabilities. These often do not offer enough support to exchange skills / rights between the operating system unknown instances in order to be the primary authority for access rights. In contrast, a skills-based system is designed for this.

The skills / rights that this article deals with should not be confused with POSIX .

Rights and rights-based security

Rights improve system security by using them instead of changeable references . A changeable reference (e.g. a path name ) identifies an object, but does not indicate which access rights are available for this object and the user program that contains this reference. Therefore, every access to the referenced object must be validated by the operating system on the basis of the authorizations of the requesting program, which typically happens through the use of an access control list (ACL). On the contrary, in a system with rights, the pure possession of certain rights is sufficient to be able to access referenced objects. In theory, access control lists or similar technologies are not required in these systems, since all entities only have the capabilities they actually need.

A right / ability is typically implemented as a privileged data structure consisting of two parts, one specifying access rights and the other uniquely identifying the object to be assigned. The user does not access the data structure or the object directly, but via a handle . In practice, it is used much like a filehandle in a traditional operating system (a traditional handle), but to access any object on the system. The capabilities are typically stored in a list by the operating system, with some mechanism in place to prevent the program from directly changing the content of the capability. Some systems are also based on skill-oriented addressing (≈ hardware support for skills), such as the Plessey System 250.

Programs that have skills can perform functions on them, such as: B. pass them on to other programs, convert them to a less privileged version or delete them. The operating system must ensure that only certain operations for the capabilities can occur in the system in order to maintain the integrity of the security policy.

Introduction to rights-based security

An ability / right is defined as a protected object reference that, by virtue of its property, gives a process the permission / ability to interact with an object. This could be reading data associated with an object, changing the object, executing the data and other possible access rights. The ability therefore logically consists of a reference that uniquely identifies a certain object and has one or more of these rights.

Assume that the following string exists in the memory location of a program: 

/etc/passwd

Although this identifies a unique object on the system, it does not specify access rights and is therefore not a capability. For example, suppose there are two values ​​instead: 

/etc/passwd
O_RDWR

This identifies an object along with its access rights. However, there is still no ability because possession of these values does not say anything about whether this approach would actually be legitimate.

Let us now assume that the user program successfully executes the following instruction: 

int fd = open("/etc/passwd", O_RDWR);

The variable fd now contains the index of a filehandle in the filehandle table of the process. This filehandle is a capability. Its existence in the process filehandle table is sufficient to know that the process actually has legitimate access to the object. An essential feature of this arrangement is that the file handle table is located in the core memory and cannot be directly manipulated by the user program.

Exchange of skills between processes

In traditional operating systems, programs often communicate with each other, often passing path names as command line parameters or sending them over sockets. These references are not skills and must be validated before they can be used. In these systems, the central question is, "On whose authority a given reference is to be judged?" This becomes a critical issue for processes that are run by two different entities with different rights. This can lead to frequent programming error that as Confused deputy trouble ( German  confused deputy problem ) is known and can lead to security vulnerabilities.

In a skills-based system, skills are passed between processes and storage through a mechanism known by the operating system to maintain the integrity of those skills.

A novel approach to solving this problem involves the use of an orthogonally persistent operating system. (This was implemented in the Flex machine) In such a system there is no need to discard entities and invalidate their capabilities and therefore require an ACL- like mechanism to be able to restore these capabilities at a later point in time. The operating system maintains the integrity and security of the capabilities contained in all memory, both volatile and non-volatile; In part, by performing all of the serialization tasks instead of letting the user agents do it, as most operating systems do. Since the user programs are relieved of this responsibility, there is no need to validate their rights and capabilities or their access requests.

POSIX vs. Capsicum skills

POSIX draft 1003.1e specifies a concept of authorizations called "capabilities". However, POSIX capabilities are different from the capabilities in this article. A POSIX capability is not associated with an object; A process with CAP_NET_BIND_SERVICE capability can be accessed on TCP port 1024. In contrast, Capsicum's capabilities on FreeBSD and Linux combine a true capabilities system with UNIX design and the POSIX API. Capsicum capabilities are a refined form of filehandle. A right that can be delegated between processes and additional object types that extends beyond classic POSIX (e.g. process) can be referenced via capabilities. In Capsicum capability mode, processes can use non-global namespaces (such as the file system filename) to find objects and must instead be inherited or they can get the objects from other processes.

Research and Commercial Systems

See also

literature

Web links

Individual evidence

  1. ↑ engadget.com