From patchwork Tue Aug 25 08:37:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735149 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 6269E1731 for ; Tue, 25 Aug 2020 08:38:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 417182071E for ; Tue, 25 Aug 2020 08:38:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="S0UOd6sO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725792AbgHYIiN (ORCPT ); Tue, 25 Aug 2020 04:38:13 -0400 Received: from mailomta11-sa.btinternet.com ([213.120.69.17]:34663 "EHLO sa-prd-fep-044.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725936AbgHYIiL (ORCPT ); Tue, 25 Aug 2020 04:38:11 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-044.btinternet.com with ESMTP id <20200825083807.GKNX3440.sa-prd-fep-044.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344687; bh=K5ZcZQGcI0EbTFBF4DcaOF0uGgrB91qDpkJQfAP19UE=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=S0UOd6sOzKWP9bJ1+4qf2dxeQC7l9K/f6xbH4M4Hpqyk+YXImj8onmfQv9WOptwMpI6aOrwZWWBI/4VJEy1oR5hHJta7v3Vdlu6Z39ufKCDV0sQl/Z9krmq26px72wrHdOrO0cdPVrQ9uOjdZI/0s4+3SQUmPFgKQPE1HOqDza/jmk+EI/LD3SIWfrtJCKkWgpsmbbFSZQZ6WipD3bXm+n4/L8TA7nJe646pvORrHQb1GkwYGzEuxgnLgpKC7/1rl8mgRnR/wfZppJWw+oup+5CvJmlx7+7yGO2QBz8YagNiXkRy7u0NTcNCokHX/SljurAcH9hDprvC3hoWgdvAmA== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=70/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecugfgrrhhlhicushhprhhinhhgucdljedtmdenucfjughrpefhvffufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpedvjedvhfefjefhuefffeektedtieejffffudfhtdetueefteeikeelleetveekudenucffohhmrghinhepghhoohhglhgvtghouggvrdgtohhmnecukfhppedutdelrdduheehrddufedtrdduiedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplhhotggrlhhhohhsthdrlhhotggrlhguohhmrghinhdpihhnvghtpedutdelrdduheehrddufedtrdduiedtpdhmrghilhhfrhhomhepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeophgruhhlsehprghulhdqmhhoohhrvgdrtghomheqpdhrtghpthhtohepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqecuqfftvefrvfeprhhftgekvddvnehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgt ohhmpdhrtghpthhtohepoehsvghlihhnuhigsehvghgvrhdrkhgvrhhnvghlrdhorhhgqe X-RazorGate-Vade-Verdict: clean 70 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599D6F; Tue, 25 Aug 2020 09:38:07 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 01/18] apache_support: Convert to markdown Date: Tue, 25 Aug 2020 09:37:26 +0100 Message-Id: <20200825083743.6508-2-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/apache_support.md | 79 ++++++++++++++++++------------------------- 1 file changed, 33 insertions(+), 46 deletions(-) diff --git a/src/apache_support.md b/src/apache_support.md index 8e8df1c..5c012cf 100644 --- a/src/apache_support.md +++ b/src/apache_support.md @@ -1,5 +1,8 @@ # Apache SELinux Support +- [*mod_selinux* Overview](#mod_selinux-overview) +- [Bounds Overview](#bounds-overview) + Apache web servers are supported by SELinux using the Apache policy modules from the Reference Policy (*httpd* modules), however there is no specific Apache object manger. There is though an SELinux-aware shared @@ -25,31 +28,20 @@ configuration details is available from: The objective of these Apache add-on services is to achieve a fully SELinux-aware web stack (although not there yet). For example, currently -the LAPP1 -(Linux, Apache, PostgreSQL, PHP / Perl / Python) stack has the following support: - - - - - - - - - - - - - - - - - - - - -
LLinux has SELinux support.
AApache has partial SELinux support using the 'Apache SELinux Plus' module.
PPostgreSQL has SELinux support using the PostgreSQL sepgsql extension .
PPHP / Perl / Python are not currently SELinux-aware, however PHP and Python do have support for libselinux functions in packages: PHP - with the php-pecl-selinux package, Python - with the libselinux-python package.
- -The [A secure web application platform powered by SELinux](http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf) +the LAPP[^fn_as_1] (Linux, Apache, PostgreSQL, PHP / Perl / Python) +stack has the following support: + +**L** - Linux has SELinux support. + +**A** - Apache has partial SELinux support using the 'Apache SELinux Plus' module. + +**P** - PostgreSQL has SELinux support using the PostgreSQL *sepgsql* extension. + +**P** - PHP / Perl / Python are not currently SELinux-aware, however PHP +and Python do have support for libselinux functions in packages: PHP - with +the *php-pecl-selinux* package, Python - with the *libselinux-python* package. + +The "[A secure web application platform powered by SELinux](http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf)" document gives a good overview of the LAPP architecture. ## *mod_selinux* Overview @@ -59,22 +51,20 @@ What the *mod_selinux* module achieves is to allow a web application context based on policy rather than that of the web server process itself, for example: -1. A user sends an HTTP request to Apache that requires the services of - a web application (Apache may or may not apply HTTP authentication). -2. Apache receives the request and launches the web application - instance to perform the task: -- Without *mod_selinux* enabled the web applications security context - is identical to the Apache web server process, it is therefore not - possible to restrict it privileges. - -- With *mod_selinux* enabled, the web application is launched with - the security context defined in the *mod_selinux.conf* file - (*selinuxDomainVal <security_context>* entry). It is also - possible to restrict its privileges as described in the - [Bounds Overview](#bounds-overview) section. - -3. The web application exits, handing control back to the web server - that replies with the HTTP response. +1. A user sends an HTTP request to Apache that requires the services of + a web application (Apache may or may not apply HTTP authentication). +2. Apache receives the request and launches the web application + instance to perform the task: + - Without *mod_selinux* enabled the web applications security context + is identical to the Apache web server process, it is therefore not + possible to restrict it privileges. + - With *mod_selinux* enabled, the web application is launched with + the security context defined in the *mod_selinux.conf* file + (*selinuxDomainVal \* entry). It is also + possible to restrict its privileges as described in the + [Bounds Overview](#bounds-overview) section. +3. The web application exits, handing control back to the web server + that replies with the HTTP response. ## Bounds Overview @@ -120,11 +110,8 @@ operation will be denied and an *SELINUX_ERR* entry will be added to the audit log stating *op=security_compute_av reason=bounds* with the context strings and the denied class and permissions. -
-
    -

  1. This is similar to the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) stack, however MySQL is not SELinux-aware.↩

    2. -
-
+[^fn_as_1]: This is similar to the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) +stack, however MySQL is not SELinux-aware. From patchwork Tue Aug 25 08:37:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735151 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 9A263739 for ; Tue, 25 Aug 2020 08:38:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7ACF02071E for ; Tue, 25 Aug 2020 08:38:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="Lsf9W3ya" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728955AbgHYIiN (ORCPT ); Tue, 25 Aug 2020 04:38:13 -0400 Received: from mailomta7-sa.btinternet.com ([213.120.69.13]:34784 "EHLO sa-prd-fep-049.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726365AbgHYIiM (ORCPT ); Tue, 25 Aug 2020 04:38:12 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-049.btinternet.com with ESMTP id <20200825083808.JHDG4195.sa-prd-fep-049.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344688; bh=iNMO/xxmNkqwN2Gxa1/mYOprgi+wK92MvaSCyczuomg=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=Lsf9W3yat5sBVKpFhPQLYIta12pgiSuLW35ZvgtnHPfaWvcw/kZtinCMCDD7W6iY2Xexj+5lzb5Ij3WDRXGfaMWDaNb4/53R8yEUwFtT0mqxqhbGsBQz/UfBQcZbB+VEZ3gI0oAZmCE+7EibCX8BP9s8wIeAwVUbRBJSSWccbJcjFcBM2jPA4H0wg27cG5CnF1qQJ/9jTrR2zI1Zfdi5nFt8HjQ7Fjmu8fEGZ5kXWnmu/CzGmX4aKamBcC6aQujLXGVy3B2YuNxP2zVUqjxqFr8jPA0VMkgery+2EF6ZXTVA2I2Xvs6k2FgpyNJQFbDZrDHbvHOK36Q1sVxVRpoQ0Q== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599D7B; Tue, 25 Aug 2020 09:38:08 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 02/18] auditing: Convert to markdown Date: Tue, 25 Aug 2020 09:37:27 +0100 Message-Id: <20200825083743.6508-3-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/auditing.md | 300 ++++++++++++++++++++++-------------------------- 1 file changed, 135 insertions(+), 165 deletions(-) diff --git a/src/auditing.md b/src/auditing.md index 8272e02..8812db6 100644 --- a/src/auditing.md +++ b/src/auditing.md @@ -1,179 +1,149 @@ # Auditing SELinux Events +- [AVC Audit Events](#avc-audit-events) + - [Example Audit Events](#example-audit-events) +- [General SELinux Audit Events](#general-selinux-audit-events) + For SELinux there are two main types of audit event: -1. **AVC Audit Events** - These are generated by the AVC subsystem as a - result of access denials, or where specific events have requested an - audit message (i.e. where an *auditallow* rule has been used in - the policy). -2. **SELinux-aware Application Events** - These are generated by the - SELinux kernel services and SELinux-aware applications for events - such as system errors, initialisation, policy load, changing boolean - states, setting of enforcing / permissive mode, relabeling etc. +1. **AVC Audit Events** - These are generated by the AVC subsystem as a + result of access denials, or where specific events have requested an + audit message (i.e. where an *auditallow* rule has been used in + the policy). +2. **SELinux-aware Application Events** - These are generated by the + SELinux kernel services and SELinux-aware applications for events + such as system errors, initialisation, policy load, changing boolean + states, setting of enforcing / permissive mode, relabeling etc. The audit and event messages are generally stored in one of the following logs (in F-27 anyway): -1. The SELinux kernel boot events are logged in the */var/log/dmesg* log. -2. The system log */var/log/messages* contains messages generated by - SELinux before the audit daemon has been loaded. -3. The audit log */var/log/audit/audit.log* contains events that take - place after the audit daemon has been loaded. The AVC audit messages - of interest are described in the [AVC Audit Events](#avc-audit-events) - section with others described in the - [General SELinux Audit Events](#general-selinux-audit-events) - section. Fedora uses the audit framework **auditd**(8) as standard. +1. The SELinux kernel boot events are logged in the */var/log/dmesg* log. +2. The system log */var/log/messages* contains messages generated by + SELinux before the audit daemon has been loaded. +3. The audit log */var/log/audit/audit.log* contains events that take + place after the audit daemon has been loaded. The AVC audit messages + of interest are described in the [AVC Audit Events](#avc-audit-events) + section with others described in the + [General SELinux Audit Events](#general-selinux-audit-events) + section. Fedora uses the audit framework ***auditd**(8)* as standard. Notes: -1. It is not mandatory for SELinux-aware applications to audit events - or even log them in the audit log. The decision is made by the - application designer. -2. The format of audit messages do not need to conform to any format, - however where possible applications should use the - ***audit_log_user_avc_message**(3)* function with a suitably - formatted message if using ***auditd**(8)*. The type of audit events - possible are defined in the *include/libaudit.h* and - *include/linux/audit.h* files. -3. Those libselinux library functions that output messages do so to - *stderr* by default, however this can be changed by calling - ***selinux_set_callback**(3)* and specifying an alternative log - handler. +1. It is not mandatory for SELinux-aware applications to audit events + or even log them in the audit log. The decision is made by the + application designer. +2. The format of audit messages do not need to conform to any format, + however where possible applications should use the + ***audit_log_user_avc_message**(3)* function with a suitably + formatted message if using ***auditd**(8)*. The type of audit events + possible are defined in the *include/libaudit.h* and + *include/linux/audit.h* files. +3. Those libselinux library functions that output messages do so to + *stderr* by default, however this can be changed by calling + ***selinux_set_callback**(3)* and specifying an alternative log handler. ## AVC Audit Events -**Table 1** describes the general format of AVC audit -messages in the audit.log when access has been denied or an audit event -has been specifically requested. Other types of events are shown in the -section that follows. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
KeywordDescription
type

For SELinux AVC events this can be:

-

type=AVC - for kernel events

-

type=USER_AVC - for user-space object manager events

-

Note that once the AVC event has been logged, another event with type=SYSCALL may follow that contains further information regarding the event.

-

The AVC event can always be tied to the relevant SYSCALL event as they have the same serial_number in the msg=audit(time:serial_number) field as shown in the following example:

-

type=AVC msg=audit(1243332701.744:101): avc: denied { getattr } for pid=2714 comm="ls" path="/usr/lib/locale/locale-archive" dev=dm-0 ino=353593 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:locale_t:s0 tclass=file

-

type=SYSCALL msg=audit(1243332701.744:101): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=553ac0 a2=552ff4 a3=bfc5eab0 items=0 ppid=2671 pid=2714 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="ls" exe="/bin/ls" subj=system_u:object_r:unlabeled_t:s0 key=(null)

msgThis will contain the audit keyword with a reference number (e.g. msg=audit(1243332701.744:101))
avc

This will be either denied when access has been denied or granted when an auditallow rule has been defined by the policy.

-

The entries that follow the *avc=* field depend on what type of event is being audited. Those shown below are generated by the kernel AVC audit function, however the user space AVC audit function will return fields relevant to the application being managed by their Object Manager.

pidIf a task, then log the process id (pid) and the name of the executable file (comm).
comm
capabilityIf a capability event then log the identifier.
pathIf a File System event then log the relevant information. Note that the name field may not always be present.
name
dev
ino
laddrIf a Socket event then log the Source / Destination addresses and ports for IP4 or IP6 sockets (AF_INET).
lport
faddr
fport
pathIf a File Socket event then log the path (AF_UNIX).
saddr

If a Network event then log the Source / Destination addresses and ports with the network interface for IP4 or IP6 networks (AF_INET).

src
daddr
dest
netif
sauidIPSec security association identifiers
hostname
addr
residX-Windows resource ID and type.
restype
scontextThe security context of the source or subject.
tcontextThe security context of the target or object.
tclassThe object class of the target or object.
permissiveKeyword introduced in Linux 4.17 to indicate whether the event -was denied or granted due to global or per-domain permissive -mode.
- -**Table 1: AVC Audit Message Description** - -Example *audit.log* denied and granted events are shown in the following -examples: - -This is an example **denied** message - note that there are two -`type=AVC` calls, but only one corresponding `type=SYSCALL` entry. +The **AVC Audit Message Keyword Descriptions** table describes the general +format of AVC audit messages in the *audit.log* when access has been denied +or an audit event has been specifically requested. Other types of events are +shown in the section that follows. + +**AVC Audit Message Keyword Descriptions:** + +*type* + +- For SELinux AVC events this can be: + - *type=AVC* - for kernel events. + - *type=USER_AVC* - for user-space object manager events. +- Note that once the AVC event has been logged, another event with + *type=SYSCALL* may follow that contains further information regarding the + event. +- The AVC event can always be tied to the relevant *SYSCALL* event as they + have the same *serial_number* in the *msg=audit(time:serial_number)* field + as shown in the following example: + - ***type=AVC*** *msg=audit(1243332701.744:***101***): avc: denied { getattr } + for pid=2714 comm="ls" path="/usr/lib/locale/locale-archive" dev=dm-0 + ino=353593 scontext=system_u:object_r:unlabeled_t:s0 + tcontext=system_u:object_r:locale_t:s0 tclass=file* + - ***type=SYSCALL*** *msg=audit(1243332701.744:***101***): arch=40000003 + syscall=197 success=yes exit=0 a0=3 a1=553ac0 a2=552ff4 a3=bfc5eab0 + items=0 ppid=2671 pid=2714 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 + egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="ls" exe="/bin/ls" + subj=system_u:object_r:unlabeled_t:s0 key=(null)* + +*msg* + +- This will contain the audit keyword with a reference number + (e.g. *msg=audit(1243332701.744:101)*) + +*avc* + +- This will be either denied when access has been denied or granted when an + *auditallow* rule has been defined by the policy. +- The entries that follow the *avc=* field depend on what type of event is + being audited. Those shown below are generated by the kernel AVC audit + function, however the user space AVC audit function will return fields + relevant to the application being managed by their Object Manager. + +*pid* and *comm* + +- If a task, then log the process id (*pid*) and the name of the executable + file (*comm*). + +*capability* + +- If a capability event then log the identifier. + +*path*, *name*, *dev* and *ino* + +- If a File System event then log the relevant information. Note that the + *name* field may not always be present. + +*laddr*, *lport*, *faddr* and *fport* + +- If a Socket event then log the Source / Destination addresses and ports + for IPv4 or IPv6 sockets (*AF_INET*). + +*path* + +- If a File Socket event then log the path (*AF_UNIX*). + +*saddr*, *src*, *daddr*, *dest* and *netif* + +- If a Network event then log the Source / Destination addresses and ports + with the network interface for IPv4 or IPv6 networks (*AF_INET*). + +*sauid*, *hostname* and *addr* + +- IPSec security association identifiers. + +*resid* and *restype* + +- X-Windows resource ID and type. + +*scontext* + +- The security context of the source or subject. + +*tcontext* + +- The security context of the target or object. + +*tclass* + +- The object class of the target or object. + +*permissive* + +- Keyword introduced in Linux 4.17 to indicate whether the event + was denied or granted due to global or per-domain permissive mode. + +### Example Audit Events + +This is an example ***denied*** message - note that there are two +***type=AVC*** calls, but only one corresponding ***type=SYSCALL*** entry. ``` type=AVC msg=audit(1242575005.122:101): avc: denied { rename } for @@ -196,7 +166,7 @@ exe="/usr/bin/canberra-gtk-play" subj=test_u:staff_r:oddjob_mkhomedir_t:s0 key=(null) ``` -These are example X-Windows object manager audit message: +These are example X-Windows object manager audit messages: ``` type=USER_AVC msg=audit(1267534171.023:18): user pid=1169 uid=0 @@ -211,7 +181,7 @@ type=USER_AVC msg=audit(1267534395.930:19): user pid=1169 uid=0 auid=4294967295 ses=4294967295 subj=system_u:unconfined_r:unconfined_t msg='avc: denied { read } for request=SELinux:SELinuxGetClientContext comm=X-setest resid=3c00001 -restype=<unknown> +restype= scontext=unconfined_u:unconfined_r:x_select_paste_t tcontext=unconfined_u:unconfined_r:unconfined_t tclass=x_resource : exe="/usr/bin/Xorg" sauid=0 hostname=? addr=? terminal=?' @@ -357,7 +327,7 @@ perms=ioctl,read,write,getattr,lock,append,open ``` These were generated by the kernel security server when an SELinux-aware -application was trying to use ***setcon***(3) to create a new thread. To +application was trying to use ***setcon**(3)* to create a new thread. To fix this a *typebounds* statement is required in the policy. ``` From patchwork Tue Aug 25 08:37:28 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735153 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 C40B414F6 for ; Tue, 25 Aug 2020 08:38:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A24F52071E for ; Tue, 25 Aug 2020 08:38:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="Ic23xeMl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729165AbgHYIiP (ORCPT ); Tue, 25 Aug 2020 04:38:15 -0400 Received: from mailomta22-sa.btinternet.com ([213.120.69.28]:12727 "EHLO sa-prd-fep-043.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726905AbgHYIiO (ORCPT ); Tue, 25 Aug 2020 04:38:14 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-043.btinternet.com with ESMTP id <20200825083808.MPKL26847.sa-prd-fep-043.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344688; bh=/LagwUNmVydS69xhHfqyQiV7nB4ff26cXv4LpsqTBLk=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=Ic23xeMlPeTFrluruvHqIAfLHURo5dUS391yK+8IceWekUYWdOvphjq6MGLqsSG8xjxrz64MS/H74eChKp6zmsUisXgjlrSanvddBuo2CA632T31SdJxJcskiNt1Wg9q0XY+9xH4VMtAbA4SIN9PaOmjJ3DxqIEMtoX1Bwp2uSf6VPugVWbyXm5fzMpsOVyQWh11cUR1rLSvxSfP6MtmyJqwWkWeJfAmr4qPg3/em3BnymLKaN8A3QLUwEEriubxcDe49DJe4igKugRlnN7KcUoUvlRiXpzEzFd5BlPkSNO7gTcxIaxM5LTvNEj6E1c48Y2zi+XGjm/4j4eCILnPUg== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfgggtgfesthekredtredtjeenucfhrhhomheptfhitghhrghrugcujfgrihhnvghsuceorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqnecuggftrfgrthhtvghrnhepgfekgffghffgleekgfellefftedvhfejveehhfekkefgvdehueetgfffffelkedtnecukfhppedutdelrdduheehrddufedtrdduiedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplhhotggrlhhhohhsthdrlhhotggrlhguohhmrghinhdpihhnvghtpedutdelrdduheehrddufedtrdduiedtpdhmrghilhhfrhhomhepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeophgruhhlsehprghulhdqmhhoohhrvgdrtghomheqpdhrtghpthhtohepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqecuqfftvefrvfeprhhftgekvddvnehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmpdhrtghpthhtohepoehsvghlihhnuhigsehvghgvrhdrkhgvrhhnvghlrdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599D8D; Tue, 25 Aug 2020 09:38:08 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 03/18] avc_rules: Convert to markdown Date: Tue, 25 Aug 2020 09:37:28 +0100 Message-Id: <20200825083743.6508-4-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/avc_rules.md | 115 +++++++++++++++++++++++------------------------ 1 file changed, 56 insertions(+), 59 deletions(-) diff --git a/src/avc_rules.md b/src/avc_rules.md index 7572302..b1535d3 100644 --- a/src/avc_rules.md +++ b/src/avc_rules.md @@ -1,5 +1,11 @@ # Access Vector Rules +- [Access Vector Rules](#access-vector-rules) + - [*allow*](#allow) + - [*dontaudit*](#dontaudit) + - [*auditallow*](#auditallow) + - [*neverallow*](#neverallow) + The AV rules define what access control privileges are allowed for processes and objects. There are four types of AV rule: *allow*, *dontaudit*, *auditallow*, and *neverallow* as explained in the sections that @@ -26,63 +32,56 @@ rule_name source_type target_type : class perm_set; **Where:** - - - - - - - - - - - - - - - - - - - -
rule_nameThe applicable allow, dontaudit, auditallow, and neverallow rule keyword.

source_type

-

target_type

One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces '{}'. Entries can be excluded from the list by using the negative operator '-'.

-

The *target_type* can have the self keyword instead of type, typealias or attribute identifiers. This means that the *target_type* is the same as the *source_type*.

-

The neverallow rule also supports the wildcard operator '*' to specify that all types are to be included and the complement operator '~' to specify all types are to be included except those explicitly listed.

classOne or more object classes. Multiple entries consist of a space separated list enclosed in braces '{}'.
perm_set

The access permissions the source is allowed to access for the target object (also known as the Access Vector). Multiple entries consist of a space separated list enclosed in braces '{}'.

-

The optional wildcard operator '*' specifies that all permissions for the object class can be used.

-

The complement operator '~' is used to specify all permissions except those explicitly listed (although the compiler issues a warning if the dontaudit rule has '~'.

+*rule_name* + +The applicable *allow*, *dontaudit*, *auditallow*, and *neverallow* rule keyword. + +*source_type*, *target_type* + +One or more source / target *type*, *typealias* or *attribute* identifiers. +Multiple entries consist of a space separated list enclosed in braces \'\{\}\'. +Entries can be excluded from the list by using the negative operator \'-\'. +The *target_type* can have the self keyword instead of *type*, *typealias* +or *attribute* identifiers. This means that the *target_type* is the same +as the *source_type*. +The *neverallow* rule also supports the wildcard operator \'\*\' to specify +that all types are to be included and the complement operator \'\~\' to +specify all types are to be included except those explicitly listed. + +*class* + +One or more object classes. Multiple entries consist of a space separated +list enclosed in braces \'\{\}\'. + +*perm_set* + +The access permissions the source is allowed to access for the target +object (also known as the Access Vector). Multiple entries consist of a +space separated list enclosed in braces \'\{\}\'. +The optional wildcard operator \'\*\' specifies that all permissions for +the object *class* can be used. +The complement operator \'\~\' is used to specify all permissions except +those explicitly listed (although the compiler issues a warning if the +*dontaudit* rule has \'\~\'. **The statements are valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesYes
Conditional Policy if Statementoptional Statementrequire Statement
Yes: allow, dontaudit, auditallow No: neverallowYes: allow, dontaudit, auditallow, neverallowNo: allow, dontaudit, auditallow, neverallow
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | Yes | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| Yes: *allow*, *dontaudit*, *auditallow* No: *neverallow* | Yes | No | ## *allow* -The allow rule checks whether the operations between the source\_type -and target_type are allowed for the class and permissions defined. It +The allow rule checks whether the operations between the *source_type* +and *target_type* are allowed for the class and permissions defined. It is the most common statement that many of the **Reference Policy** helper macros and interface definitions expand into multiple allow rules. @@ -177,8 +176,7 @@ auditallow ada_t self:process execstack; This rule specifies that an *allow* rule must not be generated for the operation, even if it has been previously allowed. The *neverallow* statement is a compiler enforced action, where the ***checkpolicy**(8)*, -***checkmodule**(8)* 1 -or ***secilc**(8)* 2 +***checkmodule**(8)*[^fn_avc_1] or ***secilc**(8)*[^fn_avc_2] compiler checks if any allow rules have been generated in the policy source, if so it will issue a warning and stop. @@ -201,12 +199,11 @@ neverallow ~can_read_shadow_passwords shadow_t:file read; neverallow { domain -mmap_low_domain_type } self:memprotect mmap_zero; ``` -
-
    -

  1. neverallow statements are allowed in modules, however to detect these the semanage.conf file must have the 'expand-check=1' entry present.↩

    2. -

  2. The *--disable-neverallow* option can be used with secilc(8) to disable neverallow rule checking.↩

    3. -
-
+[^fn_avc_1]: *neverallow* statements are allowed in modules, however to detect +these the *semanage.conf* file must have the 'expand-check=1' entry present. + +[^fn_avc_2]: The *\-\-disable-neverallow* option can be used with ***secilc**(8)* +to disable *neverallow* rule checking. From patchwork Tue Aug 25 08:37:29 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735155 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 EE5CA1731 for ; Tue, 25 Aug 2020 08:38:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D3C512074D for ; Tue, 25 Aug 2020 08:38:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="brk6iQT6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726905AbgHYIiQ (ORCPT ); Tue, 25 Aug 2020 04:38:16 -0400 Received: from mailomta12-sa.btinternet.com ([213.120.69.18]:26121 "EHLO sa-prd-fep-047.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728061AbgHYIiO (ORCPT ); Tue, 25 Aug 2020 04:38:14 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-047.btinternet.com with ESMTP id <20200825083808.VUFH4609.sa-prd-fep-047.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344688; bh=fC2wyhpHaURkZcuBXZz6alQIM4TXhTCsioaQDwjBlVE=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=brk6iQT6Uk1fUXMQ2T9m3alODjj/EBpHp9S8uLJK2WT8QVkkMID8fsuPk4bkn+O6g3UTeyK/WeKVZLbewyDwF8LEfD/x1cfkXYu6PTYp5tNoiY6Y7LtULcnLHjNf7c0uLis4CHDh3d1xakUKvTFXAEg+RqEmowEHpYHjtq1jErcdq71h5hs45GXod/krZZTHj480lO8XrCFI0sUgIVzlw4ueGKpaNwG/gZxiOgn6NztmEcPw5yMOGq+RWdANz5HczrjU8CBALF1TY/PJkMkAw0wqZygkiq6pX5aW5kHwzRSZAoxm9O6aXYp87ibbydc6NGRfrXnptKDmFlPEx//jqg== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599D94; Tue, 25 Aug 2020 09:38:08 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 04/18] bounds_rules: Convert to markdown Date: Tue, 25 Aug 2020 09:37:29 +0100 Message-Id: <20200825083743.6508-5-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/bounds_rules.md | 65 +++++++++++++++++---------------------------- 1 file changed, 25 insertions(+), 40 deletions(-) diff --git a/src/bounds_rules.md b/src/bounds_rules.md index 55a793a..6def780 100644 --- a/src/bounds_rules.md +++ b/src/bounds_rules.md @@ -1,5 +1,7 @@ # Bounds Rules +- [*typebounds*](#typebounds) + Bounds handling was added in version 24 of the policy and consisted of adding *userbounds*, *rolebounds* and *typebounds* information to the policy. However only the *typebounds* rule is currently implemented by @@ -28,49 +30,32 @@ typebounds bounding_domain bounded_domain; **Where:** - - - - - - - - - - - - - - - -
typeboundsThe typebounds keyword.
bounding_domainThe type or typealias identifier of the parent domain.
bounded_domainOne or more type or typealias identifiers of the child domains. Multiple entries consist of a comma ',' separated list.
+*typebound* + +The *typebounds* keyword. + +*bounding_domain* + +The *type* or *typealias* identifier of the parent domain. + +*bounded_domain* + +One or more *type* or *typealias* identifiers of the child domains. +Multiple entries consist of a comma ',' separated list. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesYes
Conditional Policy if Statementoptional Statementrequire Statement
NoYesNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | Yes | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | Yes | No | **Example:** From patchwork Tue Aug 25 08:37:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735157 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 71A05739 for ; Tue, 25 Aug 2020 08:38:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 537B920706 for ; Tue, 25 Aug 2020 08:38:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="aH0WwE0z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728061AbgHYIiR (ORCPT ); Tue, 25 Aug 2020 04:38:17 -0400 Received: from mailomta8-sa.btinternet.com ([213.120.69.14]:24199 "EHLO sa-prd-fep-045.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728087AbgHYIiP (ORCPT ); Tue, 25 Aug 2020 04:38:15 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-045.btinternet.com with ESMTP id <20200825083808.HLWA4112.sa-prd-fep-045.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344688; bh=L3j/8ZLx2LOTL6IaLpkY5WKc4iBNLyiGz8srqIFRtF4=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=aH0WwE0zTKvpadY1xOq7HU4TWRNOEL/luQPmC+FgCQwnLUvbS15GrZDHp2fZwJKxF8fQV2YAIaGXllJItHGeWmvAu4O77wWkYjYM8eEarlnNBspUuxa9GNrBDbo1iynhWaDSpv/lUDrqGyTh/l6y5gHgRCQ7oI9rWNOMuO4jR6PZPyNM3B2zhrKSEoOZR7TcLR1cJs6eUyh2C8sNMI39j3+UZ2Z4VuhOnDEEEVmMBvswTjRp2NmY49tO8QwerQcjW0w/XUcn1rtVp+eaxWHQaa3XyOX0Nyh/JCkoXVT6WDADE8diZkrAUGNPbuhqo2YsixaLW5xNKSPzdsrNVW6j2A== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeujeduvdejkeevtddtgfejiedtvefggfekgeehudetjeefffekteelgeefkeevieenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedutdelrdduheehrddufedtrdduiedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplhhotggrlhhhohhsthdrlhhotggrlhguohhmrghinhdpihhnvghtpedutdelrdduheehrddufedtrdduiedtpdhmrghilhhfrhhomhepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeophgruhhlsehprghulhdqmhhoohhrvgdrtghomheqpdhrtghpthhtohepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqecuqfftvefrvfeprhhftgekvddvnehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmpdhrtghpthhtohepoehsvghlihhnuhigsehvghgv rhdrkhgvrhhnvghlrdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599D9F; Tue, 25 Aug 2020 09:38:08 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 05/18] cil_overview: Convert to markdown Date: Tue, 25 Aug 2020 09:37:30 +0100 Message-Id: <20200825083743.6508-6-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Convert to markdown Signed-off-by: Richard Haines --- src/cil_overview.md | 63 ++++++++++++++++++++------------------------- 1 file changed, 28 insertions(+), 35 deletions(-) diff --git a/src/cil_overview.md b/src/cil_overview.md index aa22bff..ddb70f6 100644 --- a/src/cil_overview.md +++ b/src/cil_overview.md @@ -11,19 +11,17 @@ A PDF version is included in this documentation: The CIL compiler source can be found at: within the *secilc* and *libsepol* sections and can be cloned via: -- *git clone https://github.com/SELinuxProject/selinux.git* +- *git clone https://github.com/SELinuxProject/selinux.git* While the CIL design web pages give the main objectives of CIL, from a language perspective it will: -1. Apply name and usage consistency to the current kernel language - statements. For example the kernel language uses *attribute* and - *attribute_role* to declare identifiers, whereas CIL uses - *typeattribute* and *roleattribute*. Also statements to associate - types or roles have been made consistent and enhanced to allow - expressions to be defined. - -- Examples: +- Apply name and usage consistency to the current kernel language + statements. For example the kernel language uses *attribute* and + *attribute_role* to declare identifiers, whereas CIL uses + *typeattribute* and *roleattribute*. Also statements to associate + types or roles have been made consistent and enhanced to allow + expressions to be defined. Some examples are: | Kernel | CIL | | ---------------- | ------------------ | @@ -35,32 +33,27 @@ language perspective it will: | *allow* (role) | *roleallow* | | *dominance* | *sensitivityorder* | -2. Additional CIL statements have been defined to enhance - functionality: - -- *classpermission* - Declare a *classpermissionset* identifier. - -- *classpermissionset* - Associate class / permissions also supporting -expressions. - -- *classmap* / *classmapping* - Statements to support declaration and -association of multiple *classpermissionset*'s. Useful when defining an -*allow* rule with multiple class/permissions. - -- *context* - Statement to declare security context. - -3. Allow named and anonymous definitions to be supported. -4. Support namespace features allowing policy modules to be defined - within blocks with inheritance and template features. -5. Remove the order dependency in that policy statements can be - anywhere within the source (i.e. remove dependency of class, sid - etc. being within a base module). -6. Able to define macros and calls that will remove any dependency on - M4 macro support. -7. Directly generate the binary policy file and other configuration - files - currently the *file_contexts* file. -8. Support transformation services such as delete, transform and - inherit with exceptions. +- Additional CIL statements have been defined to enhance + functionality: + - *classpermission* - Declare a *classpermissionset* identifier. + - *classpermissionset* - Associate class / permissions also supporting + expressions. + - *classmap* / *classmapping* - Statements to support declaration and + association of multiple *classpermissionset*'s. Useful when defining an + *allow* rule with multiple class/permissions. + - *context* - Statement to declare security context. +- Allow named and anonymous definitions to be supported. +- Support namespace features allowing policy modules to be defined + within blocks with inheritance and template features. +- Remove the order dependency in that policy statements can be + anywhere within the source (i.e. remove dependency of class, sid + etc. being within a base module). +- Able to define macros and calls that will remove any dependency on + M4 macro support. +- Directly generate the binary policy file and other configuration + files - currently the *file_contexts* file. +- Support transformation services such as delete, transform and + inherit with exceptions. An simple CIL policy is as follows: From patchwork Tue Aug 25 08:37:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735169 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 4EBAD17D4 for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36A7B2075B for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="U/LoWXsF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728115AbgHYIiY (ORCPT ); Tue, 25 Aug 2020 04:38:24 -0400 Received: from mailomta10-sa.btinternet.com ([213.120.69.16]:21504 "EHLO sa-prd-fep-041.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728109AbgHYIiR (ORCPT ); Tue, 25 Aug 2020 04:38:17 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-041.btinternet.com with ESMTP id <20200825083809.MJXX19995.sa-prd-fep-041.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344689; bh=WAke2q5HIFSVAmCRcXhPKk31kmXXju7pzkqUUlE2JGw=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=U/LoWXsFkAFsBX2DDgsbbJnimt0AHQRdboMQcs+9smjOIyn12n/e/Cv5hDfrhfmhxu5DdjK8bCIrqZ5Uq3OZNyjejHBj8Ja7Zq6o8Kd5D/nXbaAlfQQeDna7LIgCF0hL+MntAPiCfWU9P5hu/jwZx88fAAXcI0KFBloYfT48DOHSziWkmFa33vhMF9CMZspWd2E2227OyLaFygZFomlyd+5FFJ9XRRI5LwuSNBn2T+ztQUD5sNQvtrAhjHHvsHEHsWe7GFbeeLh0cqIesrUtgqVHFnzBI92OdEPB8CfqoANHExOgouaI+VPqL25eqXoB2p4mgLs5p+6g4UmpTGzOlw== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599DAC; Tue, 25 Aug 2020 09:38:09 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 06/18] class_permission_statements: Convert to markdown Date: Tue, 25 Aug 2020 09:37:31 +0100 Message-Id: <20200825083743.6508-7-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/class_permission_statements.md | 231 ++++++++++++----------------- 1 file changed, 93 insertions(+), 138 deletions(-) diff --git a/src/class_permission_statements.md b/src/class_permission_statements.md index 4090fa0..b1ef36a 100644 --- a/src/class_permission_statements.md +++ b/src/class_permission_statements.md @@ -1,5 +1,10 @@ # Object Class and Permission Statements +- [*class* (1)](#class-1) + - [Associating Permissions to a Class](#associating-permissions-to-a-class) +- [*common*](#common) +- [*class* (2)](#class-2) + For those who write or manager SELinux policy, there is no need to define new objects and their associated permissions as these would be done by those who actually design and/or write object managers. @@ -9,14 +14,14 @@ in the *./policy/flask/security\_classes* file. There are two variants of the *class* statement for writing policy: -1. There is the *class* statement that declares the actual class - identifier or name. -2. There is a further refinement of the *class* statement that - associates permissions to the class as discussed in the - [**Associating Permissions to a Class**](#associating-permissions-to-a-class) - section. +1. There is the *class* statement that declares the actual class + identifier or name. +2. There is a further refinement of the *class* statement that + associates permissions to the class as discussed in the + [**Associating Permissions to a Class**](#associating-permissions-to-a-class) + section. -## *class* +## *class* (1) Object classes are declared within a policy with the following statement definition: @@ -27,45 +32,27 @@ class class_id **Where:** - - - - - - - - - - - -
classThe class keyword.
class_idThe class identifier.
+*class* + +The *class* keyword. + +*class_id* + +The *class* identifier. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoYes
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | Yes | **Example:** @@ -79,11 +66,11 @@ class db_tuple Permissions can be defined within policy in two ways: -1. Define a set of common permissions that can then be inherited by one - or more object classes using further *class* statements. -2. Define *class* specific permissions. This is where permissions are - declared for a specific object class only (i.e. the permission is - not inherited by any other object class). +1. Define a set of common permissions that can then be inherited by one + or more object classes using further *class* statements. +2. Define *class* specific permissions. This is where permissions are + declared for a specific object class only (i.e. the permission is + not inherited by any other object class). A list of classes and their permissions used by the **Reference Policy** can be found in the *./policy/flask/access_vectors* file. @@ -100,49 +87,32 @@ common common_id { perm_set } **Where:** - - - - - - - - - - - - - - - -
commonThe common keyword.
common_idThe common identifier.
perm_setOne or more permission identifiers in a space separated list enclosed within braces '{}'.
+*common* + +The *common* keyword. + +*common_id* + +The *common* identifier. + +*perm_set* + +One or more permission identifiers in a space separated list enclosed within +braces \'\{\}\'. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Example:** @@ -152,9 +122,10 @@ common common_id { perm_set } common database { create drop getattr setattr relabelfrom relabelto } ``` -## *class* +## *class* (2) -Inherit and / or associate permissions to a perviously declared *class* identifier. +Inherit and / or associate permissions to a perviously declared *class* +identifier. **The statement definition is:** @@ -164,60 +135,44 @@ class class_id [ inherits common_set ] [ { perm_set } ] **Where:** - - - - - - - - - - - - - - - - - - - - - - - -
classThe class keyword.
class_idThe previously declared class identifier.
inheritsThe optional inherits keyword that allows a set of common permissions to be inherited.
common_setA previously declared common identifier.
perm_setOne or more optional permission identifiers in a space separated list enclosed within braces '{}'.
+*class* + +The *class* keyword. + +*class_id* + +The previously declared *class* identifier. + +*inherits* + +The optional *inherits* keyword that allows a set of common permissions to be +inherited. + +*common_set* + +A previously declared *common* identifier. + +*perm_set* + +One or more optional permission identifiers in a space separated list enclosed +within braces \'\{\}\'. Note: There must be at least one *common_set* or one *perm_set* defined within the statement. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoYes
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | Yes | **Examples:** From patchwork Tue Aug 25 08:37:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735167 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 302691731 for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 177C520706 for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="L9oh5Ir0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728504AbgHYIiY (ORCPT ); Tue, 25 Aug 2020 04:38:24 -0400 Received: from mailomta5-sa.btinternet.com ([213.120.69.11]:37035 "EHLO sa-prd-fep-044.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728115AbgHYIiQ (ORCPT ); Tue, 25 Aug 2020 04:38:16 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-044.btinternet.com with ESMTP id <20200825083809.GKOE3440.sa-prd-fep-044.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344689; bh=dr9T7/JLpH7J3P0mRfUWnisH5zS+69UMofuRGXGw9aA=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=L9oh5Ir0o9yGq8Ls3opfLi2beIYOlH503B+ByYrEKK/+PnFENm/AShj6Mjzt9sUBUFBEk2n9kYGeX8hasSbVlGDU95Gf+cUIix9Ryk65tkvETpWMJBfFdFc8sBwwTN7Wag4Lwd7hrx+1IsilpJxlK4E2yVH8o2yfTc4AmZahzfQSdf8Xo+1toMHVqq7rqucoVvdOjaXpo43abH+nR3A74yVbPBWTu4lOPgiA93eoSKVu5vrErAeOEeXMM686vx/SI/sYXF4Q+JyuyI0P3l1daMW9gQ0+qX0G1IhG+8SaaUA6eVI4rCT3glkFMTjfsSuVW5zCRlUjOylU6gUxvgmrfA== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599DB6; Tue, 25 Aug 2020 09:38:09 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 07/18] computing_access_decisions: Convert to markdown Date: Tue, 25 Aug 2020 09:37:32 +0100 Message-Id: <20200825083743.6508-8-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Convert to markdown Signed-off-by: Richard Haines --- src/computing_access_decisions.md | 82 ++++++++++++++----------------- 1 file changed, 38 insertions(+), 44 deletions(-) diff --git a/src/computing_access_decisions.md b/src/computing_access_decisions.md index 5ab9430..0ab1092 100644 --- a/src/computing_access_decisions.md +++ b/src/computing_access_decisions.md @@ -3,50 +3,44 @@ There are a number of ways to compute access decisions within userspace SELinux-aware applications or object managers: -1. Use of the ***selinux_check_access**(3)* function is the - recommended option. This utilises the AVC services discussed in - bullet 3 in a single call that: - -- Dynamically resolves class and permissions strings to their - class/permission values using ***string_to_security_class**(3)* - and ***string_to_av_perm**(3)* with - ***security_deny_unknown**(3)* to handle unknown - classes/permissions. -- Uses ***avc_has_perm**(3)* to check whether the decision is cached - before calling ***security_compute_av_flags**(3)* (and caching - the result), checks enforcing mode (both global and per-domain - (permissive)), and logs any denials (there is also an option to add - supplemental auditing information that is handled as described in - ***avc_audit**(3)*. - -2. Use functions that do not cache access decisions (i.e. they do not - use the *libselinux* AVC services). These require a call to the - kernel for every decision using ***security_compute_av**(3)* or - ***security_compute_av_flags**(3)*. The ***avc_netlink_\***(3)* - functions can be used to detect policy change events. Auditing would - need to be implemented if required. - -3. Use functions that utilise the *libselinux* userspace AVC services - that are initialised with ***avc_open**(3)*. These can be built in - various configurations such as: - -- Using the default single threaded mode where ***avc_has_perm**(3)* - will automatically cache entries, audit the decision and manage - the handling of policy change events. - -- Implementing threads or a similar service that will handle policy - change events and auditing in real time with - ***avc_has_perm**(3)* or ***avc_has_perm_noaudit**(3)* - handling decisions and caching. This has the advantage of better - performance, which can be further increased by caching the entry - reference. - -4. Implement custom caching services with - ***security_compute_av**(3)* or - ***security_compute_av_flags**(3)* for computing access - decisions. The ***avc_netlink_\***(3)* functions can then be used to - detect policy change events. Auditing would need to be implemented - if required. +1. Use of the ***selinux_check_access**(3)* function is the + recommended option. This utilises the AVC services discussed in + bullet 3 in a single call that: + - Dynamically resolves class and permissions strings to their + class/permission values using ***string_to_security_class**(3)* + and ***string_to_av_perm**(3)* with + ***security_deny_unknown**(3)* to handle unknown + classes/permissions. + - Uses ***avc_has_perm**(3)* to check whether the decision is cached + before calling ***security_compute_av_flags**(3)* (and caching + the result), checks enforcing mode (both global and per-domain + (permissive)), and logs any denials (there is also an option to add + supplemental auditing information that is handled as described in + ***avc_audit**(3)*. +2. Use functions that do not cache access decisions (i.e. they do not + use the *libselinux* AVC services). These require a call to the + kernel for every decision using ***security_compute_av**(3)* or + ***security_compute_av_flags**(3)*. The ***avc_netlink_\***(3)* + functions can be used to detect policy change events. Auditing would + need to be implemented if required. +3. Use functions that utilise the *libselinux* userspace AVC services + that are initialised with ***avc_open**(3)*. These can be built in + various configurations such as: + - Using the default single threaded mode where ***avc_has_perm**(3)* + will automatically cache entries, audit the decision and manage + the handling of policy change events. + - Implementing threads or a similar service that will handle policy + change events and auditing in real time with + ***avc_has_perm**(3)* or ***avc_has_perm_noaudit**(3)* + handling decisions and caching. This has the advantage of better + performance, which can be further increased by caching the entry + reference. +4. Implement custom caching services with + ***security_compute_av**(3)* or + ***security_compute_av_flags**(3)* for computing access + decisions. The ***avc_netlink_\***(3)* functions can then be used to + detect policy change events. Auditing would need to be implemented + if required. Where performance is important when making policy decisions, then the ***selinux_status_open**(3)*, ***selinux_status_updated**(3)*, From patchwork Tue Aug 25 08:37:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735177 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 8949E1731 for ; Tue, 25 Aug 2020 08:38:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 65D2E2071E for ; Tue, 25 Aug 2020 08:38:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="JiciTYT6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728986AbgHYIiZ (ORCPT ); Tue, 25 Aug 2020 04:38:25 -0400 Received: from mailomta9-sa.btinternet.com ([213.120.69.15]:51235 "EHLO sa-prd-fep-049.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728145AbgHYIiU (ORCPT ); Tue, 25 Aug 2020 04:38:20 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-049.btinternet.com with ESMTP id <20200825083810.JHDK4195.sa-prd-fep-049.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344690; bh=rdfzeAhIXlReKS+I1/cNliu0vPNZfs6ItoLhaS6TReQ=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=JiciTYT6T+CX1DeLUXb6DHPqKpl7QTw1cQjQL9gT/CgwloqtOIlf1GWJ3ySxEFwUYnNrY9q/ajCa9RpMPc9IqVKrQVsa0GoUX4A3iM82TlQUJE5vQuceGY1KpOTZi2YM1pbLbnzlR8Ea803NJRYwo3UFk/Y5ZE7S9LBRJ/I4To9W6GdxjcnlZqSIciv7gz1lxxZRUSsTHSnquPrCXzdRzHeWK2y7JyJRGmVoA/H7nX3wNCPpr+HJQZegTHDih6hbdJcuhy66PaafiM7oILWUrgykZtnBtjIVFUScZWHEi6byGiVbk2d058YaQDg6k21mt7ZD3dupwJCvqmw0W60zCw== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599DD2; Tue, 25 Aug 2020 09:38:10 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 08/18] computing_security_contexts: Convert to markdown Date: Tue, 25 Aug 2020 09:37:33 +0100 Message-Id: <20200825083743.6508-9-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/computing_security_contexts.md | 662 +++++++++++++++-------------- 1 file changed, 346 insertions(+), 316 deletions(-) diff --git a/src/computing_security_contexts.md b/src/computing_security_contexts.md index 5849375..bb946b5 100644 --- a/src/computing_security_contexts.md +++ b/src/computing_security_contexts.md @@ -1,5 +1,22 @@ # Computing Security Contexts +- [Security Context Computation for Kernel Objects](#security-context-computation-for-kernel-objects) + - [Process](#process) + - [Files](#files) + - [File Descriptors](#file-descriptors) + - [Filesystems](#filesystems) + - [Network File System (nfsv4.2)](#network-file-system-nfsv4.2) + - [INET Sockets](#inet-sockets) + - [IPC](#ipc) + - [Message Queues](#message-queues) + - [Semaphores](#semaphores) + - [Shared Memory](#shared-memory) + - [Keys](#keys) +- [Using libselinux Functions](#using-libselinux-functions) + - [*avc_compute_create* and *security_compute_create*](#avc_compute_create-and-security_compute_create) + - [*avc_compute_member* and *security_compute_member*](#avc_compute_member-and-security_compute_member) + - [*security_compute_relabel*](#security_compute_relabel) + SELinux uses a number of policy language statements and *libselinux* functions to compute a security context via the kernel security server. @@ -15,9 +32,9 @@ components: a source context, a target context and an object class. The *libselinux* userspace functions used to compute a security context are: -- ***avc_compute_create**(3)* and ***security_compute_create**(3)* -- ***avc_compute_member**(3)* and ***security_compute_member**(3)* -- ***security_compute_relabel**(3)* +- ***avc_compute_create**(3)* and ***security_compute_create**(3)* +- ***avc_compute_member**(3)* and ***security_compute_member**(3)* +- ***security_compute_relabel**(3)* Note that these *libselinux* functions actually call the kernel equivalent functions in the security server (see kernel source @@ -53,24 +70,24 @@ The initial task starts with the kernel security context, but the (e.g. *init_t*) when the init binary is executed after the policy has been loaded. Some init programs re-exec themselves after loading policy, while in other cases the initial policy load is performed by the -*initrd*/*initramfs* script prior to mounting the real root and -executing the real init program. +*initrd*/*initramfs* script prior to mounting the real *root* and +executing the real *init* program. Processes inherit their security context as follows: -1. On fork a process inherits the security context of its - creator/parent. -2. On *exec*, a process may transition to another security context - based on policy statements: *type_transition*, *range_transition*, - *role_transition* (policy version 26), *default_user*, - *default_role*, *default_range* (policy versions 27) and - *default_type* (policy version 28) or if a security-aware process, - by calling ***setexeccon**(3)* if permitted by policy prior to - invoking exec. -3. At any time, a security-aware process may invoke ***setcon**(3)* to - switch its security context (if permitted by policy) although this - practice is generally discouraged - exec-based transitions are - preferred. +1. On fork a process inherits the security context of its + creator/parent. +2. On *exec*, a process may transition to another security context + based on policy statements: *type_transition*, *range_transition*, + *role_transition* (policy version 26), *default_user*, + *default_role*, *default_range* (policy versions 27) and + *default_type* (policy version 28) or if a security-aware process, + by calling ***setexeccon**(3)* if permitted by policy prior to + invoking exec. +3. At any time, a security-aware process may invoke ***setcon**(3)* to + switch its security context (if permitted by policy) although this + practice is generally discouraged - exec-based transitions are + preferred. ### Files @@ -79,23 +96,23 @@ the following classes: files, symbolic links, directories, socket files, fifo's and block/character) upon creation for any filesystem type that supports labeling is as follows: -1. The user component is inherited from the creating process (policy - version 27 allows a *default_user* of source or target to be - defined for each object class). -2. The role component generally defaults to the *object_r* role - (policy version 26 allows a *role_transition* and version 27 allows - a *default_role* of source or target to be defined for each object - class). -3. The type component defaults to the type of the parent directory if - no matching *type_transition* rule was specified in the policy - (policy version 25 allows a filename *type_transition* rule and - version 28 allows a *default_type* of source or target to be - defined for each object class). -4. The *range*/*level* component defaults to the low/current level of - the creating process if no matching *range_transition* rule was - specified in the policy (policy version 27 allows a *default_range* - of source or target with the selected range being low, high or - low-high to be defined for each object class). +1. The user component is inherited from the creating process (policy + version 27 allows a *default_user* of source or target to be + defined for each object class). +2. The role component generally defaults to the *object_r* role + (policy version 26 allows a *role_transition* and version 27 allows + a *default_role* of source or target to be defined for each object + class). +3. The type component defaults to the type of the parent directory if + no matching *type_transition* rule was specified in the policy + (policy version 25 allows a filename *type_transition* rule and + version 28 allows a *default_type* of source or target to be + defined for each object class). +4. The *range*/*level* component defaults to the low/current level of + the creating process if no matching *range_transition* rule was + specified in the policy (policy version 27 allows a *default_range* + of source or target with the selected range being low, high or + low-high to be defined for each object class). Security-aware applications can override this default behavior by calling ***setfscreatecon**(3)* prior to creating the file, if permitted @@ -116,7 +133,7 @@ Inherits the label of its creator/parent. ### Filesystems Filesystems are labeled using the appropriate *fs_use* kernel policy -language statement as they are mounted, they are based on the filesystem +language statement as they are mounted, they are based on the *filesystem* type name (e.g. *ext4*) and their behaviour (e.g. *xattr*). For example if the policy specifies the following: @@ -128,37 +145,37 @@ then as the *pipefs* filesystem is being mounted, the SELinux LSM security hook *selinux_set_mnt_opts* will call *security_fs_use* that will: -- Look for the filesystem name within the policy (*pipefs*) -- If present, obtain its behaviour (*fs_use_task*) -- Then obtain the allocated security context (*system_u:object_r:fs_t:s0*) +- Look for the filesystem name within the policy (*pipefs*) +- If present, obtain its behaviour (*fs_use_task*) +- Then obtain the allocated security context (*system_u:object_r:fs_t:s0*) Should the behaviour be defined as *fs_use_task*, then the filesystem will be labeled as follows: -1. The user component is inherited from the creating process (policy - version 27 allows a *default_user* of source or target to be - defined). -2. The role component generally defaults to the *object_r* role - (policy version 26 allows a *role_transition* and version 27 allows - a *default_role* of source or target to be defined). -3. The type component defaults to the type of the target type if no - matching *type_transition* rule was specified in the policy (policy - version 28 allows a *default_type* of source or target to be - defined). -4. The *range*/*level* component defaults to the low/current level of - the creating process if no matching *range_transition* rule was - specified in the policy (policy version 27 allows a *default_range* - of source or target with the selected range being low, high or - low-high to be defined). +1. The user component is inherited from the creating process (policy + version 27 allows a *default_user* of source or target to be + defined). +2. The role component generally defaults to the *object_r* role + (policy version 26 allows a *role_transition* and version 27 allows + a *default_role* of source or target to be defined). +3. The type component defaults to the type of the target type if no + matching *type_transition* rule was specified in the policy (policy + version 28 allows a *default_type* of source or target to be + defined). +4. The *range*/*level* component defaults to the low/current level of + the creating process if no matching *range_transition* rule was + specified in the policy (policy version 27 allows a *default_range* + of source or target with the selected range being *low*, *high* or + *low-high* to be defined). Notes: -1. Filesystems that support *xattr* extended attributes can be - identified via the mount command as there will be a '*seclabel*' - keyword present. -2. There are mount options for allocating various context types: - *context=*, *fscontext=*, *defcontext=* and *rootcontext=*. They are - fully described in the ***mount**(8)* man page. +1. Filesystems that support *xattr* extended attributes can be + identified via the mount command as there will be a '*seclabel*' + keyword present. +2. There are mount options for allocating various context types: + *context=*, *fscontext=*, *defcontext=* and *rootcontext=*. They are + fully described in the ***mount**(8)* man page. ### Network File System (nfsv4.2) @@ -171,22 +188,22 @@ section. If a socket is created by the ***socket**(3)* call they are labeled as follows: -1. The user component is inherited from the creating process (policy - version 27 allows a *default_user* of source or target to be - defined for each socket object class). -2. The role component is inherited from the creating process (policy - version 26 allows a *role_transition* and version 27 allows a - *default_role* of source or target to be defined for each socket - object class). -3. The type component is inherited from the creating process if no - matching *type_transition* rule was specified in the policy and - version 28 allows a *default_type* of source or target to be - defined for each socket object class). -4. The *range*/*level* component is inherited from the creating process - if no matching *range_transition* rule was specified in the policy - (policy version 27 allows a *default_range* of source or target - with the selected range being low, high or low-high to be defined - for each socket object class). +1. The user component is inherited from the creating process (policy + version 27 allows a *default_user* of source or target to be + defined for each socket object class). +2. The role component is inherited from the creating process (policy + version 26 allows a *role_transition* and version 27 allows a + *default_role* of source or target to be defined for each socket + object class). +3. The type component is inherited from the creating process if no + matching *type_transition* rule was specified in the policy and + version 28 allows a *default_type* of source or target to be + defined for each socket object class). +4. The *range*/*level* component is inherited from the creating process + if no matching *range_transition* rule was specified in the policy + (policy version 27 allows a *default_range* of source or target + with the selected range being *low*, *high* or *low-high* to be defined + for each socket object class). Security-aware applications may use ***setsockcreatecon**(3)* to explicitly label sockets they create if permitted by policy. @@ -208,22 +225,22 @@ Inherits the label of its sending process. However if sending a message that is unlabeled, compute a new label based on the current process and the message queue it will be stored in as follows: -1. The user component is inherited from the sending process (policy - version 27 allows a *default_user* of source or target to be - defined for the message object class). -2. The role component is inherited from the sending process (policy - version 26 allows a *role_transition* and version 27 allows a - *default_role* of source or target to be defined for the message - object class). -3. The type component is inherited from the sending process if no - matching *type_transition* rule was specified in the policy and - version 28 allows a *default_type* of source or target to be - defined for the message object class). -4. The *range*/*level* component is inherited from the sending process - if no matching *range_transition* rule was specified in the policy - (policy version 27 allows a *default_range* of source or target - with the selected range being low, high or low-high to be defined - for the message object class). +1. The user component is inherited from the sending process (policy + version 27 allows a *default_user* of source or target to be + defined for the message object class). +2. The role component is inherited from the sending process (policy + version 26 allows a *role_transition* and version 27 allows a + *default_role* of source or target to be defined for the message + object class). +3. The type component is inherited from the sending process if no + matching *type_transition* rule was specified in the policy and + version 28 allows a *default_type* of source or target to be + defined for the message object class). +4. The *range*/*level* component is inherited from the sending process + if no matching *range_transition* rule was specified in the policy + (policy version 27 allows a *default_range* of source or target + with the selected range being *low*, *high* or *low-high* to be defined + for the message object class). ### Semaphores @@ -244,249 +261,262 @@ explicitly label keys they create if permitted by policy. ### *avc_compute_create* and *security_compute_create* -**Table 1** below shows how the components from the source context +The table below shows how the components from the source context *scon*, target context *tcon* and class *tclass* are used to compute the new context *newcon* (referenced by SIDs for ***avc_compute_create**(3)*). The following notes also apply: -1. Any valid policy *role_transition*, *type_transition* and - *range_transition* enforcement rules will influence the final - outcome as shown. -2. For kernels less than 2.6.39 the context generated will depend on - whether the class is *process* or any other class. -3. For kernels 2.6.39 and above the following also applies: -- Those classes suffixed by *socket* will also be included in the *process* +1. Any valid policy [***role_transition***](role_statements.md#role_transition), + [***type_transition***](type_statements.md#type_transition) and + [***range_transition***](mls_statements.md#range_transition) enforcement + rules will influence the final outcome as shown. +2. For kernels less than 2.6.39 the context generated will depend on + whether the class is *process* or any other class. +3. For kernels 2.6.39 and above the following also applies: + - Those classes suffixed by *socket* will also be included in the *process* class outcome. -- If a valid *role_transition* rule for *tclass*, then use that - instead of the default *object_r*. Also requires policy version - 26 or greater - see ***security_policyvers**(3)*. -- If the *type_transition* rule is classed as the 'file name - transition rule' (i.e. it has an *object_name* parameter), then - provided the object name in the rule matches the last component of - the objects name (in this case a file or directory name), then use - the rules *default_type*. Also requires policy version 25 or greater. -4. For kernels 3.5 and above with policy version 27 or greater, the - *default_user*, *default_role*, *default_range* statements will - influence the *user*, *role* and *range* of the computed context for - the specified class *tclass*. With policy version 28 or greater the - *default_type* statement can also influence the *type* in the - computed context. - - - - - - - - - - - - - - - - -
userroletyperange

If kernel >= 3.5 with a default_user tclass target rule then use tcon user

-

ELSE

-

Use scon user

If kernel >=2.6.39, and there is a valid

-

role_transition

-

rule then use the rules new_role

-

OR

-

If kernel >= 3.5 with default_role tclass source rule then use scon role

-

OR

-

If kernel >= 3.5 with default_role tclass target rule then use tcon role

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon role

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon role

-

ELSE

-

Use object_r

If there is a valid

-

type_transition

-

rule then use the rules default_type

-

OR

-

If kernel >= 3.5 with default_type tclass source rule then use scon type

-

OR

-

If kernel >= 3.5 with default_type tclass target rule then use tcon type

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon type

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon type

-

ELSE

-

Use tcon type

If there is a valid

-

range_transition

-

rule then use the rules new_range

-

OR

-

If kernel >= 3.5 with default_range tclass source low rule then use scon low

-

OR

-

If kernel >= 3.5 with default_range tclass source high rule then use scon high

-

OR

-

If kernel >= 3.5 with default_range tclass source low_high rule then use scon range

-

OR

-

If kernel >= 3.5 with default_range tclass target low rule then use tcon low

-

OR

-

If kernel >= 3.5 with default_range tclass target high rule then use tcon high

-

OR

-

If kernel >= 3.5 with default_range tclass target low_high rule then use tcon range

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon range

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon range

-

ELSE

-

Use scon low

- -**Table 1** + - If a valid *role_transition* rule for *tclass*, then use that + instead of the default *object_r*. Also requires policy version + 26 or greater - see ***security_policyvers**(3)*. + - If the *type_transition* rule is classed as the 'file name + transition rule' (i.e. it has an *object_name* parameter), then + provided the object name in the rule matches the last component of + the objects name (in this case a file or directory name), then use + the rules *default_type*. Also requires policy version 25 or greater. +4. For kernels 3.5 and above with policy version 27 or greater, the + *default_user*, *default_role*, *default_range* statements will + influence the *user*, *role* and *range* of the computed context for + the specified class *tclass*. With policy version 28 or greater the + *default_type* statement can also influence the *type* in the + computed context. + +***Computing avc_compute_create(3) and security_compute_create(3) contexts***: + +- ***user*** + - IF kernel \>= 3.5 with a *default_user tclass target* rule then + use *tcon user* + - ELSE + - Use *scon user* +- ***role*** + - IF kernel \>=2.6.39, and there is a valid *role_transition* rule then + use the rules [***new_role***](role_statements.md#role_transition) + - OR + - IF kernel \>= 3.5 with *default_role tclass source* rule then use + *scon role* + - OR + - IF kernel \>= 3.5 with *default_role tclass target* rule then use + *tcon role* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket*, then + use *scon role* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon role* + - ELSE + - Use *object_r* +- ***type*** + - IF there is a valid *type_transition* rule then use the rules + [***default_type***](type_statements.md#type_transition) + - OR + - IF kernel \>= 3.5 with *default_type tclass source* rule then use + *scon type* + - OR + - IF kernel \>= 3.5 with *default_type tclass target* rule then use + *tcon type* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket* then + use *scon type* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon type* + - **ELSE** + - Use *tcon type* +- ***range*** + - IF there is a valid *range_transition* rule then use the rules + [***new_range***](mls_statements.md#range_transition) + - OR + - IF kernel \>= 3.5 with *default_range tclass source low* rule then + use *scon low* + - OR + - IF kernel \>= 3.5 with *default_range tclass source high* rule then + use *scon high* + - OR + - IF kernel \>= 3.5 with *default_range tclass source low_high* rule + then use *scon range* + - OR + - IF kernel \>= 3.5 with *default_range tclass target low* rule then + use *tcon low* + - OR + - IF kernel \>= 3.5 with *default_range tclass target high* rule then + use *tcon high* + - OR + - IF kernel \>= 3.5 with *default_range tclass target low_high* rule + then use *tcon range* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket* then + use *scon range* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon range* + - **ELSE** + - Use *scon low* ### *avc_compute_member* and *security_compute_member* -**Table 2** shows how the components from the source context, +The table below shows how the components from the source context, *scon* target context, *tcon* and class, *tclass* are used to compute the new context *newcon* (referenced by SIDs for ***avc_compute_member**(3)*). The following notes also apply: -1. Any valid policy *type_member* enforcement rules will influence the - final outcome as shown. -2. For kernels less than 2.6.39 the context generated will depend on - whether the class is *process* or any other class. -3. For kernels 2.6.39 and above, those classes suffixed by *socket* are - also included in the *process* class outcome. -4. For kernels 3.5 and above with policy version 28 or greater, the - *default_role*, *default_range* statements will influence the - *role* and *range* of the computed context for the specified class - *tclass*. With policy version 28 or greater the *default_type* - statement can also influence the *type* in the computed context. - - - - - - - - - - - - - - - - -
userroletyperange
Always uses tcon user

If kernel >= 3.5 with default_role tclass source rule then use scon role

-

OR

-

If kernel >= 3.5 with default_role tclass target rule then use tcon role

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon role

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon role

-

ELSE

-

Use object_r

If there is a valid

-

type_member

-

rule then use the rules member_type

-

OR

-

If kernel >= 3.5 with default_type tclass source rule then use scon type

-

OR

-

If kernel >= 3.5 with default_type tclass target rule then use tcon type

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon type

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon type

-

ELSE

-

Use tcon type

If kernel >= 3.5 with default_range tclass source low rule then use scon low

-

OR

-

If kernel >= 3.5 with default_range tclass source high rule then use scon high

-

OR

-

If kernel >= 3.5 with default_range tclass source low_high rule then use scon range

-

OR

-

If kernel >= 3.5 with default_range tclass target low rule then use tcon low

-

OR

-

If kernel >= 3.5 with default_range tclass target high rule then use tcon high

-

OR

-

If kernel >= 3.5 with default_range tclass target low_high rule then use tcon range

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon range

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon range

-

ELSE

-

Use scon low

- -**Table 2** +1. Any valid policy [***type_member***](type_statements.md#type_member) + enforcement rules will influence the final outcome as shown. +2. For kernels less than 2.6.39 the context generated will depend on + whether the class is *process* or any other class. +3. For kernels 2.6.39 and above, those classes suffixed by *socket* are + also included in the *process* class outcome. +4. For kernels 3.5 and above with policy version 28 or greater, the + *default_role*, *default_range* statements will influence the + *role* and *range* of the computed context for the specified class + *tclass*. With policy version 28 or greater the *default_type* + statement can also influence the *type* in the computed context. + +***Computing avc_compute_member(3) and security_compute_member(3) contexts:*** + +- ***user*** + - Always uses *tcon user* +- ***role*** + - IF kernel \>= 3.5 with *default_role tclass source* rule then use + *scon role* + - OR + - IF kernel \>= 3.5 with *default_role tclass target* rule then use + *tcon role* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket* then + use *scon role* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon role* + - ELSE + - Use *object_r* +- ***type*** + - IF there is a valid *type_member* rule then use the rules + [***member_type***](type_statements.md#type_member) + - OR + - IF kernel \>= 3.5 with *default_type tclass source* rule then use + *scon type* + - OR + - IF kernel \>= 3.5 with *default_type tclass target* rule then use + *tcon type* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket* then + use *scon type* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon type* + - ELSE + - Use *tcon type* +- ***range*** + - IF kernel \>= 3.5 with *default_range tclass source low* rule then + use *scon low* + - OR + - IF kernel \>= 3.5 with *default_range tclass source high* rule then + use *scon high* + - OR + - IF kernel \>= 3.5 with *default_range tclass source low_high* rule + then use *scon range* + - OR + - IF kernel \>= 3.5 with *default_range tclass target low* rule then + use *tcon low* + - OR + - IF kernel \>= 3.5 with *default_range tclass target high* rule then + use *tcon high* + - OR + - IF kernel \>= 3.5 with *default_range tclass target low_high* rule + then use *tcon range* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket* then + use *scon range* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon range* + - ELSE + - Use *scon low* ### *security_compute_relabel* -**Table 3** below shows how the components from the source context, +The table below shows how the components from the source context, *scon* target context, *tcon* and class, *tclass* are used to compute the new context *newcon* for ***security_compute_relabel**(3)*. The following notes also apply: -1. Any valid policy *type_change* enforcement rules will influence the - final outcome shown in the table. -2. For kernels less than 2.6.39 the context generated will depend on - whether the class is *process* or any other class. -3. For kernels 2.6.39 and above, those classes suffixed by *socket* - are also included in the *process* class outcome. -4. For kernels 3.5 and above with policy version 28 or greater, the - *default_user*, *default_role*, *default_range* statements will - influence the *user*, *role* and *range* of the computed context for - the specified class *tclass*. With policy version 28 or greater the - *default_type* statement can also influence the *type* in the - computed context. - - - - - - - - - - - - - - - - -
userroletyperange

If kernel >= 3.5 with a default_user tclass target rule then use tcon user

-

ELSE

-

Use scon user

If kernel >= 3.5 with default_role tclass source rule then use scon role

-

OR

-

If kernel >= 3.5 with default_role tclass target rule then use tcon role

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon role

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon role

-

ELSE

-

Use object_r

If there is a valid

-

type_change

-

rule then use the rules change_type

-

OR

-

If kernel >= 3.5 with default_type tclass source rule then use scon type

-

OR

-

If kernel >= 3.5 with default_type tclass target rule then use tcon type

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon type

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon type

-

ELSE

-

Use tcon type

If kernel >= 3.5 with default_range tclass source low rule then use scon low

-

OR

-

If kernel >= 3.5 with default_range tclass source high rule then use scon high

-

OR

-

If kernel >= 3.5 with default_range tclass source low_high rule then use scon range

-

OR

-

If kernel >= 3.5 with default_range tclass target low rule then use tcon low

-

OR

-

If kernel >= 3.5 with default_range tclass target high rule then use tcon high

-

OR

-

If kernel >= 3.5 with default_range tclass target low_high rule then use tcon range

-

OR

-

If kernel >= 2.6.39 and tclass is process or socket, then use scon range

-

OR

-

If kernel <= 2.6.38 and tclass is process, then use scon range

-

ELSE

-

Use scon low

- -**Table 3** +1. Any valid policy [***type_change***](type_statements.md#type_change) + enforcement rules will influence the final outcome shown in the table. +2. For kernels less than 2.6.39 the context generated will depend on + whether the class is *process* or any other class. +3. For kernels 2.6.39 and above, those classes suffixed by *socket* + are also included in the *process* class outcome. +4. For kernels 3.5 and above with policy version 28 or greater, the + *default_user*, *default_role*, *default_range* statements will + influence the *user*, *role* and *range* of the computed context for + the specified class *tclass*. With policy version 28 or greater the + *default_type* statement can also influence the *type* in the + computed context. + +***Computing security_compute_relabel(3) contexts:*** + +- ***user*** + - If kernel \>= 3.5 with a *default_user tclass target* rule then use + *tcon user* + - ELSE + - Use *scon user* +- ***role*** + - IF kernel \>= 3.5 with *default_role tclass source* rule then use + *scon role* + - OR + - IF kernel \>= 3.5 with *default_role tclass target* rule then use + *tcon role* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket* then use + *scon role* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon role* + - ELSE + - Use *object_r* +- ***type*** + - IF there is a valid *type_change* rule then use the rules + [***change_type***](type_statements.md#type_change) + - OR + - IF kernel \>= 3.5 with *default_type tclass source* rule then use + *scon type* + - OR + - IF kernel \>= 3.5 with *default_type tclass target* rule then use + *tcon type* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket* then use + *scon type* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon type* + - ELSE + - Use *tcon type* +- ***range*** + - IF kernel \>= 3.5 with *default_range tclass source low* rule then use + *scon low* + - OR + - IF kernel \>= 3.5 with *default_range tclass source high* rule then use + *scon high* + - OR + - IF kernel \>= 3.5 with *default_range tclass source low_high* rule then + use *scon range* + - OR + - IF kernel \>= 3.5 with *default_range tclass target low* rule then use + *tcon low* + - OR + - IF kernel \>= 3.5 with *default_range tclass target high* rule then use + *tcon high* + - OR + - IF kernel \>= 3.5 with *default_range tclass target low_high* rule then + use *tcon range* + - OR + - IF kernel \>= 2.6.39 and *tclass* is *process* or *\*socket* then use + *scon range* + - OR + - IF kernel \<= 2.6.38 and *tclass* is *process* then use *scon range* + - ELSE + - Use *scon low* From patchwork Tue Aug 25 08:37:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735163 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 E2F3D739 for ; Tue, 25 Aug 2020 08:38:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C6BEC2074D for ; Tue, 25 Aug 2020 08:38:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="Gx8qqybc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728543AbgHYIiV (ORCPT ); Tue, 25 Aug 2020 04:38:21 -0400 Received: from mailomta27-sa.btinternet.com ([213.120.69.33]:53158 "EHLO sa-prd-fep-043.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728504AbgHYIiQ (ORCPT ); Tue, 25 Aug 2020 04:38:16 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-043.btinternet.com with ESMTP id <20200825083810.MPKQ26847.sa-prd-fep-043.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344690; bh=rwUXWQzCJW6urkEMzOx9OdmAEPAgf2t+Upku6IVW1q8=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=Gx8qqybcJWmRI6KC2GoDhzyKx/k/HmnrUDvab/6JWvaJOgswdmSBT/hxHvSoKXkQP4XYEql0L8Fz6g0oNklbSAHTHQecuhlSdRS9nozZk6yy+mzv6f6Q0uSj+JH/kpQv/Y71HJ/tIe4amaA+mlrTq2bROAiuuabk3R0BQ1WYgniY689TEGHdB4zPvpuxQ+LjcqQTJRz6skkGeLQnhQg2C4DJ31z8Fr+GDxyJoVjmQGBsdEu54JVzwes2kWJlAQD8W/6Mq0obOIHIOmU2dNgcRhb2xhEW/flGAKsYudwMLucoY/7w46vfj+og66AOuakbxenxrTA2xj7tVNyp2eVLSQ== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfgggtgfesthekredtredtjeenucfhrhhomheptfhitghhrghrugcujfgrihhnvghsuceorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqnecuggftrfgrthhtvghrnhepgfekgffghffgleekgfellefftedvhfejveehhfekkefgvdehueetgfffffelkedtnecukfhppedutdelrdduheehrddufedtrdduiedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplhhotggrlhhhohhsthdrlhhotggrlhguohhmrghinhdpihhnvghtpedutdelrdduheehrddufedtrdduiedtpdhmrghilhhfrhhomhepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeophgruhhlsehprghulhdqmhhoohhrvgdrtghomheqpdhrtghpthhtohepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqecuqfftvefrvfeprhhftgekvddvnehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmpdhrtghpthhtohepoehsvghlihhnuhigsehvghgvrhdrkhgvrhhnvghlrdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599DE1; Tue, 25 Aug 2020 09:38:10 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 09/18] conditional_statements: Convert to markdown Date: Tue, 25 Aug 2020 09:37:34 +0100 Message-Id: <20200825083743.6508-10-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/conditional_statements.md | 159 ++++++++++++++-------------------- 1 file changed, 66 insertions(+), 93 deletions(-) diff --git a/src/conditional_statements.md b/src/conditional_statements.md index 3cf07df..4eeeec3 100644 --- a/src/conditional_statements.md +++ b/src/conditional_statements.md @@ -1,5 +1,8 @@ # Conditional Policy Statements +- [*if*](#if) +- [*bool*](#bool) + Conditional policies consist of a bool statement that defines a condition as *true* or *false*, with a supporting *if* / *else* construct that specifies what rules are valid under the condition as shown in the @@ -56,7 +59,7 @@ getsebool -a getsebool allow_daemons_use_tty ``` -## bool +## *bool* The *bool* statement is used to specify a boolean identifier and its initial state (*true* or *false*) that can then be used with the @@ -71,49 +74,31 @@ bool bool_id default_value; **Where:** - - - - - - - - - - - - - - - -
boolThe bool keyword.
bool_idThe boolean identifier.
default_valueEither true or false.
+*bool* + +The *bool* keyword. + +*bool_id* + +The boolean identifier. + +*default_value* + +Either true or false. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesYes
Conditional Policy if Statementoptional Statementrequire Statement
NoYesYes
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | Yes | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | Yes | Yes | **Examples:** @@ -133,7 +118,7 @@ bool allow_execheap false; bool allow_execstack true; ``` -### if +## *if* The if statement is used to form a 'conditional block' of statements and rules that are enforced depending on whether one or more boolean @@ -154,60 +139,48 @@ if (conditional_expression) { true_list } [ else { false_list } ] **Where:** - - - - - - - - - - - - - - - - - - - - - - - -
ifThe if keyword.
conditional_expression

One or more bool_name identifiers that have been previously defined by the bool Statement. Multiple identifiers must be separated by the following logical operators: &&, ¦¦, ^, !, ==, !=.

-

The conditional_expression is enclosed in brackets ().

true_list

A list of rules enclosed within braces '{}' that will be executed when the conditional_expression is 'true'.

-

Valid statements and rules are highlighted within each language definition statement.

elseOptional else keyword.
false_list

A list of rules enclosed within braces '{}' that will be executed when the optional else keyword is present and the conditional_expression is false.

-

Valid statements and rules are highlighted within each language definition statement.

+*if* + +The *if* keyword. + +*conditional_expression* + +One or more *bool_name* identifiers that have been previously defined by the +*bool* Statement. Multiple identifiers must be separated by the following +logical operators: &&, ¦¦, ^, !, ==, !=. +The *conditional_expression* is enclosed in brackets \'\(\)\'. + +*true_list* + +A list of rules enclosed within braces \'\{\}\' that will be executed when the +*conditional_expression* is 'true'. +Valid statements and rules are highlighted within each language definition +statement. + +*else* + +Optional *else* keyword. + +*false_list* + +A list of rules enclosed within braces \'\{\}\' that will be executed when the +optional *else* keyword is present and the *conditional_expression* is *false*. +Valid statements and rules are highlighted within each language definition +statement. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesYes
Conditional Policy if Statementoptional Statementrequire Statement
NoYesNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | Yes | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | Yes | No | **Examples:** From patchwork Tue Aug 25 08:37:35 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735165 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 1245B14F6 for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E8E9C2074D for ; Tue, 25 Aug 2020 08:38:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="REpx97+K" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728890AbgHYIiT (ORCPT ); Tue, 25 Aug 2020 04:38:19 -0400 Received: from mailomta11-sa.btinternet.com ([213.120.69.17]:34229 "EHLO sa-prd-fep-048.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728543AbgHYIiP (ORCPT ); Tue, 25 Aug 2020 04:38:15 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-048.btinternet.com with ESMTP id <20200825083810.LXZC4139.sa-prd-fep-048.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344690; bh=MscxKCRu5e6f/Y6erVfiJFdf4IKu1/9yRWC6PTtnlkY=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=REpx97+Kq8382H6mGf0iBIRFn8EzV1YcvdDVUQpLEIcVdz+eQOHjgvMnlDaXj7i77FLcMkNiv6+qlkGxjszlyINYpr7NQWs0lJLxzfbxlpyeLsfndcLwNIRd2AzcUrfins+iAyh/9WXtcdyCQ18qpXujG9CaG7jAPj7vnAt2S9P7BrObsIxdQECKA6wxffJirradIsd0ak2L/OdQlw/OQnnMIMoW6zjS4hwA1Td+iiT9dzSCizHhMAZrgtuVfRlcoyivdAL+6WCvcOBMeOvWVsLpGqWW8MhNJMOHgVXeW8zumV2ffm3hlTf/569IeNvx8sHqXXqn2/ifJwDWoXeeBw== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599DF2; Tue, 25 Aug 2020 09:38:10 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 10/18] configuration_files: Convert to markdown Date: Tue, 25 Aug 2020 09:37:35 +0100 Message-Id: <20200825083743.6508-11-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/configuration_files.md | 74 ++++++++++++++++++++------------------ 1 file changed, 39 insertions(+), 35 deletions(-) diff --git a/src/configuration_files.md b/src/configuration_files.md index 3515f1b..0d48d09 100644 --- a/src/configuration_files.md +++ b/src/configuration_files.md @@ -1,5 +1,9 @@ # SELinux Configuration Files +- [The Policy Store](#the-policy-store) + - [The priority Option](#the-priority-option) +- [Converting policy packages to CIL](#converting-policy-packages-to-cil) + This section explains each SELinux configuration file with its format, example content and where applicable, any supporting SELinux commands or **libselinux** library API functions. @@ -10,34 +14,34 @@ adding the man page section (e.g. ***semanage.config**(5)*). This Notebook classifies the types of configuration file used in SELinux as follows: -1. [**Global Configuration files**](global_config_files.md#global-configuration-files) that - affect the active policy and their supporting SELinux-aware - applications, utilities or commands. This Notebook will only refer - to the commonly used configuration files. -2. [**Policy Store Configuration Files**](policy_store_config_files.md#policy-store-configuration-files) - that are managed by the **semanage**(8) and **semodule**(8) commands. These - are used to build the majority of the - [Policy Configuration Files](policy_config_files.md#policy-configuration-files) - and should NOT be edited as together they describe the overall 'policy' configuration. -3. [**Policy Configuration Files**](policy_config_files.md) used by an active - (run time) policy/system. Note that there can be multiple policy - configurations on a system (e.g. */etc/selinux/targeted* and - */etc/selinux/mls*), however only one can be the active policy. -4. [**SELinux Filesystem files - Table 6: SELinux filesystem Information**](lsm_selinux.md#selinux-filesystem) located under the */sys/fs/selinux* - directory and reflect the current configuration of SELinux for the active - policy. This area is used - extensively by the libselinux library for userspace object managers and - other SELinux-aware applications. These files and directories should not - be updated by users (the majority are read only anyway), however - they can be read to check various configuration parameters and - viewing the currently loaded policy using tools such as - ***apol**(1)* (e.g. *apol /sys/fs/selinux/policy*). +1. [**Global Configuration files**](global_config_files.md#global-configuration-files) that + affect the active policy and their supporting SELinux-aware + applications, utilities or commands. This Notebook will only refer + to the commonly used configuration files. +2. [**Policy Store Configuration Files**](policy_store_config_files.md#policy-store-configuration-files) + that are managed by the **semanage**(8) and **semodule**(8) commands. These + are used to build the majority of the + [Policy Configuration Files](policy_config_files.md#policy-configuration-files) + and should NOT be edited as together they describe the overall 'policy' configuration. +3. [**Policy Configuration Files**](policy_config_files.md) used by an active + (run time) policy/system. Note that there can be multiple policy + configurations on a system (e.g. */etc/selinux/targeted* and + */etc/selinux/mls*), however only one can be the active policy. +4. [**SELinux Filesystem files - Table 6: SELinux filesystem Information**](lsm_selinux.md#selinux-filesystem) + located under the */sys/fs/selinux* directory and reflect the current + configuration of SELinux for the active policy. This area is used + extensively by the libselinux library for userspace object managers and + other SELinux-aware applications. These files and directories should not + be updated by users (the majority are read only anyway), however + they can be read to check various configuration parameters and + viewing the currently loaded policy using tools such as + ***apol**(1)* (e.g. *apol /sys/fs/selinux/policy*). ## The Policy Store Version 2.7 of *libsemanage*, *libsepol*, and *policycoreutils* had the -policy module store has moved from */etc/selinux/<SELINUXTYPE>/modules* -to */var/lib/selinux/<SELINUXTYPE>*. +policy module store has moved from */etc/selinux/\/modules* +to */var/lib/selinux/\*. This new infrastructure now makes it possible to build policies containing a mixture of Reference Policy modules, kernel policy language modules and @@ -83,12 +87,12 @@ int_gateway The ***semodule**(8)* command now has a number of new options, with the most significant being: -1. Setting module priorities (*-X | --priority*), this is discussed in - [The priority Option](#the-priority-option) section. -2. Listing modules (*--list-modules=full | standard*). The 'f*ull*' - option shows all the available modules with their priority and - policy format. The '*standard*' option will only show the highest - priority, enabled modules. +1. Setting module priorities (*-X | \-\-priority*), this is discussed in + [The priority Option](#the-priority-option) section. +2. Listing modules (*\-\-list-modules=full | standard*). The '*full*' + option shows all the available modules with their priority and + policy format. The '*standard*' option will only show the highest + priority, enabled modules. ### The priority Option @@ -105,7 +109,7 @@ semodule --priority 400 --install custom/apache.pp Both apache modules are installed in the policy store as 'apache', but only the custom apache module is included in the final kernel binary. -The distribution apache module is ignored. The *--list-modules* options +The distribution apache module is ignored. The *\-\-list-modules* options can be used to show these: ``` @@ -137,15 +141,15 @@ new distribution policy. This does require that policy managers adopt some kind of scheme for who uses what priority. No strict guidelines currently exist, however the -value used by the *semanage\_migrate\_store* script is *--priority 100* +value used by the *semanage\_migrate\_store* script is *\-\-priority 100* as this is assumed to be migrating a distribution. If a value is not -provided, *semodule* will use a default of *--priority 400* as it is +provided, *semodule* will use a default of *\-\-priority 400* as it is assumed to be a locally customised policy. When *semodule* builds a lower priority module when a higher priority is already available, the following message will be given: "*A higher -priority <name> module exists at priority <999> and will -override the module currently being installed at priority <111>*". +priority \ module exists at priority \<999\> and will +override the module currently being installed at priority \<111\>*". ## Converting policy packages to CIL From patchwork Tue Aug 25 08:37:36 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735181 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 1C3EF739 for ; Tue, 25 Aug 2020 08:38:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EBA932071E for ; Tue, 25 Aug 2020 08:38:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="CNCkUIho" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729184AbgHYIi0 (ORCPT ); Tue, 25 Aug 2020 04:38:26 -0400 Received: from mailomta26-sa.btinternet.com ([213.120.69.32]:46596 "EHLO sa-prd-fep-047.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728605AbgHYIiS (ORCPT ); Tue, 25 Aug 2020 04:38:18 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-047.btinternet.com with ESMTP id <20200825083811.VUFQ4609.sa-prd-fep-047.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344691; bh=XfI7YSDz9AOp789EAuW2cs4yNvVPVMWv3AJxxnNBuDM=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=CNCkUIhoa7mHCwXF7mmtH9A0ynLUiLL4v8R6HGTHtKmLlrYhxpDrAyqQIGi8UA/mg0Pk+ctkeRSZkDlfPhRA4hCBBpqWws16yFpn6xY63dwPjnZNlEV65LN2fC1+TRgvJRka+qKH8GQ9sqWmlksFxnWQ97Z/lFPZV0g7Nf+QR59dEcISXN4y1KcPQCp5HVvQpb5QZY3tWqxber+Qh8T+HRfDC8twSpjntvgSFOwX+d2c85bWmLSjkWmrvUpJzkVOf+mciB9r1ubfOp/fMhA4eKG6luq2kWUFkzf34id0Ltjy01APVhuaBbL72Iet3iIiZbqY8ewrCrveXDrX0TTffg== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599E2E; Tue, 25 Aug 2020 09:38:11 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 11/18] constraint_statements: Convert to markdown Date: Tue, 25 Aug 2020 09:37:36 +0100 Message-Id: <20200825083743.6508-12-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/constraint_statements.md | 562 ++++++++++++++++------------------- 1 file changed, 251 insertions(+), 311 deletions(-) diff --git a/src/constraint_statements.md b/src/constraint_statements.md index 4834f6b..4c9a621 100644 --- a/src/constraint_statements.md +++ b/src/constraint_statements.md @@ -1,93 +1,82 @@ # Constraint Statements +- [*constrain*](#constrain) +- [*validatetrans*](#validatetrans) +- [*mlsconstrain*](#mlsconstrain) +- [*mlsvalidatetrans*](#mlsvalidatetrans) + ## *constrain* -The constrain statement allows further restriction on permissions for +The *constrain* statement allows further restriction on permissions for the specified object classes by using boolean expressions covering: source and target types, roles and users as described in the examples. **The statement definition is:** ``` -constrain class perm_set expression; +constrain class perm_set expression | expr ...; ``` **Where:** - - - - - - - - - - - - - - - - - - - - - - - - - - - -
constrainThe constrain keyword.
classOne or more object classes. Multiple entries consist of a space separated list enclosed in braces '{}'.
perm_setOne or more permissions. Multiple entries consist of a space separated list enclosed in braces '{}'.
expressionThe boolean expression of the constraint that is defined as follows:

( expression : expression )

-

| not expression

-

| expression and expression

-

| expression or expression

-

| u1 op u2

-

| r1 role_op r2

-

| t1 op t2

-

| u1 op names

-

| u2 op names

-

| r1 op names

-

| r2 op names

-

| t1 op names

-

| t2 op names

Where:

-

u1, r1, t1 = Source user, role, type

-

u2, r2, t2 = Target user, role, type

-

and:

-

op : == | !=

-

role_op : == | != | eq | dom | domby | incomp

-

names : name | { name_list }

-

name_list : name | name_list name

+*constrain* + +The *constrain* keyword. + +*class* + +One or more object classes. Multiple entries consist of a space separated list +enclosed in braces \'\{\}\'. + +*perm_set* + +One or more permissions. Multiple entries consist of a space separated list +enclosed in braces \'\{\}\'. + +*expression* + +There must be one constraint *expression* or one or more *expr*'s. An +*expression* consists of '*operand operator operand*' as follows: + +- *( u1 op u2 )* +- *( r1 role_op r2 )* +- *( t1 op t2 )* +- *( u1 op names )* +- *( u2 op names )* +- *( r1 op names )* +- *( r2 op names )* +- *( t1 op names )* +- *( t2 op names )* +- Where: + - *u1*, *r1*, *t1* = Source *user*, *role*, *type* + - *u2*, *r2*, *t2* = Target *user*, *role*, *type* +- And: + - *op : == | !=* + - *role_op : == | != | eq | dom | domby | incomp* + - *names : name | { name_list }* + - *name_list : name | name_list name* + +*expr* + +Zero or more *expr*'s, the valid operators and syntax are: + +- *( not expression )* +- *( expression and expression )* +- *( expression or expression )* **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Examples:** @@ -174,12 +163,12 @@ constrain { dir file lnk_file sock_file fifo_file chr_file blk_file } { create r ## *validatetrans* -This statement is used to control the ability to change the objects -security context. +The *validatetrans* statement is used to control the ability to change the +objects security context. -The first context *u1.r1.t1* is the context before the transition, the -second context *u2.r2.t2* is the context after the transition, and the -third *u3.r3.t3* is the context of the process performing the transition. +The first context *u1:r1:t1* is the context before the transition, the +second context *u2:r2:t2* is the context after the transition, and the +third *u3:r3:t3* is the context of the process performing the transition. Note there are no *validatetrans* statements specified within the **Reference Policy** source. @@ -187,95 +176,78 @@ Note there are no *validatetrans* statements specified within the **The statement definition is:** ``` -validatetrans class expression; +validatetrans class expression | expr ...; ``` **Where:** - - - - - - - - - - - - - - - - - - - - - - - -
validatetransThe validatetrans keyword.
classOne or more file related object classes. Multiple entries consist of a space separated list enclosed in braces '{}'.
expressionThe boolean expression of the constraint that is defined as follows:

( expression : expression )

-

| not expression

-

| expression and expression

-

| expression or expression

-

| u1 op u2

-

| r1 role_op r2

-

| t1 op t2

-

| u1 op names

-

| u2 op names

-

| r1 op names

-

| r2 op names

-

| t1 op names

-

| t2 op names

-

| u3 op names

-

| r3 op names

-

| t3 op names

Where:

-

u1, r1, t1 = Old user, role, type

-

u2, r2, t2 = New user, role, type

-

u3, r3, t3 = Process user, role, type

-

and:

-

op : == | !=

-

role_op : == | != | eq | dom | domby | incomp

-

names : name | { name_list }

-

name_list : name | name_list name

+*validatetrans* + +The *validatetrans* keyword. + +*class* + +One or more object classes. Multiple entries consist of a space separated list +enclosed in braces \'\{\}\'. + +*expression* + +There must be one constraint *expression* or one or more *expr*'s. An +*expression* consists of '*operand operator operand*' as follows: + +- *( u1 op u2 )* +- *( r1 role_op r2 )* +- *( t1 op t2 )* +- *( u1 op names )* +- *( u2 op names )* +- *( u3 op names )* +- *( r1 op names )* +- *( r2 op names )* +- *( r3 op names )* +- *( t1 op names )* +- *( t2 op names )* +- *( t3 op names )* +- Where: + - *u1*, *r1*, *t1* = Source *user*, *role*, *type* + - *u2*, *r2*, *t2* = Target *user*, *role*, *type* + - *u3*, *r3*, *t3* = Process *user*, *role*, *type* +- And: + - *op : == | !=* + - *role_op : == | != | eq | dom | domby | incomp* + - *names : name | { name_list }* + - *name_list : name | name_list name* + +*expr* + +Zero or more *expr*'s, the valid operators and syntax are: + +- *( not expression )* +- *( expression and expression )* +- *( expression or expression )* **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Example:** ``` -validatetrans { file } { t1 == unconfined_t ); +validatetrans { file } ( t1 == unconfined_t ); ``` ## *mlsconstrain* -The mlsconstrain statement allows further restriction on permissions for +The *mlsconstrain* statement allows further restriction on permissions for the specified object classes by using boolean expressions covering: source and target types, roles, users and security levels as described in the examples. @@ -283,91 +255,75 @@ in the examples. **The statement definition is:** ``` -mlsconstrain class perm_set expression; +mlsconstrain class perm_set expression | expr ...; ``` **Where:** - - - - - - - - - - - - - - - - - - - - - - - - - - - -
mlsconstrainThe mlsconstrain keyword.
classOne or more object classes. Multiple entries consist of a space separated list enclosed in braces '{}'.
perm_setOne or more permissions. Multiple entries consist of a space separated list enclosed in braces '{}'.
expressionThe boolean expression of the constraint that is defined as follows:

( expression : expression )

-

| not expression

-

| expression and expression

-

| expression or expression

-

| u1 op u2

-

| r1 role_mls_op r2

-

| t1 op t2

-

| l1 role_mls_op l2

-

| l1 role_mls_op h2

-

| h1 role_mls_op l2

-

| h1 role_mls_op h2

-

| l1 role_mls_op h1

-

| l2 role_mls_op h2

-

| u1 op names

-

| u2 op names

-

| r1 op names

-

| r2 op names

-

| t1 op names

-

| t2 op names

Where:

-

u1, r1, t1, l1, h1 = Source user, role, type, low level, high level

-

u2, r2, t2, l2, h2 = Target user, role, type, low level, high level

-

and:

-

op : == | !=

-

role_mls_op : == | != | eq | dom | domby | incomp

-

names : name | { name_list }

-

name_list : name | name_list name

+*mlsconstrain* + +The *mlsconstrain* keyword. + +*class* + +One or more object classes. Multiple entries consist of a space separated +list enclosed in braces \'\{\}\'. + +*perm_set* + +One or more permissions. Multiple entries consist of a space separated +list enclosed in braces \'\{\}\'. + +*expression* + +There must be one constraint *expression* or one or more *expr*'s. An +*expression* consists of '*operand operator operand*' as follows: + +- *( u1 op u2 )* +- *( r1 role_mls_op r2 )* +- *( t1 op t2 )* +- *( l1 role_mls_op l2 )* +- *( l1 role_mls_op h2 )* +- *( h1 role_mls_op l2 )* +- *( h1 role_mls_op h2 )* +- *( l1 role_mls_op h1 )* +- *( l2 role_mls_op h2 )* +- *( u1 op names )* +- *( u2 op names )* +- *( r1 op names )* +- *( r2 op names )* +- *( t1 op names )* +- *( t2 op names )* +- Where: + - *u1*, *r1*, *t1*, *l1*, *h1* = Source *user*, *role*, *type*, *low*, *high* + - *u2*, *r2*, *t2*, *l2*, *h2* = Target *user*, *role*, *type*, *low*, *high* +- And: + - *op : == | !=* + - *role_mls_op : == | != | eq | dom | domby | incomp* + - *names : name | { name_list }* + - *name_list : name | name_list name* + +*expr* + +Zero or more *expr*'s, the valid operators and syntax are: + +- *( not expression )* +- *( expression and expression )* +- *( expression or expression )* **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Example:** @@ -404,98 +360,82 @@ The *mlsvalidatetrans* is the MLS equivalent of the *validatetrans* statement where it is used to control the ability to change the objects security context. -The first context *u1.r1.t1* is the context before the transition, the -second context *u2.r2.t2* is the context after the transition, and the -third *u3.r3.t3* is the context of the process performing the transition. +The first context *u1:r1:t1:l1-h1* is the context before the transition, the +second context *u2:r2:t2:l2-h2* is the context after the transition, and the +third *u3:r3:t3:*\[*range*\] is the context of the process performing the +transition. **The statement definition is:** ``` -mlsvalidatetrans class expression; +mlsvalidatetrans class expression | expr ...; ``` **Where:** - - - - - - - - - - - - - - - - - - - - - - - -
mlsvalidatetransThe mlsvalidatetrans keyword.
classOne or more file type object classes. Multiple entries consist of a space separated list enclosed in braces '{}'.
expressionThe boolean expression of the constraint that is defined as follows:

( expression : expression )

-

| not expression

-

| and (expression and expression

-

| or expression or expression

-

| u1 op u2

-

| r1 role_mls_op r2

-

| t1 op t2

-

| l1 role_mls_op l2

-

| l1 role_mls_op h2

-

| h1 role_mls_op l2

-

| h1 role_mls_op h2

-

| l1 role_mls_op h1

-

| l2 role_mls_op h2

-

| u1 op names

-

| u2 op names

-

| r1 op names

-

| r2 op names

-

| t1 op names

-

| t2 op names

-

| u3 op names

-

| r3 op names

-

| t3 op names

Where:

-

u1, r1, t1, l1, h1 = Old user, role, type, low level, high level

-

u2, r2, t2, l2, h2 = New user, role, type, low level, high level

-

u3, r3, t3, l3, h3 = Process user, role, type, low level, high level

-

and:

-

op : == | !=

-

role_mls_op : == | != | eq | dom | domby | incomp

-

names : name | { name_list }

-

name_list : name | name_list name

+*mlsvalidatetrans* + +The *mlsvalidatetrans* keyword. + +*class* + +One or more object classes. Multiple entries consist of a space separated list +enclosed in braces \'\{\}\'. + +*expression* + +There must be one constraint *expression* or one or more *expr*'s. An +*expression* consists of '*operand operator operand*' as follows: + +- *( u1 op u2 )* +- *( r1 role_mls_op r2 )* +- *( t1 op t2 )* +- *( l1 role_mls_op l2 )* +- *( l1 role_mls_op h2 )* +- *( h1 role_mls_op l2 )* +- *( h1 role_mls_op h2 )* +- *( l1 role_mls_op h1 )* +- *( l2 role_mls_op h2 )* +- *( u1 op names )* +- *( u2 op names )* +- *( u3 op names )* +- *( r1 op names )* +- *( r2 op names )* +- *( r3 op names )* +- *( t1 op names )* +- *( t2 op names )* +- *( t3 op names )* +- Where: + - *u1*, *r1*, *t1*, *l1*, *h1* = Source *user*, *role*, *type*, *low*, *high* + - *u2*, *r2*, *t2*, *l2*, *h2* = Target *user*, *role*, *type*, *low*, *high* + - *u3*, *r3*, *t3*, \[*range*\] = Process *user*, *role*, *type*, \[*range*\] +- And: + - *op : == | !=* + - *role_mls_op : == | != | eq | dom | domby | incomp* + - *names : name | { name_list }* + - *name_list : name | name_list name* + +*expr* + +Zero or more *expr*'s, the valid operators and syntax are: + +- *( not expression )* +- *( expression and expression )* +- *( expression or expression )* **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Example:** From patchwork Tue Aug 25 08:37:37 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735183 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 8E7041731 for ; Tue, 25 Aug 2020 08:38:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6E7B22071E for ; Tue, 25 Aug 2020 08:38:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="ZVKfOOMJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728605AbgHYIi1 (ORCPT ); Tue, 25 Aug 2020 04:38:27 -0400 Received: from mailomta12-sa.btinternet.com ([213.120.69.18]:35296 "EHLO sa-prd-fep-047.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728873AbgHYIiR (ORCPT ); Tue, 25 Aug 2020 04:38:17 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-047.btinternet.com with ESMTP id <20200825083811.VUFS4609.sa-prd-fep-047.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344691; bh=smUIFAcgfgCcaohr4VEO5dUM7n+qDg7USg195rx+kqc=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=ZVKfOOMJQcctAr/W7yHWe9mv3YH5rosudMU/N4NeWz5X5FW9SDjRWoYwzhiZk2PLrgsJeqw3KaVcRKrkBwYZYyPn4LHrL0VkHMa2oQUB0oUlYypCfzuaohoLMeSGYL2bOqzZCfuDccGXfJ66Z7uyNmGHMxlO+6N8Iszz1tnzRRWE67VUAqIbuv3ymZAE2iImEmcIgVkOU8Ob7t7b3SYDteLKVYklcrgrC5jZn1C7NydkVHU4Ml6W7YVZU85o8nB/CLUVqETXCzXpa4sSfOl7bepnqxmf6HPuJ3ZbX5cMQXLfSQlvTLeIhXH8NeRrgmRFKjLdB6swQQ9TklnFgx+STw== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfgggtgfesthekredtredtjeenucfhrhhomheptfhitghhrghrugcujfgrihhnvghsuceorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqnecuggftrfgrthhtvghrnhepvdejfeehfeduhfevjeehheejkefgvdekvdegueelffdtkeeghfekveduveffieevnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhg vghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599E3C; Tue, 25 Aug 2020 09:38:11 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 12/18] core_components: Convert to markdown Date: Tue, 25 Aug 2020 09:37:37 +0100 Message-Id: <20200825083743.6508-13-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Convert to markdown Signed-off-by: Richard Haines --- src/core_components.md | 211 +++++++++++++++++++---------------------- 1 file changed, 99 insertions(+), 112 deletions(-) diff --git a/src/core_components.md b/src/core_components.md index 0bb9058..eeb1945 100644 --- a/src/core_components.md +++ b/src/core_components.md @@ -3,19 +3,19 @@ **Figure 1** shows a high level diagram of the SELinux core components that manage enforcement of the policy and comprise of the following: -1. A [**Subjects**](subjects.md#subjects) that must be present to cause an action - to be taken by an [**Objects**](objects.md#objects) (such as read a file as - information only flows when a subject is involved). -2. An Object Manager that knows the actions required of the particular - resource (such as a file) and can enforce those actions (i.e. allow - it to write to a file if permitted by the policy). -3. A Security Server that makes decisions regarding the subjects rights - to perform the requested action on the object, based on the security - policy rules. -4. A Security Policy that describes the rules using the SELinux - [**Kernel Policy Language**](kernel_policy_language.md#kernel-policy-language)). -5. An Access Vector Cache (AVC) that improves system performance by - caching security server decisions. +1. A [**Subject**](subjects.md#subjects) that must be present to cause an action + to be taken by an [**Object**](objects.md#objects) (such as read a file as + information only flows when a subject is involved). +2. An Object Manager that knows the actions required of the particular + resource (such as a file) and can enforce those actions (i.e. allow + it to write to a file if permitted by the policy). +3. A Security Server that makes decisions regarding the subjects rights + to perform the requested action on the object, based on the security + policy rules. +4. A Security Policy that describes the rules using the SELinux + [**Kernel Policy Language**](kernel_policy_language.md#kernel-policy-language)). +5. An Access Vector Cache (AVC) that improves system performance by + caching security server decisions. ![](./images/1-core.png) @@ -33,113 +33,100 @@ supporting services that are used to manage the SELinux environment. This diagram will be referenced a number of times to explain areas of SELinux, therefore starting from the bottom: -1. In the current implementation of SELinux the security server is - embedded in the kernel with the policy being loaded from userspace via a - series of functions contained in the **libselinux** library (see - [**SELinux Userspace Libraries**](userspace_libraries.md#selinux-userspace-libraries) for details). - - The object managers (OM) and access vector cache (AVC) can reside in: - -- **kernel space** - These object manages are for the kernel services such -as files, directory, socket, IPC etc. and are provided by hooks into the -SELinux sub-system via the Linux Security Module (LSM) framework (shown -as LSM Hooks in ) that is discussed in the -[**Linux Security Module and SELinux**](lsm_selinux.md#linux-security-module-and-selinux) - section. The SELinux kernel AVC service is used to cache the security servers -response to the kernel based object managers thus speeding up access decisions -should the same request be asked in future. - -- **userspace** - These object managers are provided with the application - or service that requires support for MAC and are known as - 'SELinux-aware' applications or services. Examples of these are: - X-Windows, D-bus messaging (used by the Gnome desktop), PostgreSQL - database, Name Service Cache Daemon (*nscd*), and the GNU / Linux passwd - command. Generally, these OMs use the AVC services built into the - SELinux library (libselinux), however they could, if required supply - their own AVC or not use an AVC at all (see - [**Implementing SELinux-aware Applications**](implementing_seaware_apps.md#implementing-selinux-aware-applications) for details). - -2. The SELinux security policy (right hand side of **Figure 2**) and its -supporting configuration files are contained in the /etc/selinux directory. -This directory contains the main SELinux configuration file *config* that has -the name of the policy to be loaded (via the *SELINUXTYPE* entry) and the initial -enforcement mode1 -of the policy at load time (via the *SELINUX* entry). -The /etc/selinux/*<SELINUXTYPE>* directories -contain policies that can be activated along with their configuration -files (e.g. '*SELINUXTYPE=targeted*' will have its policy and associated -configuration files located at */etc/selinux/targeted*). All known -configuration files are shown in the -[**SELinux Configuration Files**](configuration_files.md#selinux-configuration-files) -sections. - -3. SELinux supports a 'modular policy', this means that a policy does not -have to be one large source policy but can be built from modules. A -modular policy consists of a base policy that contains the mandatory -information (such as object classes, permissions etc.), and zero or more -policy modules where generally each supports a particular application or -service. These modules are compiled, linked, and held in a 'policy -store' where they can be built into a binary format that is then loaded -into the security server (in the diagram the binary policy is located at -*/etc/selinux/targeted/policy/policy.30*). The types of policy and their -construction are covered in the -[**Types of SELinux Policy**](types_of_policy.md#types-of-selinux-policy) -section. - -4. To be able to build the policy in the first place, policy source is -required (top left hand side of **Figure 2**). This can be supplied in three -basic ways: - -- as source code written using the -[**Kernel Policy Language**](kernel_policy_language.md#kernel-policy-language), -however it is not recommended for large policy developments. -- using the **Reference Policy** that has high -level macros to define policy rules. This is the standard way -policies are now built for SELinux distributions such as Red Hat -and Debian and is discussed in the -[**The Reference Policy**](reference_policy.md#the-reference-policy) -section. Note that SE for Android also uses high level macros to define -policy rules. -- using CIL (Common Intermediate Language). An overview can be found -in the [**CIL Policy Language**](cil_overview.md#cil-overview) -section. The is a good example. - +1. In the current implementation of SELinux the security server is + embedded in the kernel with the policy being loaded from userspace via a + series of functions contained in the **libselinux** library (see + [**SELinux Userspace Libraries**](userspace_libraries.md#selinux-userspace-libraries) + for details). The object managers (OM) and access vector cache (AVC) can + reside in: + - **kernel space** - These object manages are for the kernel services such + as files, directory, socket, IPC etc. and are provided by hooks into the + SELinux sub-system via the Linux Security Module (LSM) framework (shown + as LSM Hooks in ) that is discussed in the + [**Linux Security Module and SELinux**](lsm_selinux.md#linux-security-module-and-selinux) + section. The SELinux kernel AVC service is used to cache the security + servers response to the kernel based object managers thus speeding up + access decisions should the same request be asked in future. + - **userspace** - These object managers are provided with the application + or service that requires support for MAC and are known as + 'SELinux-aware' applications or services. Examples of these are: + X-Windows, D-bus messaging (used by the Gnome desktop), PostgreSQL + database, Name Service Cache Daemon (*nscd*), and the GNU / Linux passwd + command. Generally, these OMs use the AVC services built into the + SELinux library (libselinux), however they could, if required supply + their own AVC or not use an AVC at all (see + [**Implementing SELinux-aware Applications**](implementing_seaware_apps.md#implementing-selinux-aware-applications) + for details). +2. The SELinux security policy (right hand side of **Figure 2**) and its + supporting configuration files are contained in the /etc/selinux directory. + This directory contains the main SELinux configuration file *config* that has + the name of the policy to be loaded (via the *SELINUXTYPE* entry) and the + initial enforcement mode[^fn_cc_1] of the policy at load time (via the + *SELINUX* entry). The */etc/selinux/\* directories contain + policies that can be activated along with their configuration files (e.g. + '*SELINUXTYPE=targeted*' will have its policy and associated configuration + files located at */etc/selinux/targeted*). All known configuration files are + shown in the + [**SELinux Configuration Files**](configuration_files.md#selinux-configuration-files) + sections. +3. SELinux supports a 'modular policy', this means that a policy does not + have to be one large source policy but can be built from modules. A + modular policy consists of a base policy that contains the mandatory + information (such as object classes, permissions etc.), and zero or more + policy modules where generally each supports a particular application or + service. These modules are compiled, linked, and held in a 'policy + store' where they can be built into a binary format that is then loaded + into the security server (in the diagram the binary policy is located at + */etc/selinux/targeted/policy/policy.30*). The types of policy and their + construction are covered in the + [**Types of SELinux Policy**](types_of_policy.md#types-of-selinux-policy) + section. +4. To be able to build the policy in the first place, policy source is + required (top left hand side of **Figure 2**). This can be supplied in three + basic ways: + 1. as source code written using the + [**Kernel Policy Language**](kernel_policy_language.md#kernel-policy-language), + however it is not recommended for large policy developments. + 2. using the **Reference Policy** that has high + level macros to define policy rules. This is the standard way + policies are now built for SELinux distributions such as Red Hat + and Debian and is discussed in the + [**The Reference Policy**](reference_policy.md#the-reference-policy) + section. Note that SE for Android also uses high level macros to define + policy rules. + 3. using CIL (Common Intermediate Language). An overview can be found + in the [**CIL Policy Language**](cil_overview.md#cil-overview) + section. The is a good example. 5. To be able to compile and link the policy source then load it into the -security server requires a number of tools (top of **Figure 2**). - -6. To enable system administrators to manage policy, the SELinux -environment and label file systems, tools and modified GNU / Linux -commands are used. These are mentioned throughout the Notebook as needed -and summarised in -[**SELinux Commands**](selinux_cmds.md#appendix-c---selinux-commands). -Note that there are many other applications to manage policy, however this -Notebook only concentrates on the core services. - -7. To ensure security events are logged, GNU / Linux has an audit service -that captures policy violations. The -[**Auditing Events**](auditing.md#auditing-selinux-events) -section describes the format of these security events. - -8. SELinux supports network services that are described in the -[**SELinux Networking Support**](network_support.md#selinux-networking-support) -section. + security server requires a number of tools (top of **Figure 2**). +6. To enable system administrators to manage policy, the SELinux + environment and label file systems, tools and modified GNU / Linux + commands are used. These are mentioned throughout the Notebook as needed + and summarised in + [**SELinux Commands**](selinux_cmds.md#appendix-c---selinux-commands). + Note that there are many other applications to manage policy, however this + Notebook only concentrates on the core services. +7. To ensure security events are logged, GNU / Linux has an audit service + that captures policy violations. The + [**Auditing Events**](auditing.md#auditing-selinux-events) + section describes the format of these security events. +8. SELinux supports network services that are described in the + [**SELinux Networking Support**](network_support.md#selinux-networking-support) + section. The [**Linux Security Module and SELinux**](lsm_selinux.md#linux-security-module-and-selinux) section goes into greater detail of the LSM / SELinux modules with a walk through of a ***fork**(2)* and ***exec**(2)* process. -
-
    -

  1. When SELinux is enabled, the policy can be running in 'permissive mode' (SELINUX=permissive), where all accesses are allowed. The policy -can also be run in 'enforcing mode' (SELINUX=enforcing), where any +[^fn_cc_1]: When SELinux is enabled, the policy can be running in +'permissive mode' (*SELINUX=permissive*), where all accesses are allowed. +The policy can also be run in 'enforcing mode' (*SELINUX=enforcing*), where any access that is not defined in the policy is denied and an entry placed in the audit log. SELinux can also be disabled (at boot time only) by -setting SELINUX=disabled. There is also support for the -permissive -statement that allows a domain to run in permissive mode while the others are still confined -(instead of the all or nothing set by SELINUX=).↩

    2. -
-
+setting *SELINUX=disabled*. There is also support for the +[***permissive***](type_statements.md#permissive) statement that allows a +domain to run in permissive mode while the others are still confined +(instead of all or nothing set by *SELINUX=*). From patchwork Tue Aug 25 08:37:38 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735161 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 4FA3E14F6 for ; Tue, 25 Aug 2020 08:38:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 300AD2071E for ; Tue, 25 Aug 2020 08:38:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="S4oxa02S" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725936AbgHYIiS (ORCPT ); Tue, 25 Aug 2020 04:38:18 -0400 Received: from mailomta10-sa.btinternet.com ([213.120.69.16]:46270 "EHLO sa-prd-fep-047.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728890AbgHYIiQ (ORCPT ); Tue, 25 Aug 2020 04:38:16 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-047.btinternet.com with ESMTP id <20200825083812.VUFU4609.sa-prd-fep-047.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344692; bh=sxT9hoY/sJl5Qz9DRDnuzmbh1B6Uo+Wz1qgs0NSCirM=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=S4oxa02Smhi8r+/k5KCjY5nlW50sVCTtwVN2ZviIOy6lLtu19G+bK3db550Bk8lPxghjPQWN0EQxp7kQLPCRLl3FK+L1eNdLHf3Q7AYrtvBgdPa2aQWI17ZrB//2VZ78B10wR3UXczklLhWbMOdR7mrWJ60WLgSaWiBEgOz0T7hrF1217FObYPlZKVoAn33W6P2hL6iakdctEDO3IT4TEpDUaVMmmf4L2fex2/3y1EJA7Mug8aMzZ7+E30BhhqUjCao6VGDTz3uQgwIogXwrE3LH+TBnAzaAN4inWXWT4SDHoT07IOgMtIET1alCknSBznfzYl80hyYKMwgeApVcaw== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599E4D; Tue, 25 Aug 2020 09:38:12 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 13/18] default_rules: Convert to markdown Date: Tue, 25 Aug 2020 09:37:38 +0100 Message-Id: <20200825083743.6508-14-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/default_rules.md | 293 ++++++++++++++++++------------------------- 1 file changed, 119 insertions(+), 174 deletions(-) diff --git a/src/default_rules.md b/src/default_rules.md index 92ba272..e0d11e8 100644 --- a/src/default_rules.md +++ b/src/default_rules.md @@ -1,8 +1,14 @@ # Default Object Rules +- [*default_user*](#default_user) +- [*default_role*](#default_role) +- [*default_type*](#default_type) +- [*default_range*](#default_range) + These rules allow a default user, role, type and/or range to be used when computing a context for a new object. These require policy version -27 or 28 with kernels 3.5 or greater. +27 or 28 with kernels 3.5 or greater, for *glblub* support version 32 with +kernel 5.5 is required. ## *default_user* @@ -18,50 +24,34 @@ default_user class default; **Where:** - - - - - - - - - - - - - - - -
default_userThe default_user rule keyword.

class

One or more class identifiers. Multiple entries consist of a space separated list enclosed in braces '{}'.

-

Entries can be excluded from the list by using the negative operator '-'.

defaultA single keyword consisting of either source or target that will state whether the default user should be obtained from the source or target context.
+*default_user* + +The *default_user* rule keyword. + +*class* + +One or more *class* identifiers. Multiple entries consist of a space separated +list enclosed in braces \'\{\}\'. Entries can be excluded from the list by using +the negative operator \'\-\'. + +*default* + +A single keyword consisting of either *source* or *target* that will state +whether the default user should be obtained from the source or target context. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Examples:** @@ -93,50 +83,35 @@ default_role class default; **Where:** - - - - - - - - - - - - - - - -
default_roleThe default_role rule keyword.

class

One or more class identifiers. Multiple entries consist of a space separated list enclosed in braces '{}'.

-

Entries can be excluded from the list by using the negative operator '-'.

defaultA single keyword consisting of either source or target that will state whether the default role should be obtained from the source or target context.
+*default_role* + +The *default_role* rule keyword. + +*class* + +One or more *class* identifiers. Multiple entries consist of a space +separated list enclosed in braces \'\{\}\'. +Entries can be excluded from the list by using the negative operator \'\-\'. + +*default* + +A single keyword consisting of either *source* or *target* that will state +whether the default role should be obtained from the source or target context. + **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Examples:** @@ -168,50 +143,34 @@ default_type class default; **Where:** - - - - - - - - - - - - - - - -
default_typeThe default_type rule keyword.

class

One or more class identifiers. Multiple entries consist of a space separated list enclosed in braces '{}'.

-

Entries can be excluded from the list by using the negative operator '-'.

defaultA single keyword consisting of either source or target that will state whether the default type should be obtained from the source or target context.
+*default_type* + +The *default_type* rule keyword. + +*class* + +One or more *class* identifiers. Multiple entries consist of a space +separated list enclosed in braces \'\{\}\'. Entries can be excluded from the +list by using the negative operator \'\-\'. + +*default* + +A single keyword consisting of either *source* or *target* that will state +whether the default type should be obtained from the source or target context. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Examples:** @@ -235,7 +194,7 @@ Allows the default range or level to be taken from the source or target context when computing a new context for an object of the defined class. Requires policy version 27. -Policy verion 32 with kernel 5.5 allows the use of *glblub* as a +Policy version 32 with kernel 5.5 allows the use of *glblub* as a *default_range* default and the computed transition will be the intersection of the MLS range of the two contexts. The *glb* (greatest lower bound) *lub* (lowest upper bound) of a range is calculated as the @@ -249,58 +208,44 @@ default_range class [default range] | [glblub]; **Where:** - - - - - - - - - - - - - - - - - - - - - - - -
default_rangeThe default_range rule keyword.

class

One or more class identifiers. Multiple entries consist of a space separated list enclosed in braces '{}'.

-

Entries can be excluded from the list by using the negative operator '-'.

defaultA single keyword consisting of either source or target that will state whether the default level or range should be obtained from the source or target context.
rangeA single keyword consisting of either: low, high or low_high that will state what part of the range should be used.
glblubThe glblub keyword used instead of [default range].
+*default_range* + +The *default_range* rule keyword. + +*class* + +One or more *class* identifiers. Multiple entries consist of a space +separated list enclosed in braces \'\{\}\'. Entries can be excluded from the +list by using the negative operator \'\-\'. + +*default* + +A single keyword consisting of either *source* or *target* that will state +whether the default level or range should be obtained from the source +or target context. + +*range* + +A single keyword consisting of either: *low*, *high* or *low_high* that will +state what part of the range should be used. + +*glblub* + +The *glblub* keyword used instead of *[default range]*. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Examples:** From patchwork Tue Aug 25 08:37:39 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735159 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 5747B739 for ; Tue, 25 Aug 2020 08:38:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36D412071E for ; Tue, 25 Aug 2020 08:38:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="QJ7XtE51" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728087AbgHYIiS (ORCPT ); Tue, 25 Aug 2020 04:38:18 -0400 Received: from mailomta30-sa.btinternet.com ([213.120.69.36]:23248 "EHLO sa-prd-fep-042.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725936AbgHYIiQ (ORCPT ); Tue, 25 Aug 2020 04:38:16 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-042.btinternet.com with ESMTP id <20200825083812.IOUU26396.sa-prd-fep-042.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344692; bh=QC+svJEAdzLwdQSNt57fEKYeJFgYUGtdD+UBOXyr2J0=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=QJ7XtE51QpPpbxWEUj/MTGQ/rBtb8k+uDaibvc1nS6tdfoord794FSQ4NALfnMx5sttS3yv2a/H7SC0UfCBPZ1EveAqSpUiygUipixFtX2GNHybgHqf86ppEMuQqcn8bTBHy7yeoO+YPiGkWEOgApEJNOrp/iIxi1ZVuxKSBWH5/E8S4i8wkYP29idYNKIarMoQSMISK8m1QRY65sKJ523V7TB+GTiVKz/UZ8UL5rH9rO6Qp+wJAUqZpRjB6NsWs4ccwrKJsLUqkBPqP/PHpMyoEjpIPLXwg62yKKwv4e3+IKeVzoiLY725Wdcz/gFS7a45mhIDYzRI9i568YZ1EWw== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599E55; Tue, 25 Aug 2020 09:38:12 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 14/18] domain_object_transitions: Convert to markdown Date: Tue, 25 Aug 2020 09:37:39 +0100 Message-Id: <20200825083743.6508-15-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/domain_object_transitions.md | 121 ++++++++++++++++--------------- 1 file changed, 62 insertions(+), 59 deletions(-) diff --git a/src/domain_object_transitions.md b/src/domain_object_transitions.md index 030d866..f897c3b 100644 --- a/src/domain_object_transitions.md +++ b/src/domain_object_transitions.md @@ -1,9 +1,13 @@ # Domain and Object Transitions +- [Domain Transition](#domain-transition) + - [Type Enforcement Rules](#type-enforcement-rules) +- [Object Transition](#object-transition) + This section discusses the *type_transition* statement that is used to: -1. Transition a process from one domain to another (a domain transition). -2. Transition an object from one type to another (an object transition). +- Transition a process from one domain to another (a domain transition). +- Transition an object from one type to another (an object transition). These transitions can also be achieved using the **libselinux** API functions for SELinux-aware applications. @@ -14,19 +18,19 @@ A domain transition is where a process in one domain starts a new process in another domain under a different security context. There are two ways a process can define a domain transition: -1. Using a *type_transition* statement, where the ***exec**(2)* system call - will automatically perform a domain transition for programs that are not - themselves SELinux-aware. This is the most common method and would - be in the form of the following statement: +- Using a *type_transition* statement, where the ***exec**(2)* system call + will automatically perform a domain transition for programs that are not + themselves SELinux-aware. This is the most common method and would + be in the form of the following statement: ``` type_transition unconfined_t secure_services_exec_t : process ext_gateway_t; ``` -1. SELinux-aware applications can specify the domain of the new process - using the **libselinux** API call ***setexeccon**(3)*. To achieve - this the SELinux-aware application must also have the setexec - permission, for example: +- SELinux-aware applications can specify the domain of the new process + using the **libselinux** API call ***setexeccon**(3)*. To achieve + this the SELinux-aware application must also have the setexec + permission, for example: ``` allow crond_t self:process setexec; @@ -35,12 +39,12 @@ allow crond_t self:process setexec; However, before any domain transition can take place the policy must specify that: -1. The source *domain* has permission to *transition* into the target - domain. -2. The application binary file needs to be *executable* in the source - domain. -3. The application binary file needs an *entry point* into the target - domain. +1. The source *domain* has permission to *transition* into the target + domain. +2. The application binary file needs to be *executable* in the source + domain. +3. The application binary file needs an *entry point* into the target + domain. The following is a *type_transition* statement taken an example loadable module message filter *ext_gateway.conf* that will be used to explain @@ -59,27 +63,26 @@ the *unconfined_t* domain (the source domain) executes a file labeled transition from the *unconfined_t* domain to the *ext_gateway_t* domain). However as stated above, to be able to *transition* to the -*ext_gateway_t* domain, the following minimum permissions must be -granted in the policy using *allow* rules, where (note that the -bullet numbers correspond to the numbers shown in **Figure 7: Domain Transition**: +*ext_gateway_t* domain, the following minimum permissions must be granted in +the policy using *allow* rules, where (the bullet numbers correspond to those +in **Figure 7: Domain Transition**): -1. The *domain* needs permission to *transition* into the - *ext_gateway_t* (target) domain: +**(1)** The *domain* needs permission to *transition* into the *ext_gateway_t* +(target) domain: ``` allow unconfined_t ext_gateway_t : process transition; ``` -2. The executable file needs to be *executable* in the *unconfined_t* - (source) domain, and therefore also requires that the file is - readable: +**(2)** The executable file needs to be *executable* in the *unconfined_t* +(source) domain, and therefore also requires that the file is readable: ``` allow unconfined_t secure_services_exec_t : file { execute read getattr }; ``` -3. The executable file needs an *entry point* into the - *ext_gateway_t* (target) domain: +**(3)** The executable file needs an *entry point* into the *ext_gateway_t* +(target) domain: ``` allow ext_gateway_t secure_services_exec_t : file entrypoint; @@ -94,7 +97,7 @@ SELinux enabled kernel. ![](./images/7-domain-transition.png) **Figure 7: Domain Transition** - *Where the secure_server is executed -within the *unconfined_t* domain and then transitioned to the *ext_gateway_t* +within the unconfined_t domain and then transitioned to the ext_gateway_t domain.* ### Type Enforcement Rules @@ -164,10 +167,10 @@ target domains), that breaks the type enforcement rule. It was decided to resolve this by: -1. Keeping the *type_transition* rule for the 'default' type of - *ext_gateway_t* and allow the secure server process to be exec'd - from *unconfined_t* as shown in **Figure 7: Domain Transition**, by simply - running the command from the prompt as follows: +- Keeping the *type_transition* rule for the 'default' type of + *ext_gateway_t* and allow the secure server process to be exec'd + from *unconfined_t* as shown in **Figure 7: Domain Transition**, by simply + running the command from the prompt as follows: ``` # Run the external gateway 'secure server' application on port 9999 and @@ -176,9 +179,9 @@ It was decided to resolve this by: secure_server 99999 ``` -1. Use the SELinux ***runcon**(1)* command to ensure that the internal - gateway runs in the correct domain by running runcon from the prompt - as follows: +- Use the SELinux ***runcon**(1)* command to ensure that the internal + gateway runs in the correct domain by running *runcon* from the prompt + as follows: ``` # Run the internal gateway 'secure server' application on port 1111 and @@ -189,34 +192,34 @@ runcon -t int_gateway_t -r message_filter_r secure_server 1111 # Note: The role is required as a role transition is defined in the policy. ``` -The runcon command makes use of a number of **libselinux** API +The ***runcon**(1)* command makes use of a number of **libselinux** API functions to check the current context and set up the new context (for example ***getfilecon**(3)* is used to get the executable files context and ***setexeccon**(3)* is used to set the new process context). If all contexts are correct, then the ***execvp**(2)* system call is executed that exec's the secure_server application with the argument of '1111' into the *int_gateway_t* domain with the *message_filter_r* role. The -runcon source can be found in the coreutils package. +*runcon* source can be found in the coreutils package. Other ways to resolve this issue are: -1. Use the runcon command for both gateways to transition to their - respective domains. The *type_transition* statements are therefore - not required. -2. Use different names for the secure server executable files and - ensure they have a different type (i.e. instead of - *secure_service_exec_t* label the external gateway - *ext_gateway_exec_t* and the internal gateway - *int_gateway_exec_t*. This would involve making a copy of the - application binary (which has already been done as part of the - **module testing** by calling the server 'server' and labeling it - *unconfined_t* and then making a copy called secure_server and - labeling it *secure_services_exec_t*). -3. Implement the policy using the Reference Policy utilising the - template interface principles discussed in the - [**template**](reference_policy.md#template-macro) section. - -It was decided to use runcon as it demonstrates the command usage better +1. Use the *runcon* command for both gateways to transition to their + respective domains. The *type_transition* statements are therefore + not required. +2. Use different names for the secure server executable files and + ensure they have a different type (i.e. instead of + *secure_service_exec_t* label the external gateway + *ext_gateway_exec_t* and the internal gateway + *int_gateway_exec_t*. This would involve making a copy of the + application binary (which has already been done as part of the + **module testing** by calling the server 'server' and labeling it + *unconfined_t* and then making a copy called secure_server and + labeling it *secure_services_exec_t*). +3. Implement the policy using the Reference Policy utilising the + template interface principles discussed in the + [**template**](reference_policy.md#template-macro) section. + +It was decided to use *runcon* as it demonstrates the command usage better than reading the man pages. ## Object Transition @@ -230,7 +233,7 @@ automatically using a *type_transition* statement as follows: type_transition ext_gateway_t in_queue_t:file in_file_t; ``` -The following details an object transition used in n example +The following details an object transition used in an example *ext_gateway.conf* loadable module where by default, files would be labeled *in_queue_t* when created by the gateway application as this is the label attached to the parent directory as shown: @@ -261,21 +264,21 @@ However as stated above to be able to create the file, the following minimum permissions need to be granted in the policy using *allow* rules, where: -1. The source domain needs permission to *add file entries into the - directory*: +- The source domain needs permission to *add file entries into the + directory*: ``` allow ext_gateway_t in_queue_t : dir { write search add_name }; ``` -2. The source domain needs permission to *create file entries*: +- The source domain needs permission to *create file entries*: ``` allow ext_gateway_t in_file_t : file { write create getattr }; ``` -3. The policy can then ensure (via the SELinux kernel services) that - files created in the *in_queue* are relabeled: +- The policy can then ensure (via the SELinux kernel services) that + files created in the *in_queue* are relabeled: ``` type_transition ext_gateway_t in_queue_t : file in_file_t; From patchwork Tue Aug 25 08:37:40 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735171 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 AE962739 for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8BF402071E for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="hKqVTSmb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728109AbgHYIiZ (ORCPT ); Tue, 25 Aug 2020 04:38:25 -0400 Received: from mailomta31-sa.btinternet.com ([213.120.69.37]:46271 "EHLO sa-prd-fep-044.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728975AbgHYIiR (ORCPT ); Tue, 25 Aug 2020 04:38:17 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-044.btinternet.com with ESMTP id <20200825083813.GKOM3440.sa-prd-fep-044.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344693; bh=6O1rdI9AbGRZpTFs7nv0iB+4xDi2UYizI4rae+4FTZk=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=hKqVTSmbvH5zVhRagIENPlGK/c6WjMXa0iCVsCrKlNqtjqE062hg3RT3hTTgyB8sh7p+ccadxf/l1a7JWyI+SUY2Wzc5t7G2SDvwvUZbKO73i68DpNFr5RGcgeXO3nCYjcyDfqaCMFyXdZxPNsLm0cD4DmvK6YDw9DBfUA9244aeSrnHQI+Hs4TZRrQZggmTd7d647OvXLCruNnlR5/UEMCjRAP4WjGfd42dHtlsA224KBzyP19vhkddMB2pPPQnv31NF+PyVbX93CJwK7H+dKrZkhidfS5uKtSVhe5DPyQmnixMsvscjDzDxEnBf5ggN15O0Ixw43eJDnH/n7khBQ== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599E5F; Tue, 25 Aug 2020 09:38:12 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 15/18] file_labeling_statements: Convert to markdown Date: Tue, 25 Aug 2020 09:37:40 +0100 Message-Id: <20200825083743.6508-16-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/file_labeling_statements.md | 260 ++++++++++++-------------------- 1 file changed, 96 insertions(+), 164 deletions(-) diff --git a/src/file_labeling_statements.md b/src/file_labeling_statements.md index 34c2ca8..47d0309 100644 --- a/src/file_labeling_statements.md +++ b/src/file_labeling_statements.md @@ -1,5 +1,10 @@ # File System Labeling Statements +- [*fs_use_xattr*](#fs_use_xattr) +- [*fs_use_task*](#fs_use_task) +- [*fs_use_trans*](#fs_use_trans) +- [*genfscon*](#genfscon) + There are four types of file labeling statements: *fs_use_xattr*, *fs_use_task*, *fs_use_trans* and *genfscon* that are explained below. @@ -30,49 +35,33 @@ fs_use_xattr fs_name fs_context; **Where:** - - - - - - - - - - - - - - - -
fs_use_xattrThe fs_use_xattr keyword.
fs_nameThe filesystem name that supports extended attributes. Example names are: encfs, ext2, ext3, ext4, ext4dev, gfs, gfs2, jffs2, jfs, lustre and xfs.
fs_contextThe security context allocated to the filesystem.
+*fs_use_xattr* + +The *fs_use_xattr* keyword. + +*fs_name* + +The filesystem name that supports extended attributes. Example names are: +*encfs*, *ext2*, *ext3*, *ext4*, *ext4dev*, *gfs*, *gfs2*, *jffs2*, *jfs*, +*lustre* and *xfs*. + +*fs_context* + +The security context allocated to the filesystem. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Example:** @@ -99,49 +88,30 @@ fs_use_task fs_name fs_context; **Where:** - - - - - - - - - - - - - - - -
fs_use_taskThe fs_use_task keyword.
fs_nameFilesystem name that supports task related services. Example valid names are: eventpollfs, pipefs and sockfs.
fs_contextThe security context allocated to the task based filesystem.
+*fs_use_task* + +The *fs_use_task* keyword. + +*fs_name* + +Filesystem name that supports task related services. Example valid names are: +*eventpollfs*, *pipefs* and *sockfs*. + +*fs_context* + +The security context allocated to the task based filesystem. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Example:** @@ -171,49 +141,30 @@ fs_use_trans fs_name fs_context; **Where:** - - - - - - - - - - - - - - - -
fs_use_transThe fs_use_trans keyword.
fs_nameFilesystem name that supports transition rules. Example names are: mqueue, shm, tmpfs and devpts.
fs_contextThe security context allocated to the transition based on that of the filesystem.
+*fs_use_trans* + +The *fs_use_trans* keyword. + +*fs_name* + +Filesystem name that supports transition rules. Example names are: +*mqueue*, *shm*, *tmpfs* and *devpts*. + +*fs_context* + +The security context allocated to the transition based on that of the filesystem. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Example:** @@ -247,53 +198,34 @@ genfscon fs_name partial_path fs_context **Where:** - - - - - - - - - - - - - - - - - - - -
genfsconThe genfscon keyword.
fs_nameThe filesystem name.
partial_pathIf fs_name is proc, then the partial path (see the examples). For all other types, this must be /.
fs_contextThe security context allocated to the filesystem
+*genfscon* + +The *genfscon* keyword. + +*fs_name* + +The filesystem name. + +*partial_path* + +If *fs_name* is *proc*, then the partial path (see the examples). For all other +types, this must be */*. + +*fs_context* + +The security context allocated to the filesystem **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesNo
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | No | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **MLS Examples:** From patchwork Tue Aug 25 08:37:41 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735175 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 451F714F6 for ; Tue, 25 Aug 2020 08:38:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1FD052074D for ; Tue, 25 Aug 2020 08:38:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="jXukjAO1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728975AbgHYIiZ (ORCPT ); Tue, 25 Aug 2020 04:38:25 -0400 Received: from mailomta10-sa.btinternet.com ([213.120.69.16]:21299 "EHLO sa-prd-fep-043.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728986AbgHYIiT (ORCPT ); Tue, 25 Aug 2020 04:38:19 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-043.btinternet.com with ESMTP id <20200825083813.MPLC26847.sa-prd-fep-043.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344693; bh=JvwxzYr/Vo0koxLkoamrclXNqzAbBWzj4pO8Jtdp/0o=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=jXukjAO10bNBjUHLU5uJ0WEUi/FOGg6xOMrDLjASpt4ZhU1qmWFtRZlhen8SM1gwlcNqnuuWJijA7R5H4U6QhBpSGlfpeBK82Ams5+hlxdy2q0yREZ0cHzdGQubU+XtgdrmoP6XHPJRcGYSZ8Rjz4YpGUgO7gMEHRgcdHOPhxFPdHCF48KYzcae3bM0VcxxOyrWprVmLrsZdgTonCL9pl3Np17xfXucRfq5b1srXxNWL7iBbUW/TkVk82GnpH/h1VD20VNXQToa1/fVGA1I6n0GVaMDWFdPwyKp97lOZRRpMdRAk47IV+zCpAUJTX7ovpIM6cNkQJ9f2oX2wEfgyyQ== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphhtthhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599E70; Tue, 25 Aug 2020 09:38:13 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 16/18] global_config_files: Convert to markdown Date: Tue, 25 Aug 2020 09:37:41 +0100 Message-Id: <20200825083743.6508-17-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/global_config_files.md | 389 +++++++++++++++++++++---------------- 1 file changed, 220 insertions(+), 169 deletions(-) diff --git a/src/global_config_files.md b/src/global_config_files.md index 80e557b..7c8132d 100644 --- a/src/global_config_files.md +++ b/src/global_config_files.md @@ -1,13 +1,21 @@ # Global Configuration Files +- [*/etc/selinux/config*](#etcselinuxconfig) +- [*/etc/selinux/semanage.conf*](#etcselinuxsemanage.conf) +- [*/etc/selinux/restorecond.conf*](#etcselinuxrestorecond.conf) +- [*restorecond-user.conf*](#restorecond-user.conf) +- [*/etc/selinux/newrole_pam.conf*](#etcselinuxnewrole_pam.conf) +- [*/etc/sestatus.conf*](#etcsestatus.conf) +- [*/etc/security/sepermit.conf*](#etcsecuritysepermit.conf) + Listed in the sections that follow are the common configuration files used by SELinux and are therefore not policy specific. The two most important files are: -- */etc/selinux/config* - This defines the policy to be activated and - its enforcing mode. -- */etc/selinux/semanage.conf* - This is used by the SELinux policy - configuration subsystem for modular or CIL policies. +- */etc/selinux/config* - This defines the policy to be activated and + its enforcing mode. +- */etc/selinux/semanage.conf* - This is used by the SELinux policy + configuration subsystem for modular or CIL policies. ## */etc/selinux/config* @@ -26,44 +34,59 @@ AUTORELABEL=0|1 **Where:** - - - - - - - - - - - - - - - - - - - - - - - -
SELINUX

This entry can contain one of three values:

-

enforcing - SELinux security policy is enforced.

-

permissive - SELinux logs warnings (see the Auditing SELinux Events section) instead of enforcing the policy (i.e. the action is allowed to proceed).

-

disabled - No SELinux policy is loaded.

-

Note that this configures the global SELinux enforcement mode. It is still possible to have domains running in permissive mode and/or object managers running as disabled, permissive or enforcing, when the global mode is enforcing or permissive.

SELINUXTYPE

The policy_name is used as the directory name where the active policy and its configuration files will be located. The system will then use this information to locate and load the policy contained within this directory structure.

-

The policy directory must be located at:

-

/etc/selinux

SETLOCALDEFS

Deprecated This optional field should be set to 0 (or the entry removed) as the policy store management infrastructure (semanage(8) / semodule(8)) is now used.

-

If set to 1, then init(8) and load_policy(8) will read the local customisation for booleans and users.

REQUIRESEUSERS

Deprecated This optional field can be used to fail a login if there is no matching or default entry in the seusers file or if the file is missing.

-

It is checked by the libselinux function getseuserbyname(3) that is used by SELinux-aware login applications such as PAM(8).

-

If it is set to 0 or the entry missing:

-

getseuserbyname(3) will return the GNU / Linux user name as the SELinux user.

-

If it is set to 1:

-

getseuserbyname(3) will fail.

AUTORELABEL

This is an optional field. If set to '0' and there is a file called .autorelabel in the root directory, then on a reboot, the loader will drop to a shell where a root logon is required. An administrator can then manually relabel the file system.

-

If set to '1' or the parameter name is not used (the default) there is no login for manual relabeling, however should the /.autorelabel file exist, then the file system will be automatically relabeled using fixfiles -F restore.

-

In both cases the /.autorelabel file will be removed so relabeling is not done again.

+*SELINUX* + +This entry can contain one of three values: + +- *enforcing* - SELinux security policy is enforced. +- *permissive* - SELinux logs warnings (see the + [**Auditing SELinux Events**](auditing.md#auditing-selinux-events) section) + instead of enforcing the policy (i.e. the action is allowed to proceed). +- *disabled* - No SELinux policy is loaded. Note that this configures + the global SELinux enforcement mode. It is still possible to have domains + running in permissive mode and/or object managers running as disabled, + permissive or enforcing, when the global mode is enforcing or permissive. + +*SELINUXTYPE* + +The *policy_name* is used as the directory name where the active policy +and its configuration files will be located. The system will then use this +information to locate and load the policy contained within this directory +structure. The policy directory must be located at: */etc/selinux* + +*SETLOCALDEFS* + +**Deprecated** - This optional field should be set to 0 (or the entry removed) +as the policy store management infrastructure (***semanage**(8)* / +***semodule**(8)*) is now used. If set to 1, then ***init**(8)* and +***load_policy**(8)* will read the local customisation for booleans and users. + +*REQUIRESEUSERS* + +**Deprecated** - This optional field can be used to fail a login if there is +no matching or default entry in the *seusers* file or if the file is missing. +It is checked by the *libselinux* function ***getseuserbyname**(3)* that is +used by SELinux-aware login applications such as ***PAM**(8)*. +If it is set to 0 or the entry missing: + +- ***getseuserbyname**(3)* will return the GNU / Linux user name as the + SELinux user. + +If it is set to 1: + +- ***getseuserbyname**(3)* will fail. + +*AUTORELABEL* + +This is an optional field. If set to \'*0*\' and there is a file called +*.autorelabel* in the root directory, then on a reboot, the loader will drop +to a shell where a root logon is required. An administrator can then manually +relabel the file system. +If set to '1' or the parameter name is not used (the default) there is no +login for manual relabeling, however should the */.autorelabel* file exist, +then the file system will be automatically relabeled using *fixfiles -F restore*. +In both cases the */.autorelabe*l file will be removed so relabeling is not +done again. **Example */etc/selinux/config* file contents are:** @@ -139,124 +162,152 @@ args = **Where:** - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
module-store

The method can be one of four options:

-

directlibsemanage will write directly to a module store. This is the default value.

-

sourcelibsemanage manipulates a source SELinux policy.

-

/foo/bar Write via a policy management server, whose named socket is at /foo/bar. The path must begin with a '/'.

-

foo.com:4242 Establish a TCP connection to a remote policy management server at foo.com. If there is a colon then the remainder is interpreted as a port number; otherwise default to port 4242.

policy-versionThis optional entry can contain a policy version number, however it is normally commented out as it then defaults to that supported by the system.
expand-check

This optional entry controls whether hierarchy checking on module expansion is enabled (1) or disabled (0). The default is 0.

-

It is also required to detect the presence of policy rules that are to be excluded with neverallow rules.

file-modeThis optional entry allows the file permissions to be set on runtime policy files. The format is the same as the mode parameter of the chmod command and defaults to 0644 if not present.
save-previousThis optional entry controls whether the previous module directory is saved (TRUE) after a successful commit to the policy store. The default is to delete the previous version (FALSE).
save-linked

This optional entry controls whether the previously linked module is saved (TRUE) after a successful commit to the policy store. Note that this option will create a base.linked file in the module policy store.

-

The default is to delete the previous module (FALSE).

disable-genhomedirconThis optional entry controls whether the embedded genhomedircon function is run when using the semanage(8) command. The default is FALSE.
handle-unknown

This optional entry controls the kernel behaviour for handling permissions defined in the kernel but missing from the policy.

-

The options are: allow the permission, reject by not loading the policy or deny the permission. The default is deny.

-

Note: to activate any change, the base policy needs to be rebuilt with the semodule -B command.

bzip-blocksizeThis optional entry determines whether the modules are compressed or not with bzip. If the entry is 0, then no compression will be used (this is required with tools such as sechecker and apol). This can also be set to a value between 1 and 9 that will set the block size used for compression (bzip will multiply this by 100,000, so '9' is faster but uses more memory).
bzip-smallWhen this optional entry is set to TRUE the memory usage is reduced for compression and decompression (the bzip -s or --small option). If FALSE or no entry present, then does not try to reduce memory requirements.
usepasswd

When this optional entry is set to TRUE semanage will scan all password records for home directories and set up their labels correctly.

-

If set to FALSE (the default if no entry present), then only the /home directory will be automatically re-labeled.

ignoredirsWith a list of directories to ignore (separated by ';') when setting up users home directories. This is used by some distributions to stop labeling /root as a home directory.
store-rootSpecify an alternative policy store path . The default is "/var/lib/selinux".
compiler-directorySpecify an alternate directory that will hold the High Level Language (HLL) to CIL compilers. The default is "/usr/libexec/selinux/hll".
remove-hllWhen set TRUE, HLL files will be removed after compilation into CIL (Read semanage.conf(5) for the consequences of removing these files). Default is FALSE.
ignore-module-cacheWhether or not to ignore the cache of CIL modules compiled from HLL. The default is false.
target-platformTarget platform for generated policy. Default is "selinux", the alternate is "xen".

[verify kernel]

-

..

-

[end]

Start an additional set of entries that can be used to validate the kernel policy with an external application during the build process. There may be multiple [verify kernel] entries.

-

The validation process takes place before the policy is allowed to be inserted into the store with a worked example shown in Policy Validation Example

[verify module]

-

..

-

[end]

Start an additional set of entries that can be used to validate each module by an external application during the build process. There may be multiple [verify module] entries.

[verify linked]

-

..

-

[end]

Start an additional set of entries that can be used to validate module linking by an external application during the build process. There may be multiple [verify linked] entries.

[load_policy]

-

..

-

[end]

Replace the default load policy application with this new policy loader. Defaults are either: /sbin/load_policy or /usr/sbin/load_policy.

[setfiles]

-

..

-

[end]

Replace the default setfiles(8) application with this new setfiles. Defaults are either: /sbin/setfiles or /usr/sbin/setfiles.

[sefcontexts_compile]

-

..

-

[end]

Replace the default file context build application with this new builder. Defaults are either: /sbin/sefcontexts_compile or /usr/sbin/sefcontexts_compile.
+*module-store* + +The method can be one of four options: + +1. *directlibsemanage* will write directly to a module store. + This is the default value. +2. *sourcelibsemanage* manipulates a source SELinux policy. +3. */foo/bar* - Write via a policy management server, whose named socket is + at /foo/bar. The path must begin with a '/'. +4. *foo.com:4242* - Establish a TCP connection to a remote policy management + server at *foo.com*. If there is a colon then the remainder is interpreted + as a port number; otherwise default to port 4242. + +*policy-version* + +This optional entry can contain a policy version number, however it is normally +commented out as it then defaults to that supported by the system. + +*expand-check* + +This optional entry controls whether hierarchy checking on module expansion +is enabled (1) or disabled (0). The default is 0. It is also required to detect +the presence of policy rules that are to be excluded with *neverallow* rules. + +*file-mode* + +This optional entry allows the file permissions to be set on runtime policy +files. The format is the same as the mode parameter of the ***chmod**(1)* +command and defaults to 0644 if not present. + +*save-previous* + +This optional entry controls whether the previous module directory is saved +(TRUE) after a successful commit to the policy store. The default is to delete +the previous version (FALSE). + +*save-linked* + +This optional entry controls whether the previously linked module is saved +(TRUE) after a successful commit to the policy store. Note that this option +will create a *base.linked* file in the module policy store. +The default is to delete the previous module (FALSE). + +*disable-genhomedircon* + +This optional entry controls whether the embedded *genhomedircon* function is +run when using the ***semanage**(8)* command. The default is FALSE. + +*handle-unknown* + +This optional entry controls the kernel behaviour for handling permissions +defined in the kernel but missing from the policy. +The options are: *allow* the permission, *reject* by not loading the policy +or *deny* the permission. The default is *deny*. +Note: to activate any change, the base policy needs to be rebuilt with the +*semodule -B* command. + +*bzip-blocksize* + +This optional entry determines whether the modules are compressed or not +with *bzip*. If the entry is *0*, then no compression will be used (this is +required with tools such as ***apol**(1)*. This can also be set to a value +between *1* and *9* that will set the block size used for compression +(*bzip* will multiply this by 100,000, so '*9*' is faster but uses more memory). + +*bzip-small* + +When this optional entry is set to *TRUE* the memory usage is reduced for +compression and decompression (the *bzip* *-s* or *\-\-small* option). If *FALSE* +or no entry present, then does not try to reduce memory requirements. + +*usepasswd* + +When this optional entry is set to *TRUE* *semanage* will scan all password +records for home directories and set up their labels correctly. +If set to *FALSE* (the default if no entry present), then only the +*/home* directory will be automatically re-labeled. + +*ignoredirs* + +With a list of directories to ignore (separated by '*;*') when setting up users +home directories. This is used by some distributions to stop labeling */root* +as a home directory. + +*store-root* + +Specify an alternative policy store path. The default is */var/lib/selinux*. + +*compiler-directory* + +Specify an alternate directory that will hold the High Level Language (HLL) +to CIL compilers. The default is */usr/libexec/selinux/hll*. + +*remove-hll* + +When set *TRUE*, HLL files will be removed after compilation into CIL +(Read ***semanage.conf**(5)* for the consequences of removing these files). +Default is *FALSE*. + +*ignore-module-cache* + +Whether or not to ignore the cache of CIL modules compiled from HLL. +The default is *false*. + +*target-platform* + +Target platform for generated policy. Default is *selinux*, the alternate +is *xen*. + +*\[verify kernel\] .. \[end\]* + +Start an additional set of entries that can be used to validate the kernel +policy with an external application during the build process. There may be +multiple *\[verify kernel\]* entries. +The validation process takes place before the policy is allowed to be inserted +into the store with a worked example shown in +[**Policy Validation Example**](policy_validation_example.md#appendix-e---policy-validation-example) + + +*\[verify module\] .. \[end\]* + +Start an additional set of entries that can be used to validate each module +by an external application during the build process. There may be multiple +*\[verify module\]* entries. + +*\[verify linked\] .. \[end\]* + +Start an additional set of entries that can be used to validate module linking +by an external application during the build process. There may be multiple +*\[verify linked\]* entries. + +*\[load_policy\] .. \[end\]* + +Replace the default load policy application with this new policy loader. +Defaults are either: */sbin/load_policy* or */usr/sbin/load_policy*. + +*\[setfiles\] .. \[end\]* + +Replace the default ***setfiles**(8)* application with this new *setfiles*. +Defaults are either: */sbin/setfiles* or */usr/sbin/setfiles*. + +*\[sefcontexts_compile\] .. \[end\]* + +Replace the default file context build application with this new builder. +Defaults are either: */sbin/sefcontexts_compile* or +*/usr/sbin/sefcontexts_compile* **Example *semanage.config* file contents are:** @@ -279,19 +330,19 @@ by applications with an incorrect security context. The ***restorecond**(8)* daemon will then watch for their creation and automatically correct their security context to that specified by the active policy file context configuration files (located in the -*/etc/selinux/<SELINUXTYPE>/contexts/files* directory). +*/etc/selinux/\/contexts/files* directory). Each line of the file contains the full path of a file or directory. -Entries that start with a tilde (~) will be expanded to watch for files -in users home directories (e.g. *~/public\_html* would cause the daemon to -listen for changes to *public\_html* in all logged on users home +Entries that start with a tilde \'\~\' will be expanded to watch for files +in users home directories (e.g. *\~/public_html* would cause the daemon to +listen for changes to *public_html* in all logged on users home directories). -1. It is possible to run *restorecond* in a user session using - the *-u* option (see ***restorecond**(8)*). This requires a - *restorecond-user.conf* file to be installed as shown in the examples below. -2. The files names and location can be changed if *restorecond* is run - with the *-f* option. +1. It is possible to run *restorecond* in a user session using + the *-u* option (see ***restorecond**(8)*). This requires a + *restorecond-user.conf* file to be installed as shown in the examples below. +2. The files names and location can be changed if *restorecond* is run + with the *-f* option. **Example *restorecond.conf* file contents are:** From patchwork Tue Aug 25 08:37:42 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735179 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 7551B14F6 for ; Tue, 25 Aug 2020 08:38:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 443C120706 for ; Tue, 25 Aug 2020 08:38:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="IFphhl//" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728145AbgHYIi0 (ORCPT ); Tue, 25 Aug 2020 04:38:26 -0400 Received: from mailomta17-sa.btinternet.com ([213.120.69.23]:51193 "EHLO sa-prd-fep-048.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726365AbgHYIiU (ORCPT ); Tue, 25 Aug 2020 04:38:20 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-048.btinternet.com with ESMTP id <20200825083813.LXZL4139.sa-prd-fep-048.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344694; bh=1f6uZZsp9WA0ydx+zF6ICacFeydHydUeq270gc+y1Tw=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=IFphhl//TTLf9qGrKP7dUCyhg5IQ4qi5KnswmJspR7F2rNP6CzbX3evs8sDzVT/OIKTFoZjEATrzVF5q0/aFH8NWUEq4D6+akzSrh2cqzp40CzKeEFk/ZYpdrJ/6sek6lZykNPZ7fkm09hwzIEqUczmMoogUNbH5Fh15Av1oU+5arzv0+lXFATHHZYL46etsWu/n+alQdO7RxjVNlHgrrw9OJJhKUBmm22+NPRf/ZJ36KRleyPpdwQboJ6bJpV1l4na2cdmTn5fBvo9Uzd9AGqu/dOpBNNUA41jq9UL4MBL670sugDiba9RhySD7cYSfHxsuAsipsmt6cCQM3XQXFA== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfgggtgfesthekredtredtjeenucfhrhhomheptfhitghhrghrugcujfgrihhnvghsuceorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqnecuggftrfgrthhtvghrnhepledtffekgfevgeffkeehhedvleeljeejgffhvdeigfffgfefleevveetteduvddunecuffhomhgrihhnpeigrdhorhhgpdhsvghlihhnuhigphhrohhjvggtthdrohhrghenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehlohgtrghlhhhoshhtrdhlohgtrghlughomhgrihhnpdhinhgvthepuddtledrudehhedrudeftddrudeitddpmhgrihhlfhhrohhmpeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoehprghulhesphgruhhlqdhmohhorhgvrdgtohhmqedprhgtphhtthhopeeorhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhequcfqtfevrffvpehrfhgtkedvvdenrhhitghhrghruggptggphhgrihhnvghssegsthhinhhtvghrnhgvthdrtghomhdprhgtphht thhopeeoshgvlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599E7D; Tue, 25 Aug 2020 09:38:13 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 17/18] implementing_seaware_apps: Convert to markdown Date: Tue, 25 Aug 2020 09:37:42 +0100 Message-Id: <20200825083743.6508-18-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/implementing_seaware_apps.md | 218 +++++++++++++++---------------- 1 file changed, 109 insertions(+), 109 deletions(-) diff --git a/src/implementing_seaware_apps.md b/src/implementing_seaware_apps.md index 13020c9..ee38258 100644 --- a/src/implementing_seaware_apps.md +++ b/src/implementing_seaware_apps.md @@ -1,5 +1,10 @@ # Implementing SELinux-aware Applications +- [Implementing SELinux-aware Applications](#implementing-selinux-aware-applications) +- [Implementing Object Managers](#implementing-object-managers) +- [Reference Policy Changes](#reference-policy-changes) +- [Adding New Object Classes and Permissions](#adding-new-object-classes-and-permissions) + The following definitions attempt to explain the difference between the two types of userspace SELinux application (however the distinction can get 'blurred'): @@ -13,22 +18,21 @@ object manager as an SELinux-aware application. **Object Manager** - Object Managers are a specialised form of SELinux-aware application that are responsible for the labeling, -management and enforcement1 -of the objects under their control. +management and enforcement[^fn_isa_1] of the objects under their control. Generally the userspace Object Manager forms part of an application that can be configured out should the base Linux OS not support SELinux. Example userspace Object Managers are: -- X-SELinux is an optional X-Windows extension responsible for - labeling and enforcement of X-Windows objects. -- Dbus has an optional Object Manager built if SELinux is defined in - the Linux build. This is responsible for the labeling and - enforcement of Dbus objects. -- SE-PostgreSQL is an optional extension for PostgreSQL that is - responsible for the labeling and enforcement of PostgreSQL database - and supporting objects. +- X-SELinux is an optional X-Windows extension responsible for + labeling and enforcement of X-Windows objects. +- Dbus has an optional Object Manager built if SELinux is defined in + the Linux build. This is responsible for the labeling and + enforcement of Dbus objects. +- SE-PostgreSQL is an optional extension for PostgreSQL that is + responsible for the labeling and enforcement of PostgreSQL database + and supporting objects. Therefore the basic distinction is that Object Managers manage their defined objects on behalf of an application, whereas general @@ -45,7 +49,7 @@ developing SELinux-aware applications and object managers using 1. Determine the security objectives and requirements. 2. Because these applications manage labeling and access control, they need to be trusted. -3. Where possible use the libselinux *\*_raw* functions as they avoid +3. Where possible use the libselinux *\*\_raw* functions as they avoid the overhead of translating the context to/from the readable format (unless of course there is a requirement for a readable context - see ***mcstransd**(8)*). @@ -65,7 +69,7 @@ developing SELinux-aware applications and object managers using 8. Do not use class IDs directly, use ***string_to_security_class**(3)* that will take the class string defined in the policy and return the class ID/value. Always check - the value is > 0. If *0*, then signifies that the class is + the value is \> 0. If *0*, then signifies that the class is unknown and the **deny_unknown** flag setting in the policy will determine the outcome of any decision - see ***security_deny_unknown**(3)*. @@ -99,59 +103,60 @@ developing SELinux-aware applications and object managers using To implement object managers for applications, an understanding of the application is essential, because as a minimum: -- What object types and their permissions are required. -- Where in the code object instances are created. -- Where access controls need to be applied. +- What object types and their permissions are required. +- Where in the code object instances are created. +- Where access controls need to be applied. While this section cannot help with those points, here are some notes to help during the design phase: -1. Determine what objects are required and the access controls - (permissions) that need to be applied. -2. Does SELinux already have some of these object classes and - permissions defined. For standard Linux OS objects such as files, - then these would be available. If so, the object manager should - remap them with ***selinux_set_mapping**(3)* so only those - required are available. +1. Determine what objects are required and the access controls + (permissions) that need to be applied. +2. Does SELinux already have some of these object classes and + permissions defined. For standard Linux OS objects such as files, + then these would be available. If so, the object manager should + remap them with ***selinux_set_mapping**(3)* so only those + required are available. However, do not try to reuse a current object that may be similar to the requirements, it will cause confusion at some stage. Always generate new classes/permissions. -1. If the application has APIs or functions that integrate with other - applications or scripts, then as part of the object manager - implementation these may need to support the use of security - contexts (examples are X-Windows and SE-PostgreSQL that provide - functions for other applications to use). Therefore if required, - provide common functions that can be used to label the objects. -2. Determine how the initial objects will be labeled. For example will - a configuration file be required for default labels, if so how will - this be introduced into the SELinux userspace build. Examples of - these are the X-Windows (***selabel_x**(5)*), SE-PostgreSQL - (***selabel_db**(3)*), and file context series of files - (***selabel_file**(5)*). -3. Will the labeling need to be persistent across policy and system - reloads or not. X-Windows is an example of a non-persistent, and - SE-PostgreSQL is an example of a persistent object manager. -4. Will support for the standard audit log or its own be required (the - *libselinux* functions default to *stderr*). Use - ***selinux_set_callback**(3)* to manage logging services. -5. Decide whether an AVC cache is required or not. If the object - manager handles high volumes of requests then an AVC will be - required. -6. Will the object manager need to do additional processing when policy - or enforcement changes are detected. This could be clearing any - caches or resetting variables etc.. If so, then - ***selinux_set_callback**(3)* will be used to set up these - functions. These events are detected via the ***netlink**(7)* - services, see ***avc_open**(3)* and ***avc_netlink_open**(3)* for - the various options available. -7. If possible implement a service like XACE for the application, and - use it to interface with the applications SELinux object manager. - The XACE interface acts like the LSM which supports SELinux as well - as other providers such as SMACK. The XACE interface is defined in - the [**X Access Control Extension Specification**](http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.pdf), and for reference, the SE-PostgreSQL service also implements a similar - interface. +1. If the application has APIs or functions that integrate with other + applications or scripts, then as part of the object manager + implementation these may need to support the use of security + contexts (examples are X-Windows and SE-PostgreSQL that provide + functions for other applications to use). Therefore if required, + provide common functions that can be used to label the objects. +2. Determine how the initial objects will be labeled. For example will + a configuration file be required for default labels, if so how will + this be introduced into the SELinux userspace build. Examples of + these are the X-Windows (***selabel_x**(5)*), SE-PostgreSQL + (***selabel_db**(3)*), and file context series of files + (***selabel_file**(5)*). +3. Will the labeling need to be persistent across policy and system + reloads or not. X-Windows is an example of a non-persistent, and + SE-PostgreSQL is an example of a persistent object manager. +4. Will support for the standard audit log or its own be required (the + *libselinux* functions default to *stderr*). Use + ***selinux_set_callback**(3)* to manage logging services. +5. Decide whether an AVC cache is required or not. If the object + manager handles high volumes of requests then an AVC will be + required. +6. Will the object manager need to do additional processing when policy + or enforcement changes are detected. This could be clearing any + caches or resetting variables etc.. If so, then + ***selinux_set_callback**(3)* will be used to set up these + functions. These events are detected via the ***netlink**(7)* + services, see ***avc_open**(3)* and ***avc_netlink_open**(3)* for + the various options available. +7. If possible implement a service like XACE for the application, and + use it to interface with the applications SELinux object manager. + The XACE interface acts like the LSM which supports SELinux as well + as other providers such as SMACK. The XACE interface is defined in the + [**X Access Control Extension Specification**](http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.pdf), + and for reference, the SE-PostgreSQL service also implements a similar + interface. ## Reference Policy Changes @@ -163,37 +168,36 @@ Policy source can be obtained from: The main points to note when adding to the Reference Policy are: -1. Create sample Reference Policy policy modules (*\*.te*, *\*.if* and - *\*.fc* module files) that provide rules for managing the new objects as - described in the [**The Reference Policy**](reference_policy.md#the-reference-policy) section. -- The SE-PostgreSQL modules provide an example, see the - *./refpolicy/policy/modules/services/postgresql.* files in the - Reference Policy source. - -2. Create any new policy classes and permissions for the Reference - Policy, these will need to be built into the base module as - described in the - [Adding New Object Classes and Permissions](#adding-new-object-classes-and-permissions) - section. +1. Create sample Reference Policy policy modules (*\*.te*, *\*.if* and + *\*.fc* module files) that provide rules for managing the new objects as + described in the [**The Reference Policy**](reference_policy.md#the-reference-policy) section. + - The SE-PostgreSQL modules provide an example, see the + *./refpolicy/policy/modules/services/postgresql.* files in the + Reference Policy source. +2. Create any new policy classes and permissions for the Reference + Policy, these will need to be built into the base module as + described in the + [Adding New Object Classes and Permissions](#adding-new-object-classes-and-permissions) + section. Note, that if no new object classes, permissions or constraints are being added to the policy, then the Reference Policy source code does not require modification, and supplying the module files (*\*.te*, *\*.if* and *\*.fc*) should suffice. -1. Create any constraints required as these need to be built into the - base module of the Reference Policy. They are added to the - *./refpolicy/policy/constraints*, *mcs* and *mls* files. Again the - SE-PostgreSQL entries in these files give examples (find the - *db_\** class entries). -2. Create any SELinux configuration files (context, user etc.) that - need to be added to the policy at build time. -3. Either produce an updated Reference Policy source or module patch, - depending on whether new classes/constraints have been added. Note - that by default a new module will be generated as a 'module', if it - is required that the module is in the base (unusual), then add an - entry ***<required val="true">*** to the start of the - interface file as shown below: +1. Create any constraints required as these need to be built into the + base module of the Reference Policy. They are added to the + *./refpolicy/policy/constraints*, *mcs* and *mls* files. Again the + SE-PostgreSQL entries in these files give examples (find the + *db_\** class entries). +2. Create any SELinux configuration files (context, user etc.) that + need to be added to the policy at build time. +3. Either produce an updated Reference Policy source or module patch, + depending on whether new classes/constraints have been added. Note + that by default a new module will be generated as a 'module', if it + is required that the module is in the base (unusual), then add an + entry ***\*** to the start of the + interface file as shown below: ``` # @@ -258,40 +262,36 @@ be declared using the *class*, *classpermission*, and *classorder* statements. For reference, describes how new kernel object classes and permissions are added to the -system and is summarised as follows for kernels >= 2.6.33 that use +system and is summarised as follows for kernels \>= 2.6.33 that use dynamic class/perm discovery: -1. Edit *security/selinux/include/classmap.h* in the kernel tree and - add the required definition. This will define the class and/or - permission for use in the kernel; the corresponding symbol - definitions will be automatically generated during the kernel build. - If not defined in the policy, then the class and/or permission will - be handled in accordance with the policy's *handle_unknown* - definition, which can be reject (refuse to load the policy), deny - (deny the undefined class/permission), or allow (allow the undefined - class/permission). *handle_unknown* is set to allow in Fedora - policies. -2. Edit *refpolicy/policy/flask/security_classes* and/or - *access_vectors* in the refpolicy tree and add your definition. - This will define the class and permission for use in the policy. - These are generally added to the class and/or permission at the end - of the existing list of classes or permissions for that class for - backward compatibility with older kernels. The class and/or - permission definition in policy need not line up with the definition - in the kernel's classmap, as the values will be dynamically mapped - by the kernel. Then add allow rules as appropriate to the policy for - the new permissions. - -
-
    -

  1. The SELinux security server does not enforce a decision, it merely +1. Edit *security/selinux/include/classmap.h* in the kernel tree and + add the required definition. This will define the class and/or + permission for use in the kernel; the corresponding symbol + definitions will be automatically generated during the kernel build. + If not defined in the policy, then the class and/or permission will + be handled in accordance with the policy's *handle_unknown* + definition, which can be reject (refuse to load the policy), deny + (deny the undefined class/permission), or allow (allow the undefined + class/permission). *handle_unknown* is set to allow in Fedora + policies. +2. Edit *refpolicy/policy/flask/security_classes* and/or + *access_vectors* in the refpolicy tree and add your definition. + This will define the class and permission for use in the policy. + These are generally added to the class and/or permission at the end + of the existing list of classes or permissions for that class for + backward compatibility with older kernels. The class and/or + permission definition in policy need not line up with the definition + in the kernel's classmap, as the values will be dynamically mapped + by the kernel. Then add allow rules as appropriate to the policy for + the new permissions. + +[^fn_isa_1]: The SELinux security server does not enforce a decision, it merely states whether the operation is allowed or not according to the policy. It is the object manager that enforces the decision of the policy / security server, therefore an object manager must be trusted. This is also true of labeling, the object manager ensures that labels are -applied to their objects as defined by policy.↩

    2. -
-
+applied to their objects as defined by policy. From patchwork Tue Aug 25 08:37:43 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Haines X-Patchwork-Id: 11735173 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 D177717C7 for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B8F0B2074D for ; Tue, 25 Aug 2020 08:38:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=btinternet.com header.i=@btinternet.com header.b="TL/N9Eik" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728951AbgHYIiZ (ORCPT ); Tue, 25 Aug 2020 04:38:25 -0400 Received: from mailomta9-sa.btinternet.com ([213.120.69.15]:35166 "EHLO sa-prd-fep-046.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729003AbgHYIiS (ORCPT ); Tue, 25 Aug 2020 04:38:18 -0400 Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-046.btinternet.com with ESMTP id <20200825083814.RNYH4114.sa-prd-fep-046.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Tue, 25 Aug 2020 09:38:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1598344694; bh=Q88WSTdQzGbFHlFMHrp2oR2+T9Wza1NWJzWqze3a3Bg=; h=From:To:Cc:Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version; b=TL/N9EikDQCHhnmr65fVSD8hXLazN1GGIW4RCRD5qxEJza9t8ua3z+B2NW1sriVQ7W1bgQGk8SQHD3yNzNBrBoKxTADAtLRpZF7AMOTWgObiLOwM8slpOEVzSRPkV9RfJoibLNPxKlnG7zy+vq8LDeLUrtm5Lg4k0SJsdfRsH07qxMbIGym9OYdDwPYAf+eDpCsbSxhGe+Jr9c9hAvEMI/CGQNRnEWgEbbKOYJXLLuqwlkTIW/B/z0XevVcLDScVNm8i4k7MSTT+9RSAx9KNt+5Y/dXuuvlSPRjO8GspVvcImkssZxYjfyXOf+k1ZQryZHdoDoD9bnV0q2+et04EvQ== Authentication-Results: btinternet.com; none X-Originating-IP: [109.155.130.160] X-OWM-Source-IP: 109.155.130.160 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpeeutddtleelheeugefgiefhiedtheeukeffveeitdffgeffieeugeeljeegvefgieenucfkphepuddtledrudehhedrudeftddrudeitdenucevlhhushhtvghrufhiiigvpeduudenucfrrghrrghmpehhvghloheplhhotggrlhhhohhsthdrlhhotggrlhguohhmrghinhdpihhnvghtpedutdelrdduheehrddufedtrdduiedtpdhmrghilhhfrhhomhepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqedprhgtphhtthhopeeophgruhhlsehprghulhdqmhhoohhrvgdrtghomheqpdhrtghpthhtohepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqecuqfftvefrvfeprhhftgekvddvnehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmpdhrtghpthhtohepoehsvghlihhnuhigsehvghgvrhdrkhgvrhhnvghlrdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from localhost.localdomain (109.155.130.160) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9B8A70D599E8B; Tue, 25 Aug 2020 09:38:14 +0100 From: Richard Haines To: paul@paul-moore.com, selinux@vger.kernel.org Cc: Richard Haines Subject: [PATCH 18/18] infiniband_statements: Convert to markdown Date: Tue, 25 Aug 2020 09:37:43 +0100 Message-Id: <20200825083743.6508-19-richard_c_haines@btinternet.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200825083743.6508-1-richard_c_haines@btinternet.com> References: <20200825083743.6508-1-richard_c_haines@btinternet.com> MIME-Version: 1.0 Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Add a TOC to aid navigation and convert to markdown. Signed-off-by: Richard Haines --- src/infiniband_statements.md | 155 ++++++++++++++--------------------- 1 file changed, 61 insertions(+), 94 deletions(-) diff --git a/src/infiniband_statements.md b/src/infiniband_statements.md index 492bdb6..943cee6 100644 --- a/src/infiniband_statements.md +++ b/src/infiniband_statements.md @@ -1,5 +1,8 @@ # InfiniBand Labeling Statements +- [*ibpkeycon*](#ibpkeycon) +- [*ibendportcon*](#ibendportcon) + To support access control for InfiniBand (IB) partitions and subnet management, security contexts are provided for: Partition Keys (Pkey) that are 16 bit numbers assigned to subnets and their IB end ports. An @@ -13,7 +16,7 @@ Note that there are no terminating semi-colons ';' on these statements. The *ibpkeycon* statement is used to label IB partition keys. It is also possible to add a security context to partition keys outside -the policy using the ***semanage ibpkey*** command that will associate the +the policy using the *semanage ibpkey* command that will associate the *pkey* (or range of pkeys) to a security context. **The statement definition is:** @@ -24,53 +27,35 @@ ibpkeycon subnet pkey pkey_context **Where:** - - - - - - - - - - - - - - - - - - - -
ibpkeyconThe ibpkeycon keyword.
subnetIP address in IPv6 format.
pkeyPartition key number or range. The range is separated by a hyphen '-'.
pkey_contextThe security context for the pkey(s).
+*ibpkeycon* + +The *ibpkeycon* keyword. + +*subnet* + +IP address in IPv6 format. + +*pkey* + +Partition key number or range. The range is separated by a hyphen \'\-\'. + +*pkey_context* + +The security context for the pkey(s). **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesYes
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | Yes | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Examples:** @@ -86,8 +71,8 @@ semanage ibpkey -a -t default_ibpkey_t -x fe80:: 0xFFFF ``` The above command will produce the following file: -*/var/lib/selinux/<SELINUXTYPE>/active/ibpkeys.local* -in the default ** policy store and then activate the policy: +*/var/lib/selinux/\/active/ibpkeys.local* +in the default *\* policy store and then activate the policy: ``` # This file is auto-generated by libsemanage @@ -101,7 +86,7 @@ ibpkeycon fe80:: 0xFFFF system_u:object_r:default_ibpkey_t:s0 The *ibendportcon* statement is used to label IB end ports. It is also possible to add a security context to ports outside the -policy using the 'semanage ibendport' command that will associate the +policy using the *semanage ibendport* command that will associate the end port to a security context. **The statement definition is:** @@ -112,53 +97,35 @@ ibendportcon device_id port_number port_context **Where:** - - - - - - - - - - - - - - - - - - - -
ibendportconThe ibendportcon keyword.
device_idDevice name
port_numberSingle port number.
port_contextThe security context for the port.
+*ibendportcon* + +The *ibendportcon* keyword. + +*device_id* + +Device name + +*port_number* + +Single port number. + +*port_context* + +The security context for the port. **The statement is valid in:** - - - - - - - - - - - - - - - - - - - - - - - -
Monolithic PolicyBase PolicyModule Policy
YesYesYes
Conditional Policy if Statementoptional Statementrequire Statement
NoNoNo
+Policy Type + +| Monolithic Policy | Base Policy | Module Policy | +| ----------------------- | ----------------------- | ----------------------- | +| Yes | Yes | Yes | + +Conditional Policy Statements + +| *if* Statement | *optional* Statement | *require* Statement | +| ----------------------- | ----------------------- | ----------------------- | +| No | No | No | **Examples:** @@ -174,8 +141,8 @@ semanage ibendport -a -t opensm_ibendport_t -z mlx4_0 2 ``` This command will produce the following file -*/var/lib/selinux/<SELINUXTYPE>/active/ibendports.local* in the default -** policy store and then activate the policy: +*/var/lib/selinux/\/active/ibendports.local* in the default +*\* policy store and then activate the policy: ``` # This file is auto-generated by libsemanage