From patchwork Sun Aug 9 16:22:12 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11706743 X-Patchwork-Delegate: paul@paul-moore.com Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 09ABB14E3 for ; Sun, 9 Aug 2020 16:22:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D5114206C0 for ; Sun, 9 Aug 2020 16:22:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="uTUGTYGq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726386AbgHIQWf (ORCPT ); Sun, 9 Aug 2020 12:22:35 -0400 Received: from mailomta14-re.btinternet.com ([213.120.69.107]:54491 "EHLO re-prd-fep-044.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726175AbgHIQWd (ORCPT ); Sun, 9 Aug 2020 12:22:33 -0400 Received: from re-prd-rgout-003.btmx-prd.synchronoss.net ([10.2.54.6]) by re-prd-fep-044.btinternet.com with ESMTP id <20200809162222.MUXS21348.re-prd-fep-044.btinternet.com@re-prd-rgout-003.btmx-prd.synchronoss.net>; Sun, 9 Aug 2020 17:22:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1596990142; bh=ZMfdXGkrmVeG6o7LCQgvwg8CeYTmpnx6V4GUwIhOFkU=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version; b=uTUGTYGq+LOtd5+56PE0BsNPAfUyPZrPUDDvRfdi6llSnovM2rT/nCF8fHVaLM3FpXidcsCd6d6KXrxUdrvyf5YL9u9tj9AAdHFppLpAdfLtfIGfIpqS1kQo77IaWQtyeudm1nFsjfC+1duMMdTXGpqBH5ujpY0re3KjsaBhVDAI8Xnoguw/053+86pjoEqCdiDD/Q/8pytDJMzKaHJvvba6iYX4aiLdMkh+Xv1j8AjpKdeLD1uDDWTB5TsvTDZNQfgmCRzzfpZtlMjVfaP6lA1kG0gyPYjdRytP0SDgTWGD5EqXmrlZZpV33uPb3ZNtUBtm/e1eix/CfiGqUy2lFA== Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=richard_c_haines@btinternet.com X-Originating-IP: [81.147.56.64] X-OWM-Source-IP: 81.147.56.64 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedrkeeigdelkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucenucfjughrpefhvffufffkofgggfestdekredtredttdenucfhrhhomheptfhitghhrghrugcujfgrihhnvghsuceorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqnecuggftrfgrthhtvghrnhepgfelleefjedtjeffgeeluddthffgjeekueduleelhfegveehvdelhedtvdegjeeunecuffhomhgrihhnpegtohhmmhhonhgtrhhithgvrhhirghpohhrthgrlhdrohhrghdpshgthhgruhhflhgvrhdqtggrrdgtohhmnecukfhppeekuddrudegjedrheeirdeigeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepkedurddugeejrdehiedrieegpdhmrghilhhfrhhomhepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeophgruhhlsehprghulhdqmhhoohhrvgdrtghomheqpdhrtghpthhtohepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqecuqfftvefrvfeprhhftgekvddvnehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgt ohhmpdhrtghpthhtohepoehsvghlihhnuhigsehvghgvrhdrkhgvrhhnvghlrdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (81.147.56.64) by re-prd-rgout-003.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9C2FD0B0E4609; Sun, 9 Aug 2020 17:22:22 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH] selinux-notebook: Convert terminology.md to markdown Date: Sun, 9 Aug 2020 17:22:12 +0100 Message-Id: <20200809162212.193739-1-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Signed-off-by: Richard Haines --- src/terminology.md | 349 +++++++++++++++++++++++++++++++-------------- 1 file changed, 243 insertions(+), 106 deletions(-) diff --git a/src/terminology.md b/src/terminology.md index 77eaade..410eff5 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -1,119 +1,256 @@ # Abbreviations and Terminology +- [Abbreviations](#abbreviations) +- [Terminology](#terminology) + ## Abbreviations -| | | -| ------- | ---------------------------------------------------------------------------------------- | -| AV | Access Vector | -| AVC | Access Vector Cache | -| BLP | Bell-La Padula | -| CC | [Common Criteria](http://www.commoncriteriaportal.org/) | -| CIL | Common Intermediate Language | -| CMW | Compartmented Mode Workstation | -| DAC | Discretionary Access Control | -| FLASK | Flux Advanced Security Kernel | -| Fluke | Flux kernel Environment | -| Flux | The Flux Research Group | -| ID | Identification | -| LSM | Linux Security Module | -| LAPP | Linux, Apache, PostgreSQL, PHP / Perl / Python | -| LSPP | Labeled Security Protection Profile | -| MAC | Mandatory Access Control | -| MCS | Multi-Category Security | -| MLS | Multi-Level Security | -| MMAC | Middleware Mandatory Access Control | -| NSA | National Security Agency | -| OM | Object Manager | -| OTA | over the air | -| PAM | Pluggable Authentication Module | -| RBAC | Role-based Access Control | -| RBACSEP | Role-based Access Control Separation | -| rpm | Red Hat Package Manager | -| SELinux | Security Enhanced Linux | -| SID | Security Identifier | -| SMACK | [Simplified Mandatory Access Control Kernel](http://www.schaufler-ca.com/) | -| SUID | Super-user Identifier | -| TE | Type Enforcement | -| UID | User Identifier | -| XACE | X (windows) Access Control Extension | +**AV** + +Access Vector + +**AVC** + +Access Vector Cache + +**BLP** + +Bell-La Padula + +**CC** + +[Common Criteria](http://www.commoncriteriaportal.org/) + +**CIL** + +Common Intermediate Language + +**CMW** + +Compartmented Mode Workstation + +**DAC** + +Discretionary Access Control + +**FLASK** + +Flux Advanced Security Kernel + +**Fluke** + +Flux kernel Environment + +**Flux** + +The Flux Research Group + +**ID** + +Identification + +**LSM** + +Linux Security Module + +**LAPP** + +Linux, Apache, PostgreSQL, PHP / Perl / Python + +**LSPP** + +Labeled Security Protection Profile + +**MAC** + +Mandatory Access Control + +**MCS** + +Multi-Category Security + +**MLS** + +Multi-Level Security + +**MMAC** + +Middleware Mandatory Access Control + +**NSA** + +National Security Agency + +**OM** + +Object Manager + +**OTA** + +over the air + +**PAM** + +Pluggable Authentication Module + +**RBAC** + +Role-based Access Control + +**RBACSEP** + +Role-based Access Control Separation + +**rpm** + +Red Hat Package Manager + +**SELinux** + +Security Enhanced Linux + +**SID** + +Security Identifier + +**SMACK** + +[Simplified Mandatory Access Control Kernel](http://www.schaufler-ca.com/) + +**SUID** + +Super-user Identifier + +**TE** + +Type Enforcement + +**UID** + +User Identifier + +**XACE** + +X (windows) Access Control Extension ## Terminology These give a brief introduction to the major components that form the core SELinux infrastructure. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Access Vector (AV)A bit map representing a set of permissions (such as open, read, write).
Access Vector Cache (AVC)

A component that stores access decisions made by the SELinux Security Server for subsequent use by Object Managers. This allows previous decisions to be retrieved without the overhead of re-computation.

-

Within the core SELinux services there are two Access Vector Caches:

DomainFor SELinux this consists of one or more processes associated to the type component of a Security Context. Type Enforcement rules declared in Policy describe how the domain will interact with objects (see Object Class).
Linux Security Module (LSM)

A framework that provides hooks into kernel components (such as disk and network services) that can be utilised by security modules (e.g. SELinux and SMACK) to perform access control checks.

-

Currently only one LSM module can be loaded, however work is in progress to stack multiple modules).

Mandatory Access ControlAn access control mechanisim enforced by the system. This can be achieved by 'hard-wiring' the operating system and applications (the bad old days - well good for some) or via a policy that conforms to a Policy. Examples of policy based MAC are SELinux and SMACK.
Multi-Level Security (MLS)Based on the Bell-La & Padula model (BLP) for confidentiality in that (for example) a process running at a 'Confidential' level can read / write at their current level but only read down levels or write up levels. While still used in this way, it is more commonly used for application separation utilising the Multi-Category Security (MCS) variant.
Object Class

Describes a resource such as files, sockets or services.

-

Each 'class' has relevant permissions associated to it such as read, write or export. This allows access to be enforced on the instantiated object by their Object Manager.

Object Manager

Userspace and kernel components that are responsible for the labeling, management (e.g. creation, access, destruction) and enforcement of the objects under their control. Object Managers call the Security Server for an access decision based on a source and target Security Context (or SID), an Object Class and a set of permissions (or AVs). The Security Server will base its decision on whether the currently loaded Policy will allow or deny access.

-

An Object Manager may also call the Security Server to compute a new Security Context or SID for an object.

PolicyA set of rules determining access rights. In SELinux these rules are generally written in a kernel policy language using either m4(1) macro support (e.g. Reference Policy) or the new CIL language. The Policy is then compiled into a binary format for loading into the Security Server.
Role Based Access ControlSELinux users are associated to one or more roles, each role may then be associated to one or more Domain types.
Role Based Access Control-Seperation

Role-based separation of user home directories. An optional policy tunable is required:

-

tunableif enable_rbacsep

Security Server

A sub-system in the Linux kernel that makes access decisions and computes security contexts based on Policy on behalf of SELinux-aware applications and Object Managers.

-

The Security Server does not enforce a decision, it merely states whether the operation is allowed or not according to the Policy. It is the SELinux-aware application or Object Manager responsibility to enforce the decision.

Security Context

An SELinux Security Context is a variable length string that consists of the following mandatory components user:role:type and an optional [:range] component.

-

Generally abbreviated to 'context', and sometimes called a 'label'.

Security Identifier (SID)

SIDs are unique opaque integer values mapped by the kernel Security Server and userspace AVC that represent a Security Context.

-

The SIDs generated by the kernel Security Server are u32 values that are passed via the Linux Security Module hooks to/from the kernel Object Managers.

Type EnforcementSELinux makes use of a specific style of type enforcement (TE) to enforce Mandatory Access Control. This is where all subjects and objects have a type identifier associated to them that can then be used to enforce rules laid down by Policy.
+**Access Vector (AV)** + +A bit map representing a set of permissions (such as open, read, write). + +**Access Vector Cache (AVC)** + +A component that stores access decisions made by the SELinux **Security Server** +for subsequent use by **Object Managers**. This allows previous decisions to +be retrieved without the overhead of re-computation. Within the core SELinux +services there are two **Access Vector Caches**: + +1. A kernel AVC that caches decisions by the **Security Server** on behalf of + kernel based object managers. +2. A userspace AVC built into libselinux that caches decisions when + SELinux-aware applications use ***avc_open**(3)* with ***avc_has_perm**(3)* + or ***avc_has_perm_noaudit**(3)* function calls. This will save calls to the + kernel after the first decision has been made. Note that the preferred + option is to use the ***selinux_check_access**(3)* function as this will + utilise the userspace AVC as explained in the + [**Computing Access Decisions**](computing_access_decisions.md#computing-access-decisions) + section. + +**Domain** + +For SELinux this consists of one or more processes associated to the type +component of a **Security Context**. **Type Enforcement** rules declared in +policy describe how the domain will interact with objects (see **Object Class**). + +**Linux Security Module (LSM)** + +A framework that provides hooks into kernel components (such as disk and +network services) that can be utilised by security modules (e.g. **SELinux** and +SMACK) to perform access control checks. Work is in progress to stack multiple +modules + +**Mandatory Access Control** + +An access control mechanisim enforced by the system. This can be achieved +by 'hard-wiring' the operating system and applications or via a policy that +conforms to a **Policy**. Examples of policy based MAC are **SELinux** and SMACK. + +**Multi-Level Security (MLS)** + +Based on the Bell-La & Padula model (BLP) for confidentiality in that +(for example) a process running at a 'Confidential' level can read / write at +their current level but only read down levels or write up levels. While still +used in this way, it is more commonly used for application separation +utilising the Multi-Category Security (MCS) variant. + +**Object Class** + +Describes a resource such as files, sockets or services. Each 'class' has +relevant permissions associated to it such as read, write or export. +This allows access to be enforced on the instantiated object by their +**Object Manager**. + +**Object Manager** + +Userspace and kernel components that are responsible for the labeling, +management (e.g. creation, access, destruction) and enforcement of the objects +under their control. **Object Managers** call the **Security Server** for an +access decision based on a source and target **Security Context** +(or **SID**), an **Object Class** and a set of permissions (or **AV**s). +The **Security Server** will base its decision on whether the currently loaded +**Policy** will allow or deny access. An **Object Manager** may also call the +**Security Server** to compute a new **Security Context** or **SID** +for an object. + +**Policy** + +A set of rules determining access rights. In SELinux these rules are generally +written in a kernel policy language using either ***m4**(1)* macro support +(e.g. Reference Policy) or the CIL language. The **Policy** is then compiled +into a binary format for loading into the **Security Server**. + +**Role Based Access Control** + +SELinux users are associated to one or more roles, each role may then be +associated to one or more **Domain** types. + +**Role Based Access Control-Seperation** + +Role-based separation of user home directories. An optional policy tunable is +required: *tunableif enable_rbacsep* + +**Security Server** + +A sub-system in the Linux kernel that makes access decisions and computes +security contexts based on **Policy** on behalf of SELinux-aware applications +and Object Managers. The **Security Server** does not enforce a decision, it +merely states whether the operation is allowed or not according to the +**Policy**. It is the SELinux-aware application or **Object Manager** +responsibility to enforce the decision. + +**Security Context** + +An SELinux **Security Context** is a variable length string that consists of +the following mandatory components *user:role:type* and an optional *[:range]* +component. Generally abbreviated to 'context', and sometimes called a 'label'. + +**Security Identifier (SID)** + +SIDs are unique opaque integer values mapped by the kernel **Security Server** +and userspace AVC that represent a **Security Context**. The SIDs generated +by the kernel **Security Server** are `u32` values that are passed via the +**Linux Security Module** hooks to/from the kernel **Object Managers**. + +**Type Enforcement** + +SELinux makes use of a specific style of type enforcement (TE) to enforce +**Mandatory Access Control**. This is where all subjects and objects have a +type identifier associated to them that can then be used to enforce rules +laid down by **Policy**.