From patchwork Fri Dec 11 16:26:13 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Yuli Khodorkovskiy X-Patchwork-Id: 7831621 Return-Path: X-Original-To: patchwork-selinux@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 8FB47BEEE1 for ; Fri, 11 Dec 2015 17:29:46 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3DDCD20431 for ; Fri, 11 Dec 2015 17:29:46 +0000 (UTC) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C044202FE for ; Fri, 11 Dec 2015 17:29:39 +0000 (UTC) X-TM-IMSS-Message-ID: <520ce01000074816@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.242.1]) by nsa.gov ([10.208.42.193]) with ESMTP (TREND IMSS SMTP Service 7.1) id 520ce01000074816 ; Fri, 11 Dec 2015 12:24:03 -0500 Received: from prometheus.infosec.tycho.ncsc.mil (prometheus [192.168.25.40]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id tBBHLYxJ024248; Fri, 11 Dec 2015 12:21:36 -0500 Received: from tarius.tycho.ncsc.mil (tarius.infosec.tycho.ncsc.mil [144.51.242.1]) by prometheus.infosec.tycho.ncsc.mil (8.15.2/8.15.2) with ESMTP id tBBGR3lh027096 for ; Fri, 11 Dec 2015 11:27:03 -0500 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id tBBGR3Yg017363 for ; Fri, 11 Dec 2015 11:27:03 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A1CeBAD092pW/6u/HtjNBQICAQ X-IronPort-AV: E=Sophos;i="5.20,414,1444708800"; d="scan'208";a="5020168" Received: from emvm-gh1-uea08.nsa.gov ([10.208.42.193]) by goalie.tycho.ncsc.mil with ESMTP; 11 Dec 2015 11:26:44 -0500 X-TM-IMSS-Message-ID: <51d8309f000732c7@nsa.gov> Received: from exchange10.columbia.tresys.com (exchange10.columbia.tresys.com [216.30.191.171]) by nsa.gov ([10.208.42.193]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES256-SHA (256/256)) id 51d8309f000732c7 ; Fri, 11 Dec 2015 11:26:31 -0500 Received: from localhost (10.1.14.248) by Exchange10.columbia.tresys.com (192.168.243.126) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 11 Dec 2015 11:26:16 -0500 From: Yuli Khodorkovskiy To: Subject: [PATCH] secilc/docs: Convert DocBook documentation into github markdown Date: Fri, 11 Dec 2015 11:26:13 -0500 Message-ID: <1449851173-9054-1-git-send-email-ykhodorkovskiy@tresys.com> X-Mailer: git-send-email 2.4.3 MIME-Version: 1.0 X-TM-AS-MML: disable X-MIME-Autoconverted: from quoted-printable to 8bit by prometheus.infosec.tycho.ncsc.mil id tBBGR3lh027096 X-Mailman-Approved-At: Fri, 11 Dec 2015 12:14:35 -0500 X-BeenThere: selinux@tycho.nsa.gov X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: Errors-To: selinux-bounces@tycho.nsa.gov Sender: "Selinux" X-Virus-Scanned: ClamAV using ClamSMTP Converting to github markdown allows for easier integration with the SELinux project wiki and viewing of documentation directly on github without creating PDFs or reading through DocBook XML. The conversion of DocBook to github markdown would not format tables or keyword links properly. By maintaining the documentation in github markdown in the repository, the content is well formatted with a table of contents when viewing in the github wiki or in the repository. The migration from DocBook to github markdown was done using Pandoc and manual fixups. Mappings of CIL keywords to headings that were lost in the DocBook conversion were added back. An introduction and design philosphy was also pulled from the SELinux project wiki to provide more cohesion to the current documentation. Running make will now convert the github markdown into PDF and HTML. Signed-off-by: Yuli Khodorkovskiy --- secilc/.gitignore | 1 + secilc/docs/CIL_Reference_Guide.xml | 573 ---------------- secilc/docs/Makefile | 86 ++- secilc/docs/README.md | 154 +++++ secilc/docs/cil_access_vector_rules.md | 428 ++++++++++++ secilc/docs/cil_access_vector_rules.xml | 518 --------------- secilc/docs/cil_call_macro_statements.md | 130 ++++ secilc/docs/cil_call_macro_statements.xml | 174 ----- secilc/docs/cil_class_and_permission_statements.md | 522 +++++++++++++++ .../docs/cil_class_and_permission_statements.xml | 604 ----------------- secilc/docs/cil_conditional_statements.md | 222 +++++++ secilc/docs/cil_conditional_statements.xml | 269 -------- secilc/docs/cil_constraint_statements.md | 313 +++++++++ secilc/docs/cil_constraint_statements.xml | 363 ---------- secilc/docs/cil_container_statements.md | 296 +++++++++ secilc/docs/cil_container_statements.xml | 424 ------------ secilc/docs/cil_context_statement.md | 77 +++ secilc/docs/cil_context_statement.xml | 100 --- secilc/docs/cil_default_object_statements.md | 183 +++++ secilc/docs/cil_default_object_statements.xml | 215 ------ secilc/docs/cil_file_labeling_statements.md | 228 +++++++ secilc/docs/cil_file_labeling_statements.xml | 302 --------- secilc/docs/cil_introduction.md | 59 ++ secilc/docs/cil_mls_labeling_statements.md | 638 ++++++++++++++++++ secilc/docs/cil_mls_labeling_statements.xml | 733 --------------------- secilc/docs/cil_network_labeling_statements.md | 201 ++++++ secilc/docs/cil_network_labeling_statements.xml | 244 ------- secilc/docs/cil_policy_config_statements.md | 113 ++++ secilc/docs/cil_policy_config_statements.xml | 118 ---- secilc/docs/cil_reference_guide.md | 298 +++++++++ secilc/docs/cil_role_statements.md | 320 +++++++++ secilc/docs/cil_role_statements.xml | 374 ----------- secilc/docs/cil_sid_statements.md | 125 ++++ secilc/docs/cil_sid_statements.xml | 142 ---- secilc/docs/cil_type_statements.md | 502 ++++++++++++++ secilc/docs/cil_type_statements.xml | 581 ---------------- secilc/docs/cil_user_statements.md | 455 +++++++++++++ secilc/docs/cil_user_statements.xml | 528 --------------- secilc/docs/cil_xen_statements.md | 200 ++++++ secilc/docs/cil_xen_statements.xml | 227 ------- 40 files changed, 5518 insertions(+), 6522 deletions(-) delete mode 100644 secilc/docs/CIL_Reference_Guide.xml create mode 100644 secilc/docs/README.md create mode 100644 secilc/docs/cil_access_vector_rules.md delete mode 100644 secilc/docs/cil_access_vector_rules.xml create mode 100644 secilc/docs/cil_call_macro_statements.md delete mode 100644 secilc/docs/cil_call_macro_statements.xml create mode 100644 secilc/docs/cil_class_and_permission_statements.md delete mode 100644 secilc/docs/cil_class_and_permission_statements.xml create mode 100644 secilc/docs/cil_conditional_statements.md delete mode 100644 secilc/docs/cil_conditional_statements.xml create mode 100644 secilc/docs/cil_constraint_statements.md delete mode 100644 secilc/docs/cil_constraint_statements.xml create mode 100644 secilc/docs/cil_container_statements.md delete mode 100644 secilc/docs/cil_container_statements.xml create mode 100644 secilc/docs/cil_context_statement.md delete mode 100644 secilc/docs/cil_context_statement.xml create mode 100644 secilc/docs/cil_default_object_statements.md delete mode 100644 secilc/docs/cil_default_object_statements.xml create mode 100644 secilc/docs/cil_file_labeling_statements.md delete mode 100644 secilc/docs/cil_file_labeling_statements.xml create mode 100644 secilc/docs/cil_introduction.md create mode 100644 secilc/docs/cil_mls_labeling_statements.md delete mode 100644 secilc/docs/cil_mls_labeling_statements.xml create mode 100644 secilc/docs/cil_network_labeling_statements.md delete mode 100644 secilc/docs/cil_network_labeling_statements.xml create mode 100644 secilc/docs/cil_policy_config_statements.md delete mode 100644 secilc/docs/cil_policy_config_statements.xml create mode 100644 secilc/docs/cil_reference_guide.md create mode 100644 secilc/docs/cil_role_statements.md delete mode 100644 secilc/docs/cil_role_statements.xml create mode 100644 secilc/docs/cil_sid_statements.md delete mode 100644 secilc/docs/cil_sid_statements.xml create mode 100644 secilc/docs/cil_type_statements.md delete mode 100644 secilc/docs/cil_type_statements.xml create mode 100644 secilc/docs/cil_user_statements.md delete mode 100644 secilc/docs/cil_user_statements.xml create mode 100644 secilc/docs/cil_xen_statements.md delete mode 100644 secilc/docs/cil_xen_statements.xml diff --git a/secilc/.gitignore b/secilc/.gitignore index 98c367a..f659d80 100644 --- a/secilc/.gitignore +++ b/secilc/.gitignore @@ -4,3 +4,4 @@ policy.* file_contexts docs/html docs/pdf +docs/tmp diff --git a/secilc/docs/CIL_Reference_Guide.xml b/secilc/docs/CIL_Reference_Guide.xml deleted file mode 100644 index e089079..0000000 --- a/secilc/docs/CIL_Reference_Guide.xml +++ /dev/null @@ -1,573 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - ]> - -
- - Common Interface Language (CIL) Reference Guide - - - - CIL Information - - Not all possible alternate statement permutations are shown, however there should be enough variation to work out any other valid formats. There is also an example policy.cil file shown in the Appendix. - The MLS components on contexts and user statements must be declared even if the policy does not support MCS/MLS. - The CIL compiler will not build a policy unless it also has as a minimum: one allow rule, one sid, sidorder and sidcontext statement. - The role object_r must be explicitly associated to contexts used for labeling objects. The original checkpolicy(8) and checkmodule(8) compilers did this by default - CIL does not. - Be aware that CIL allows class statements to be declared in a namespace, however the policy author needs to note that applications (and the kernel) generally reference a class by its well known class identifier (e.g. zygote) however if declared in a namespace (e.g. (block zygote (class zygote (...))) or (block zygote (class class (...)))) it would be prefixed with that namespace (e.g. zygote.zygote or zygote.class). Unless the application / kernel code was updated the class would never be resolved, therefore it is recommended that classes are declared in the global namespace. - Where possible use typeattribute's when defining source/target allow rules instead of multiple allow rules with individual type's. This will lead to the generation of much smaller kernel policy files. - The site explains the language however some of the statement definitions are dated. - - - Declarations - Declarations may be named or anonymous and have three different forms: - - Named declarations - These create new objects that introduce a name or identifier, for example: - (type process) - creates a type with an identifier of process. - (typeattribute domain) - creates a typeattribute with an identifier of domain. - (class file (read write)) - creates a class with an identifier of file that has read and write permissions associated to it. - The list of declaration type statement keywords are: - - block - optional - common - class - classmap - classmapping - sid - user - role - roleattribute - type - classpermission - classpermissionset - typeattribute - typealias - tunable - sensitivity - sensitivityalias - category - categoryalias - categoryset - level - levelrange - context - ipaddr - macro - policycap - - - Explicit anonymous declarations - These are currently restricted to IP addesses where they can be declared directly in statements by enclosing them within parentheses e.g. (127.0.0.1) or (::1). See the Network Labeling Statements section for examples. - Anonymous declarations - These have been previously declared and the object already exists, therefore they may be referenced by their name or identifier within statements. For example the following declare all the components required to specify a context: - - - now a portcon statement can be defined that uses these individual components to build a context as follows: - - - - - - - Definitions - Statements that build on the objects, for example: - - (typeattributeset domain (process)) - Adds the type 'process' to the typeattribute 'domain'. - (allow domain process (file (read write)))) - Adds an allow rule referencing domain, process and the file class. - - Definitions may be repeated many times throughout the policy. Duplicates will resolve to a single definition during compilation. - - - Symbol Character Set - Symbols (any string not enclosed in double quotes) must only contain alphanumeric [a-z A-Z] [0-9] characters plus the following special characters: \.@=/-_$%@+!|&^: - However symbols are checked for any specific character set limitations, for example: - - Names or identifiers must start with an alpa character [a-z A-Z], the remainder may be alphanumeric [a-z A-Z] [0-9] characters plus underscore [_] or hyphen [-]. - IP addresses must conform to IPv4 or IPv6 format. - Memory, ports, irqs must be numeric [0-9]. - - - - String Character Set - Strings are enclosed within double quotes (e.g. "This is a string"), and may contain any character except the double quote ("). - - - Comments - Comments start with a semicolon ';' and end when a new line is started. - - - Namespaces - CIL supports namespaces via containers such as the block statement. When a block is resolved to form the parent / child relationship a dot '.' is used, for example the following allow rule: - - - will resolve to the following kernel policy language statement: - - - - Global Namespace - CIL has a global namespace that is always present. Any symbol that is declared outside a container is in the global namespace. To reference a symbol in global namespace, the symbol should be prefixed with a dot '.' as shown in the following example: - - - Should the symbol not be prefixed with a dot, the current namespace would be searched first and then the global namespace (provided there is not a symbol of that name in the current namespace). - - - Expressions - Expressions may occur in the following CIL statements: - - booleanif - tunableif - classpermissionset - typeattributeset - roleattributeset - categoryset - constrain - mlsconstrain - validatetrans - validatetrans - - CIL expressions use the prefix or Polish notation and may be nested (note that the kernel policy language uses postfix or reverse Polish notation). The syntax is as follows, where the parenthesis are part of the syntax: - - - The number of expr_set's in an expr is dependent on the statement type (there are four different classes as defined below) that also influence the valid expr_key entries (e.g. dom, domby, incomp are only allowed in constraint statements). - - - - - - - - - expr_key - - - classpermissionset - roleattributeset - typeattributeset - - - categoryset - - - booleanif - tunableif - - - constrain - mlsconstrain - validatetrans - mlsvalidatetrans - - - - - dom - - - - - - - - - - - - X - - - - - domby - - - - - - - - - - - - X - - - - - incomp - - - - - - - - - - - - X - - - - - eq - - - - - - - - - X - - - X - - - - - ne - - - - - - - - - X - - - X - - - - - and - - - X - - - X - - - X - - - X - - - - - or - - - X - - - X - - - X - - - X - - - - - not - - - X - - - X - - - X - - - X - - - - - xor - - - X - - - X - - - X - - - - - - - - all - - - X - - - X - - - - - - - - - - - range - - - - - - X - - - - - - - - - - - - - - The classpermissionset, -roleattributeset and typeattributeset statements allow expr_set to mix names and exprs with expr_key values of: and, or, xor, not, all as shown in the examples: - This example includes all fs_type type entries except file.usermodehelper and file.proc_security in the associated typeattribute identifier all_fs_type_except_usermodehelper_and_proc_security: - - - The cps_1 classpermissionset identifier includes all permissions except load_policy and setenforce: - - - - This example includes all permissions in the associated classpermissionset identifer security_all_perms: - - - - - - The categoryset statement allows expr_set to mix names and expr_key values of: and, or, not, xor, all, range as shown in the examples. - Category expressions are also allowed in sensitivitycategory, level, and levelrange statements. - - - - The booleanif and tunableif statements only allow an expr_set to have one name or expr with expr_key values of and, or, xor, not, eq, neq as shown in the examples: - - - - - - - - The constrain, mlsconstrain, validatetrans and mlsvalidatetrans statements only allow an expr_set to have one name or expr with expr_key values of and, or, not, all, eq, neq, dom, domby, incomp. When expr_key is dom, domby or incomp, it must be followed by a string (e.g. h1, l2) and another string or a set of names. The following examples show CIL constraint statements and their policy language equivalents: - - - - - - - - - - Name String - Used to define macro statement parameter string types: - - - Alternatively: - - - - - - self - The self keyword may be used as the target in AVC rule statements, and means that the target is the same as the source as shown in the following example:. - - - - - &policy_config_statements; - &container_statements; - &call_macro_statements; - &default_object_statements; - &user_statements; - &role_statements; - &type_statements; - &class_and_permission_statements; - &access_vector_rules; - &conditional_statements; - &constraint_statements; - &mls_labeling_statements; - &context_statement; - &sid_statements; - &file_labeling_statements; - &network_labeling_statements; - &xen_statements; - - - - Example CIL Policy - This is the example policy.cil file taken from the CIL compiler source code. - &policy_cil; - - - - -
- - diff --git a/secilc/docs/Makefile b/secilc/docs/Makefile index 1655f59..bcbc2e3 100644 --- a/secilc/docs/Makefile +++ b/secilc/docs/Makefile @@ -1,41 +1,61 @@ -HTMLDIR ?= ./html -PDFDIR ?= ./pdf +CWD ?= $(shell pwd) +HTMLDIR ?= $(CWD)/html +PDFDIR ?= $(CWD)/pdf +TMPDIR ?= $(CWD)/tmp +TESTDIR ?= $(CWD)/../test + +# All the markdown files that make up the guide: +FILE_LIST ?= cil_introduction.md \ + cil_reference_guide.md \ + cil_access_vector_rules.md \ + cil_call_macro_statements.md \ + cil_class_and_permission_statements.md \ + cil_conditional_statements.md \ + cil_constraint_statements.md \ + cil_container_statements.md \ + cil_context_statement.md \ + cil_default_object_statements.md \ + cil_file_labeling_statements.md \ + cil_mls_labeling_statements.md \ + cil_network_labeling_statements.md \ + cil_policy_config_statements.md \ + cil_role_statements.md \ + cil_sid_statements.md \ + cil_type_statements.md \ + cil_user_statements.md \ + cil_xen_statements.md + +PANDOC_FILE_LIST = $(addprefix $(TMPDIR)/,$(FILE_LIST)) + +PDF_OUT=CIL_Reference_Guide.pdf +HTML_OUT=CIL_Reference_Guide.html +PANDOC = pandoc -# The CIL Reference Guide first part -CIL_REF_GUIDE = CIL_Reference_Guide.xml -# All the docbook files that make up the guide: -FILE_LIST ?= $(CIL_REF_GUIDE) $(wildcard cil*.xml) -# xmlto generates a *.proc file that can be removed. -PROC_FILE = CIL_Reference_Guide.proc - -# look for xmlto and dblatex packages -XMLTO = $(shell which xmlto 2> /dev/null | grep / | head -n1) -DBLATEX = $(shell which dblatex 2> /dev/null | grep / | head -n1) +all: html pdf -# If no xmlto then exit as cannot proceed. -ifeq ($(XMLTO),) -$(error xmlto package not found - install package.) -endif +$(TMPDIR): + mkdir -p $(TMPDIR) -all: html pdf +$(TMPDIR)/%.md: %.md | $(TMPDIR) + cp -f $< $(TMPDIR)/ + @# Substitute markdown links for conversion into PDF links + sed -i -re 's:(\[`[^`]*`\])\([^#]*([^\)]):\1\(\2:g' $@ -html: $(FILE_LIST) - $(XMLTO) html $(CIL_REF_GUIDE) - @mkdir -p $(HTMLDIR) - @for m in *.html; do if [ -f $$m ]; then mv $$m $(HTMLDIR); fi; done - @rm -f $(PROC_FILE) +$(TMPDIR)/policy.cil: $(TESTDIR)/policy.cil + cp -f $< $@ + @# add a title for the TOC to policy.cil. This is needed to play nicely with the PDF conversion. + sed -i '1i Example Policy\n=========\n```' $@ + echo '```' >> $@ +html: $(PANDOC_FILE_LIST) $(TMPDIR)/policy.cil + mkdir -p $(HTMLDIR) + $(PANDOC) -t html $^ -o $(HTMLDIR)/$(HTML_OUT) -pdf: $(FILE_LIST) -# Check if dblatex is available -ifeq ($(DBLATEX),) - $(error dblatex package not found - install package for a pdf document.) -endif - $(XMLTO) --with-dblatex pdf $(CIL_REF_GUIDE) - @mkdir -p $(PDFDIR) - @for m in *.pdf; do if [ -f $$m ]; then mv $$m $(PDFDIR); fi; done - @rm -f $(PROC_FILE) +pdf: $(PANDOC_FILE_LIST) $(TMPDIR)/policy.cil + mkdir -p $(PDFDIR) + $(PANDOC) --standalone --toc --latex-engine=xelatex $^ -o $(PDFDIR)/$(PDF_OUT) clean: - @rm -rf html/ - @rm -rf pdf/ + rm -rf $(HTMLDIR) + rm -rf $(PDFDIR) + rm -rf $(TMPDIR) diff --git a/secilc/docs/README.md b/secilc/docs/README.md new file mode 100644 index 0000000..aada78f --- /dev/null +++ b/secilc/docs/README.md @@ -0,0 +1,154 @@ +CIL (Common Intermediate Language) +=============== +## Table of Contents + +* [Introduction](cil_introduction.md#Introduction) + * [Design Philosophy](cil_introduction.md#design-philosophy) + * [Goals and Primary Features](cil_introduction.md#goals-and-primary-features) + * [Design Overview](cil_introduction.md#design-overview) + +* [CIL Information](cil_reference_guide.md#cil-information) + * [Declarations](cil_reference_guide.md#declarations) + * [Definitions](cil_reference_guide.md#definitions) + * [Symbol Character Set](cil_reference_guide.md#symbol-character-set) + * [String Character Set](cil_reference_guide.md#string-character-set) + * [Comments](cil_reference_guide.md#comments) + * [Namespaces](cil_reference_guide.md#namespaces) + * [Global Namespace](cil_reference_guide.md#global-namespace) + * [Expressions](cil_reference_guide.md#expressions) + * [Name String](cil_reference_guide.md#name-string) + * [self](cil_reference_guide.md#self) + * [Example CIL Policy](../test/policy.cil) + +* [Access Vector Rules](cil_access_vector_rules.md#access-vector-rules) + * [allow](cil_access_vector_rules.md#allow) + * [auditallow](cil_access_vector_rules.md#auditallow) + * [dontaudit](cil_access_vector_rules.md#dontaudit) + * [neverallow](cil_access_vector_rules.md#neverallow) + * [allowx](cil_access_vector_rules.md#allowx) + * [auditallowx](cil_access_vector_rules.md#auditallowx) + * [dontauditx](cil_access_vector_rules.md#dontauditx) + * [neverallowx](cil_access_vector_rules.md#neverallowx) + +* [Call / Macro Statements](cil_call_macro_statements.md#call--macro-statements) + * [call](cil_call_macro_statements.md#call) + * [macro](cil_call_macro_statements.md#macro) + +* [Class and Permission Statements](cil_class_and_permission_statements.md#class-and-permission-statements) + * [common](cil_class_and_permission_statements.md#common) + * [classcommon](cil_class_and_permission_statements.md#classcommon) + * [class](cil_class_and_permission_statements.md#class) + * [classorder](cil_class_and_permission_statements.md#classorder) + * [classpermission](cil_class_and_permission_statements.md#classpermission) + * [classpermissionset](cil_class_and_permission_statements.md#classpermissionset) + * [classmap](cil_class_and_permission_statements.md#classmap) + * [classmapping](cil_class_and_permission_statements.md#classmapping) + * [permissionx](cil_class_and_permission_statements.md#permissionx) + +* [Conditional Statements](cil_conditional_statements.md#conditional-statements) + * [boolean](cil_conditional_statements.md#boolean) + * [booleanif](cil_conditional_statements.md#booleanif) + * [tunable](cil_conditional_statements.md#tunable) + * [tunableif](cil_conditional_statements.md#tunableif) + +* [Constraint Statements](cil_constraint_statements.md#constraint-statements) + * [constrain](cil_constraint_statements.md#constrain) + * [validatetrans](cil_constraint_statements.md#validatetrans) + * [mlsconstrain](cil_constraint_statements.md#mlsconstrain) + * [mlsvalidatetrans](cil_constraint_statements.md#mlsvalidatetrans) + +* [Container Statements](cil_container_statements.md#container-statements) + * [block](cil_container_statements.md#block) + * [blockabstract](cil_container_statements.md#blockabstract) + * [blockinherit](cil_container_statements.md#blockinherit) + * [optional](cil_container_statements.md#optional) + * [in](cil_container_statements.md#in) + +* [Context Statement](cil_context_statement.md#context-statement) + * [context](cil_context_statement.md#context) + +* [Default Object Statements](cil_default_object_statements.md#default-object-statements) + * [defaultuser](cil_default_object_statements.md#defaultuser) + * [defaultrole](cil_default_object_statements.md#defaultrole) + * [defaulttype](cil_default_object_statements.md#defaulttype) + * [defaultrange](cil_default_object_statements.md#defaultrange) + +* [File Labeling Statements](cil_file_labeling_statements.md#file-labeling-statements) + * [filecon](cil_file_labeling_statements.md#filecon) + * [fsuse](cil_file_labeling_statements.md#fsuse) + * [genfscon](cil_file_labeling_statements.md#genfscon) + +* [Multi-Level Security Labeling Statements](cil_mls_labeling_statements.md#multi-level-security-labeling-statements) + * [sensitivity](cil_mls_labeling_statements.md#sensitivity) + * [sensitivityalias](cil_mls_labeling_statements.md#sensitivityalias) + * [sensitivityaliasactual](cil_mls_labeling_statements.md#sensitivityaliasactual) + * [sensitivityorder](cil_mls_labeling_statements.md#sensitivityorder) + * [category](cil_mls_labeling_statements.md#category) + * [categoryalias](cil_mls_labeling_statements.md#categoryalias) + * [categoryaliasactual](cil_mls_labeling_statements.md#categoryaliasactual) + * [categoryorder](cil_mls_labeling_statements.md#categoryorder) + * [categoryset](cil_mls_labeling_statements.md#categoryset) + * [sensitivitycategory](cil_mls_labeling_statements.md#sensitivitycategory) + * [level](cil_mls_labeling_statements.md#level) + * [levelrange](cil_mls_labeling_statements.md#levelrange) + * [rangetransition](cil_mls_labeling_statements.md#rangetransition) + * [mlsconstrain](cil_mls_labeling_statements.md#mlsconstrain) + * [mlsvalidatetrans](cil_mls_labeling_statements.md#mlsvalidatetrans) + +* [Network Labeling Statements](cil_network_labeling_statements.md#network-labeling-statements) + * [ipaddr](cil_network_labeling_statements.md#ipaddr) + * [netifcon](cil_network_labeling_statements.md#netifcon) + * [nodecon](cil_network_labeling_statements.md#nodecon) + * [portcon](cil_network_labeling_statements.md#portcon) + +* [Policy Configuration Statements](cil_policy_config_statements.md#policy-configuration-statements) + * [mls](cil_policy_config_statements.md#mls) + * [handleunknown](cil_policy_config_statements.md#handleunknown) + * [policycap](cil_policy_config_statements.md#policycap) + +* [Role Statements](cil_role_statements.md#role-statements) + * [role](cil_role_statements.md#role) + * [roletype](cil_role_statements.md#roletype) + * [roleattribute](cil_role_statements.md#roleattribute) + * [roleattributeset](cil_role_statements.md#roleattributeset) + * [roleallow](cil_role_statements.md#roleallow) + * [roletransition](cil_role_statements.md#roletransition) + * [rolebounds](cil_role_statements.md#rolebounds) + +* [SID Statements](cil_sid_statements.md#sid-statements) + * [sid](cil_sid_statements.md#sid) + * [sidorder](cil_sid_statements.md#sidorder) + * [sidcontext](cil_sid_statements.md#sidcontext) + +* [Type Statements](cil_type_statements.md#type-statements) + * [type](cil_type_statements.md#type) + * [typealias](cil_type_statements.md#typealias) + * [typealiasactual](cil_type_statements.md#typealiasactual) + * [typeattribute](cil_type_statements.md#typeattribute) + * [typeattributeset](cil_type_statements.md#typeattributeset) + * [typebounds](cil_type_statements.md#typebounds) + * [typechange](cil_type_statements.md#typechange) + * [typemember](cil_type_statements.md#typemember) + * [typetransition](cil_type_statements.md#typetransition) + * [typepermissive](cil_type_statements.md#typepermissive) + +* [User Statements](cil_user_statements.md#user-statements) + * [user](cil_user_statements.md#user) + * [userrole](cil_user_statements.md#userrole) + * [userattribute](cil_user_statements.md#userattribute) + * [userattributeset](cil_user_statements.md#userattributeset) + * [userlevel](cil_user_statements.md#userlevel) + * [userrange](cil_user_statements.md#userrange) + * [userbounds](cil_user_statements.md#userbounds) + * [userprefix](cil_user_statements.md#userprefix) + * [selinuxuser](cil_user_statements.md#selinuxuser) + * [selinuxuserdefault](cil_user_statements.md#selinuxuserdefault) + +* [Xen Statements](cil_xen_statements.md#xen-statements) + * [iomemcon](cil_xen_statements.md#iomemcon) + * [ioportcon](cil_xen_statements.md#ioportcon) + * [pcidevicecon](cil_xen_statements.md#pcidevicecon) + * [pirqcon](cil_xen_statements.md#pirqcon) + * [devicetreecon](cil_xen_statements.md#devicetreecon) + +* [Example Policy](../test/policy.cil#example-policy) diff --git a/secilc/docs/cil_access_vector_rules.md b/secilc/docs/cil_access_vector_rules.md new file mode 100644 index 0000000..9c03c71 --- /dev/null +++ b/secilc/docs/cil_access_vector_rules.md @@ -0,0 +1,428 @@ +Access Vector Rules +=================== + +allow +----- + +Specifies the access allowed between a source and target type. Note that access may be refined by constraint rules based on the source, target and class ([`validatetrans`](cil_constraint_statements.md#validatetrans) or [`mlsvalidatetrans`](cil_constraint_statements.md#mlsvalidatetrans)) or source, target class and permissions ([`constrain`](cil_constraint_statements.md#constrain) or [`mlsconstrain`](cil_constraint_statements.md#mlsconstrain) statements). + +**Rule definition:** + + (allow source_id target_id|self classpermissionset_id ...) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

allow

The allow keyword.

source_id

A single previously defined source type, typealias or typeattribute identifier.

target_id

A single previously defined target type, typealias or typeattribute identifier.

+

The self keyword may be used instead to signify that source and target are the same.

classpermissionset_id

A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers.

+ +**Examples:** + +These examples show a selection of possible permutations of [`allow`](cil_access_vector_rules.md#allow) rules: + + (class binder (impersonate call set_context_mgr transfer receive)) + (class property_service (set)) + (class zygote (specifyids specifyrlimits specifycapabilities specifyinvokewith specifyseinfo)) + + (classpermission cps_zygote) + (classpermissionset cps_zygote (zygote (not (specifyids)))) + + (classmap android_classes (set_1 set_2 set_3)) + + (classmapping android_classes set_1 (binder (all))) + (classmapping android_classes set_1 (property_service (set))) + (classmapping android_classes set_1 (zygote (not (specifycapabilities)))) + + (classmapping android_classes set_2 (binder (impersonate call set_context_mgr transfer))) + (classmapping android_classes set_2 (zygote (specifyids specifyrlimits specifycapabilities specifyinvokewith))) + + (classmapping android_classes set_3 cps_zygote) + (classmapping android_classes set_3 (binder (impersonate call set_context_mgr))) + + (block av_rules + (type type_1) + (type type_2) + (type type_3) + (type type_4) + (type type_5) + + (typeattribute all_types) + (typeattributeset all_types (all)) + + ; These examples have named and anonymous classpermissionset's and + ; classmap/classmapping statements + (allow type_1 self (property_service (set))) ; anonymous + (allow type_2 self (zygote (specifyids))) ; anonymous + (allow type_3 self cps_zygote) ; named + (allow type_4 self (android_classes (set_3))) ; classmap/classmapping + (allow all_types all_types (android_classes (set_2))) ; classmap/classmapping + + ;; This rule will cause the build to fail unless --disable-neverallow + ; (neverallow type_5 all_types (property_service (set))) + (allow type_5 type_5 (property_service (set))) + (allow type_1 all_types (property_service (set))) + ) + +auditallow +---------- + +Audit the access rights defined if there is a valid allow rule. Note: It does NOT allow access, it only audits the event. + +**Rule definition:** + + (auditallow source_id target_id|self classpermissionset_id ...) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

auditallow

The auditallow keyword.

source_id

A single previously defined source type, typealias or typeattribute identifier.

target_id

A single previously defined target type, typealias or typeattribute identifier.

+

The self keyword may be used instead to signify that source and target are the same.

classpermissionset_id

A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers.

+ +**Example:** + +This example will log an audit event whenever the corresponding [`allow`](cil_access_vector_rules.md#allow) rule grants access to the specified permissions: + + (allow release_app.process secmark_demo.browser_packet (packet (send recv append bind))) + + (auditallow release_app.process secmark_demo.browser_packet (packet (send recv))) + + +dontaudit +--------- + +Do not audit the access rights defined when access denied. This stops excessive log entries for known events. + +Note that these rules can be omitted by the CIL compiler command line parameter `-D` or `--disable-dontaudit` flags. + +**Rule definition:** + + (dontaudit source_id target_id|self classpermissionset_id ...) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

dontaudit

The dontaudit keyword.

source_id

A single previously defined source type, typealias or typeattribute identifier.

target_id

A single previously defined target type, typealias or typeattribute identifier.

+

The self keyword may be used instead to signify that source and target are the same.

classpermissionset_id

A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers.

+ +**Example:** + +This example will not audit the denied access: + + (dontaudit zygote.process self (capability (fsetid))) + +neverallow +---------- + +Never allow access rights defined. This is a compiler enforced action that will stop compilation until the offending rules are modified. + +Note that these rules can be over-ridden by the CIL compiler command line parameter `-N` or `--disable-neverallow` flags. + +**Rule definition:** + + (neverallow source_id target_id|self classpermissionset_id ...) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

neverallow

The neverallow keyword.

source_id

A single previously defined source type, typealias or typeattribute identifier.

target_id

A single previously defined target type, typealias or typeattribute identifier.

+

The self keyword may be used instead to signify that source and target are the same.

classpermissionset_id

A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers.

+ +**Example:** + +This example will not compile as `type_3` is not allowed to be a source type for the [`allow`](cil_access_vector_rules.md#allow) rule: + + (class property_service (set)) + + (block av_rules + (type type_1) + (type type_2) + (type type_3) + (typeattribute all_types) + (typeattributeset all_types ((all))) + + (neverallow type_3 all_types (property_service (set))) + ; This rule will fail compilation: + (allow type_3 self (property_service (set))) + ) + +allowx +------ + +Specifies the access allowed between a source and target type using extended permissions. Unlike the [`allow`](cil_access_vector_rules.md#allow) statement, the statements [`validatetrans`](cil_constraint_statements.md#validatetrans), [`mlsvalidatetrans`](cil_constraint_statements.md#mlsvalidatetrans), [`constrain`](cil_constraint_statements.md#constrain), and [`mlsconstrain`](cil_constraint_statements.md#mlsconstrain) do not limit accesses granted by [`allowx`](cil_access_vector_rules.md#allowx). + +**Rule definition:** + + (allowx source_id target_id|self permissionx_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

allowx

The allowx keyword.

source_id

A single previously defined source type, typealias, or typeattribute identifier.

target_id

A single previously defined target type, typealias, or typeattribute identifier.

+

The self keyword may be used instead to signify that source and target are the same.

permissionx_id

A single named or anonymous permissionx.

+ +**Examples:** + +These examples show a selection of possible permutations of [`allowx`](cil_access_vector_rules.md#allowx) rules: + + (allowx type_1 type_2 (ioctl tcp_socket (range 0x2000 0x20FF))) + + (permissionx ioctl_nodebug (ioctl udp_socket (not (range 0x4000 0x4010)))) + (allowx type_3 type_4 ioctl_nodebug) + + + +auditallowx +----------- + +Audit the access rights defined if there is a valid [`allowx`](cil_access_vector_rules.md#allowx) rule. It does NOT allow access, it only audits the event. + +**Rule definition:** + + (auditallowx source_id target_id|self permissionx_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

auditallowx

The auditallowx keyword.

source_id

A single previously defined source type, typealias or typeattribute identifier.

target_id

A single previously defined target type, typealias or typeattribute identifier.

+

The self keyword may be used instead to signify that source and target are the same.

permissionx_id

A single named or anonymous permissionx.

+ +**Examples:** + +This example will log an audit event whenever the corresponding [`allowx`](cil_access_vector_rules.md#allowx) rule grants access to the specified extended permissions: + + (allowx type_1 type_2 (ioctl tcp_socket (range 0x2000 0x20FF))) + + (auditallowx type_1 type_2 (ioctl tcp_socket (range 0x2005 0x2010))) + + +dontauditx +---------- + +Do not audit the access rights defined when access denied. This stops excessive log entries for known events. + +Note that these rules can be omitted by the CIL compiler command line parameter `-D` or `--disable-dontaudit` flags. + +**Rule definition:** + + (dontauditx source_id target_id|self permissionx_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

dontauditx

The dontauditx keyword.

source_id

A single previously defined source type, typealias or typeattribute identifier.

target_id

A single previously defined target type, typealias or typeattribute identifier.

+

The self keyword may be used instead to signify that source and target are the same.

permissionx_id

A single named or anonymous permissionx.

+ +**Examples:** + +This example will not audit the denied access: + + (dontauditx type_1 type_2 (ioctl tcp_socket (range 0x3000 0x30FF))) + + +neverallowx +---------- +Never allow access rights defined for extended permissions. This is a compiler enforced action that will stop compilation until the offending rules are modified. + +Note that these rules can be over-ridden by the CIL compiler command line parameter `-N` or `--disable-neverallow` flags. + +**Rule definition:** + + (neverallowx source_id target_id|self permissionx_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

neverallows

The neverallowx keyword.

source_id

A single previously defined source type, typealias or typeattribute identifier.

target_id

A single previously defined target type, typealias or typeattribute identifier.

+

The self keyword may be used instead to signify that source and target are the same.

permissionx_id

A single named or anonymous permissionx.

+ +**Examples:** + +This example will not compile as `type_3` is not allowed to be a source type and ioctl range for the [`allowx`](cil_access_vector_rules.md#allowx) rule: + + (class property_service (ioctl)) + (block av_rules + (type type_1) + (type type_2) + (type type_3) + (typeattribute all_types) + (typeattributeset all_types ((all))) + (neverallowx type_3 all_types (ioctl property_service (range 0x2000 0x20FF))) + ; This rule will fail compilation: + (allowx type_3 self (ioctl property_service (0x20A0))) + ) diff --git a/secilc/docs/cil_access_vector_rules.xml b/secilc/docs/cil_access_vector_rules.xml deleted file mode 100644 index e768558..0000000 --- a/secilc/docs/cil_access_vector_rules.xml +++ /dev/null @@ -1,518 +0,0 @@ - - - - - Access Vector Rules - - allow - Specifies the access allowed between a source and target type. Note that access may be refined by constraint rules based on the source, target and class (validatetrans or mlsvalidatetrans) or source, target class and permissions (constrain or mlsconstrain statements). - Rule definition: - - Where: - - - - - - - - allow - - - The allow keyword. - - - - - source_id - - - A single previously defined source type, typealias or typeattribute identifier. - - - - - target_id - - - A single previously defined target type, typealias or typeattribute identifier. - The self keyword may be used instead to signify that source and target are the same. - - - - - classpermissionset_id - - - A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers. - - - - - - Examples: - These examples show a selection of possible permutations of allow rules: - - - - - - auditallow - Audit the access rights defined if there is a valid allow rule. Note: It does NOT allow access, it only audits the event. - Rule definition: - - Where: - - - - - - - - auditallow - - - The auditallow keyword. - - - - - source_id - - - A single previously defined source type, typealias or typeattribute identifier. - - - - - target_id - - - A single previously defined target type, typealias or typeattribute identifier. - The self keyword may be used instead to signify that source and target are the same. - - - - - classpermissionset_id - - - A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers. - - - - - - Example: - This example will log an audit event whenever the corresponding allow rule grants access to the specified permissions: - - - - - - dontaudit - Do not audit the access rights defined when access denied. This stops excessive log entries for known events. - Note that these rules can be omitted by the CIL compiler command line parameter -D or --disable-dontaudit flags. - Rule definition: - - Where: - - - - - - - - dontaudit - - - The dontaudit keyword. - - - - - source_id - - - A single previously defined source type, typealias or typeattribute identifier. - - - - - target_id - - - A single previously defined target type, typealias or typeattribute identifier. - The self keyword may be used instead to signify that source and target are the same. - - - - - classpermissionset_id - - - A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers. - - - - - - Example: - This example will not audit the denied access: - - - - - - neverallow - Never allow access rights defined. This is a compiler enforced action that will stop compilation until the offending rules are modified. - Note that these rules can be over-ridden by the CIL compiler command line parameter -N or --disable-neverallow flags. - Rule definition: - - Where: - - - - - - - - neverallow - - - The neverallow keyword. - - - - - source_id - - - A single previously defined source type, typealias or typeattribute identifier. - - - - - target_id - - - A single previously defined target type, typealias or typeattribute identifier. - The self keyword may be used instead to signify that source and target are the same. - - - - - classpermissionset_id - - - A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers. - - - - - - Example: - This example will not compile as type_3 is not allowed to be a source type for the allow rule: - - - - - - allowx - Specifies the access allowed between a source and target type using extended permissions. Unlike the allow statement, the statements validatetrans, mlsvalidatetrans, constrain, and mlsconstrain do not limit accesses granted by allowx. - Rule definition: - - Where: - - - - - - - - allowx - - - The allowx keyword. - - - - - source_id - - - A single previously defined source type, typealias, or typeattribute identifier. - - - - - target_id - - - A single previously defined target type, typealias, or typeattribute identifier. - The self keyword may be used instead to signify that source and target are the same. - - - - - permissionx_id - - - A single named or anonymous permissionx. - - - - - - Examples: - These examples show a selection of possible permutations of allowx rules: - - - - - - - auditallowx - Audit the access rights defined if there is a valid allowx rule. It does NOT allow access, it only audits the event. - Rule definition: - - Where: - - - - - - - - auditallowx - - - The auditallowx keyword. - - - - - source_id - - - A single previously defined source type, typealias or typeattribute identifier. - - - - - target_id - - - A single previously defined target type, typealias or typeattribute identifier. - The self keyword may be used instead to signify that source and target are the same. - - - - - permissionx_id - - - A single named or anonymous permissionx. - - - - - - Examples: - This example will log an audit event whenever the corresponding allowx rule grants access to the specified extended permissions: - - - - - - dontauditx - Do not audit the access rights defined when access denied. This stops excessive log entries for known events. - Note that these rules can be omitted by the CIL compiler command line parameter -D or --disable-dontaudit flags. - Rule definition: - - Where: - - - - - - - - dontauditx - - - The dontauditx keyword. - - - - - source_id - - - A single previously defined source type, typealias or typeattribute identifier. - - - - - target_id - - - A single previously defined target type, typealias or typeattribute identifier. - The self keyword may be used instead to signify that source and target are the same. - - - - - permissionx_id - - - A single named or anonymous permissionx. - - - - - - Examples: - This example will not audit the denied access: - - - - - - neverallowx - Never allow access rights defined for extended permissions. This is a compiler enforced action that will stop compilation until the offending rules are modified. - Note that these rules can be over-ridden by the CIL compiler command line parameter -N or --disable-neverallow flags. - Rule definition: - - Where: - - - - - - - - neverallowx - - - The neverallowx keyword. - - - - - source_id - - - A single previously defined source type, typealias or typeattribute identifier. - - - - - target_id - - - A single previously defined target type, typealias or typeattribute identifier. - The self keyword may be used instead to signify that source and target are the same. - - - - - permissionx_id - - - A single named or anonymous permissionx. - - - - - - Example: - This example will not compile as type_3 is not allowed to be a source type and ioctl range for the allowx rule: - - - - - diff --git a/secilc/docs/cil_call_macro_statements.md b/secilc/docs/cil_call_macro_statements.md new file mode 100644 index 0000000..17c46ed --- /dev/null +++ b/secilc/docs/cil_call_macro_statements.md @@ -0,0 +1,130 @@ +Call / Macro Statements +======================= + +call +---- + +Instantiate a [macro](#macro) within the current namespace. There may be zero or more parameters passed to the macro (with zero parameters this is similar to the [`blockinherit`](cil_container_statements.md#blockinherit) ([`call`](cil_call_macro_statements.md#call)) / [`blockabstract`](cil_container_statements.md#blockabstract) ([`macro`](cil_call_macro_statements.md#macro)) statements). + +Each parameter passed contains an argument to be resolved by the [macro](#macro), these can be named or anonymous but must conform to the parameter types defined in the [`macro`](cil_call_macro_statements.md#macro) statement. + +**Statement definition:** + + (call macro_id [(param ...)]) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

call

The call keyword.

macro_id

The identifier of the macro to be instantiated.

param

Zero or more parameters that are passed to the macro.

+ +**Example:** + +See the [`macro`](cil_call_macro_statements.md#macro) statement for an example. + +macro +----- + +Declare a macro in the current namespace with its associated parameters. The macro identifier is used by the [`call`](cil_call_macro_statements.md#call) statement to instantiate the macro and resolve any parameters. The call statement may be within the body of a macro. + +Note that when resolving macros the callers namespace is not checked, only the following places: + +- Items defined inside the macro + +- Items passed into the macro as arguments + +- Items defined in the same namespace of the macro + +- Items defined in the global namespace + +**Statement definition:** + + (macro macro_id ([(param_type param_id) ...]) + cil_statements + ... + ) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

macro

The macro keyword.

macro_id

The macro identifier.

param_type

Zero or more parameters that are passed to the macro. The param_type is a keyword used to determine the declaration type (e.g. type, class, categoryset).

+

The list of valid param_type entries are: type, typealias, role, user, sensitivity, sensitivityalias, category, categoryalias, categoryset (named or anonymous), level (named or anonymous), levelrange (named or anonymous), class, classpermission (named or anonymous), ipaddr (named or anonymous), block, name (a string), classmap

param_id

The parameter identifier used to reference the entry within the macro body (e.g. ARG1).

cil_statement

Zero or more valid CIL statements.

+ +**Examples:** + +This example will instantiate the `binder_call` macro in the calling namespace (`my_domain`) and replace `ARG1` with `appdomain` and `ARG2` with `binderservicedomain`: + + (block my_domain + (call binder_call (appdomain binderservicedomain)) + ) + + (macro binder_call ((type ARG1) (type ARG2)) + (allow ARG1 ARG2 (binder (call transfer))) + (allow ARG2 ARG1 (binder (transfer))) + (allow ARG1 ARG2 (fd (use))) + ) + +This example does not pass any parameters to the macro but adds a [`type`](cil_type_statements.md#type) identifier to the current namespace: + + (block unconfined + (call add_type) + .... + + (macro add_type () + (type exec) + ) + ) + +This example passes an anonymous and named IP address to the macro: + + (ipaddr netmask_1 255.255.255.0) + (context netlabel_1 (system.user object_r unconfined.object low_low) + + (call build_nodecon ((192.168.1.64) netmask_1)) + + (macro build_nodecon ((ipaddr ARG1) (ipaddr ARG2)) + (nodecon ARG1 ARG2 netlabel_1) + ) diff --git a/secilc/docs/cil_call_macro_statements.xml b/secilc/docs/cil_call_macro_statements.xml deleted file mode 100644 index b783515..0000000 --- a/secilc/docs/cil_call_macro_statements.xml +++ /dev/null @@ -1,174 +0,0 @@ - - - - - Call / Macro Statements - - call - Instantiate a macro within the current namespace. There may be zero or more parameters passed to the macro (with zero parameters this is similar to the blockinherit (call) / blockabstract (macro) statements). - Each parameter passed contains an argument to be resolved by the macro, these can be named or anonymous but must conform to the parameter types defined in the macro statement. - Statement definition: - - Where: - - - - - - - - call - - - The call keyword. - - - - - macro_id - - - The identifier of the macro to be instantiated. - - - - - param - - - Zero or more parameters that are passed to the macro. - - - - - Example: - See the macro statement for an example. - - - - macro - Declare a macro in the current namespace with its associated parameters. The macro identifier is used by the call statement to instantiate the macro and resolve any parameters. The call statement may be within the body of a macro. - - Note that when resolving macros the callers namespace is not checked, only the following places: - - Items defined inside the macro - Items passed into the macro as arguments - Items defined in the same namespace of the macro - Items defined in the global namespace - - - Statement definition: - - - Where: - - - - - - - - macro - - - The macro keyword. - - - - - macro_id - - - The macro identifier. - - - - - param_type - - - Zero or more parameters that are passed to the macro. The param_type is a keyword used to determine the declaration type (e.g. type, class, categoryset). - The list of valid param_type entries are: - - type - typealias - role - user - sensitivity - sensitivityalias - category - categoryalias - categoryset (named or anonymous) - level (named or anonymous) - levelrange (named or anonymous) - class - classpermission (named or anonymous) - ipaddr (named or anonymous) - block - name (a string) - classmap - - - - - - param_id - - - The parameter identifier used to reference the entry within the macro body (e.g. ARG1). - - - - - cil_statement - - - Zero or more valid CIL statements. - - - - - - Examples: - This example will instantiate the binder_call macro in the calling namespace (my_domain) and replace ARG1 with appdomain and ARG2 with binderservicedomain: - - - - This example does not pass any parameters to the macro but adds a type identifier to the current namespace: - - - - This example passes an anonymous and named IP address to the macro: - - - - diff --git a/secilc/docs/cil_class_and_permission_statements.md b/secilc/docs/cil_class_and_permission_statements.md new file mode 100644 index 0000000..290af50 --- /dev/null +++ b/secilc/docs/cil_class_and_permission_statements.md @@ -0,0 +1,522 @@ +Class and Permission Statements +=============================== + +common +------ + +Declares a common identifier in the current namespace with a set of common permissions that can be used by one or more [`class`](cil_class_and_permission_statements.md#class) identifiers. The [`classcommon`](cil_class_and_permission_statements.md#classcommon) statement is used to associate a [`common`](cil_class_and_permission_statements.md#common) identifier to a specific [`class`](cil_class_and_permission_statements.md#class) identifier. + +**Statement definition:** + + (common common_id (permission_id ...)) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

common

The common keyword.

common_id

The common identifier.

permission_id

One or more permissions.

+ +**Example:** + +This common statement will associate the [`common`](cil_class_and_permission_statements.md#common) identifier '`file`' with the list of permissions: + + (common file (ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton)) + +classcommon +----------- + +Associate a [`class`](cil_class_and_permission_statements.md#class) identifier to a one or more permissions declared by a [`common`](cil_class_and_permission_statements.md#common) identifier. + +**Statement definition:** + + (classcommon class_id common_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

classcommon

The classcommon keyword.

class_id

A single previously declared class identifier.

common_id

A single previously declared common identifier that defines the common permissions for that class.

+ +**Example:** + +This associates the `dir` class with the list of permissions declared by the `file common` identifier: + + (common file (ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton)) + + (classcommon dir file) + +class +----- + +Declares a class and zero or more permissions in the current namespace. + +**Statement definition:** + + (class class_id (permission_id ...)) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

class

The class keyword.

class_id

The class identifier.

permission_id

Zero or more permissions declared for the class. Note that if zero permissions, an empty list is required as shown in the example.

+ +**Examples:** + +This example defines a set of permissions for the `binder` class indentifier: + + (class binder (impersonate call set_context_mgr transfer receive)) + +This example defines a common set of permissions to be used by the `sem` class, the `(class sem ())` does not define any other permissions (i.e. an empty list): + + (common ipc (create destroy getattr setattr read write associate unix_read unix_write)) + + (classcommon sem ipc) + (class sem ()) + +and will produce the following set of permissions for the `sem` class identifier of: + + (class sem (create destroy getattr setattr read write associate unix_read unix_write)) + +This example, with the following combination of the [`common`](cil_class_and_permission_statements.md#common), [`classcommon`](cil_class_and_permission_statements.md#classcommon) and [`class`](cil_class_and_permission_statements.md#class) statements: + + (common file (ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton)) + + (classcommon dir file) + (class dir (add_name remove_name reparent search rmdir open audit_access execmod)) + +will produce a set of permissions for the `dir` class identifier of: + + (class dir (add_name remove_name reparent search rmdir open audit_access execmod ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton)) + +classorder +---------- + +Defines the order of [class](#class)'s. This is a mandatory statement. Multiple [`classorder`](cil_class_and_permission_statements.md#classorder) statements declared in the policy will form an ordered list. + +**Statement definition:** + + (classorder (class_id ...)) + +**Where:** + + ++++ + + + + + + + + + + +

classorder

The classorder keyword.

class_id

One or more class identifiers.

+ +**Example:** + +This will produce an ordered list of "`file dir process`" + + (class process) + (class file) + (class dir) + (classorder (file dir)) + (classorder (dir process)) + +**Unordered Classorder Statement:** + +If users do not have knowledge of the existing [`classorder`](#classorder), the `unordered` keyword may be used in a [`classorder`](#classorder) statement. The [classes](#class) in an unordered statement are appended to the existing [`classorder`](#classorder). A class in an ordered statement always supercedes the class redeclaration in an unordered statement. The `unordered` keyword must be the first item in the [`classorder`](#classorder) listing. + +**Example:** + +This will produce an unordered list of "`file dir foo a bar baz`" + + (class file) + (class dir) + (class foo) + (class bar) + (class baz) + (class a) + (classorder (file dir)) + (classorder (dir foo)) + (classorder (unordered a)) + (classorder (unordered bar foo baz)) + +classpermission +--------------- + +Declares a class permission set identifier in the current namespace that can be used by one or more [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset)s to associate one or more classes and permissions to form a named set. + +**Statement definition:** + + (classpermission classpermissionset_id) + +**Where:** + + ++++ + + + + + + + + + + +

classpermission

The classpermission keyword.

classpermissionset_id

The classpermissionset identifier.

+ +**Example:** + +See the [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset) statement for examples. + +classpermissionset +------------------ + +Defines a class permission set identifier in the current namespace that associates a class and one or more permissions to form a named set. Nested expressions may be used to determine the required permissions as shown in the examples. Anonymous [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset)s may be used in av rules and constraints. + +**Statement definition:** + + (classpermissionset classpermissionset_id (class_id (permission_id | expr ...))) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

classpermissionset

The classpermissionset keyword.

classpermissionset_id

The classpermissionset identifier.

class_id

A single previously declared class identifier.

permission_id

Zero or more permissions required by the class.

+

Note that there must be at least one permission identifier or expr declared).

expr

Zero or more expr's, the valid operators and syntax are:

+

(and (permission_id ...) (permission_id ...))

+

(or (permission_id ...) (permission_id ...))

+

(xor (permission_id ...) (permission_id ...))

+

(not (permission_id ...))

+

(all)

+ +**Examples:** + +These class permission set statements will resolve to the permission sets shown in the kernel policy language [`allow`](cil_access_vector_rules.md#allow) rules: + + (class zygote (specifyids specifyrlimits specifycapabilities specifyinvokewith specifyseinfo)) + + (type test_1) + (type test_2) + (type test_3) + (type test_4) + (type test_5) + + ; NOT + (classpermission zygote_1) + (classpermissionset zygote_1 (zygote + (not + (specifyinvokewith specifyseinfo) + ) + )) + (allow unconfined.process test_1 zygote_1) + ;; allow unconfined.process test_1 : zygote { specifyids specifyrlimits specifycapabilities } ; + + ; AND - ALL - NOT - Equiv to test_1 + (classpermission zygote_2) + (classpermissionset zygote_2 (zygote + (and + (all) + (not (specifyinvokewith specifyseinfo)) + ) + )) + (allow unconfined.process test_2 zygote_2) + ;; allow unconfined.process test_2 : zygote { specifyids specifyrlimits specifycapabilities } ; + + ; OR + (classpermission zygote_3) + (classpermissionset zygote_3 (zygote ((or (specifyinvokewith) (specifyseinfo))))) + (allow unconfined.process test_3 zygote_3) + ;; allow unconfined.process test_3 : zygote { specifyinvokewith specifyseinfo } ; + + ; XOR - This will not produce an allow rule as the XOR will remove all the permissions: + (classpermission zygote_4) + (classpermissionset zygote_4 (zygote (xor (specifyids specifyrlimits specifycapabilities specifyinvokewith specifyseinfo) (specifyids specifyrlimits specifycapabilities specifyinvokewith specifyseinfo)))) + + ; ALL + (classpermission zygote_all_perms) + (classpermissionset zygote_all_perms (zygote (all))) + (allow unconfined.process test_5 zygote_all_perms) + ;; allow unconfined.process test_5 : zygote { specifyids specifyrlimits specifycapabilities specifyinvokewith specifyseinfo } ; + +classmap +-------- + +Declares a class map identifier in the current namespace and one or more class mapping identifiers. This will allow: + +1. Multiple [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset)s to be linked to a pair of [`classmap`](cil_class_and_permission_statements.md#classmap) / [`classmapping`](cil_class_and_permission_statements.md#classmapping) identifiers. + +2. Multiple [`class`](cil_class_and_permission_statements.md#class)s to be associated to statements and rules that support a list of classes: + + typetransition + typechange + typemember + rangetransition + roletransition + defaultuser + defaultrole + defaulttype + defaultrange + validatetrans + mlsvalidatetrans + +**Statement definition:** + + (classmap classmap_id (classmapping_id ...)) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

classmap

The classmap keyword.

classmap_id

The classmap identifier.

classmapping_id

One or more classmapping identifiers.

+ +**Example:** + +See the [`classmapping`](cil_class_and_permission_statements.md#classmapping) statement for examples. + +classmapping +------------ + +Define sets of [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset)s (named or anonymous) to form a consolidated [`classmapping`](cil_class_and_permission_statements.md#classmapping) set. Generally there are multiple [`classmapping`](cil_class_and_permission_statements.md#classmapping) statements with the same [`classmap`](cil_class_and_permission_statements.md#classmap) and [`classmapping`](cil_class_and_permission_statements.md#classmapping) identifiers that form a set of different [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset)'s. This is useful when multiple class / permissions are required in rules such as the [`allow`](cil_access_vector_rules.md#allow) rules (as shown in the examples). + +**Statement definition:** + + (classmapping classmap_id classmapping_id classpermissionset_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

classmapping

The classmapping keyword.

classmap_id

A single previously declared classmap identifier.

classmapping_id

The classmapping identifier.

classpermissionset_id

A single named classpermissionset identifier or a single anonymous classpermissionset using expr's as required (see the classpermissionset statement).

+ +**Examples:** + +These class mapping statements will resolve to the permission sets shown in the kernel policy language [`allow`](cil_access_vector_rules.md#allow) rules: + + (class binder (impersonate call set_context_mgr transfer receive)) + (class property_service (set)) + (class zygote (specifyids specifyrlimits specifycapabilities specifyinvokewith specifyseinfo)) + + (classpermission cps_zygote) + (classpermissionset cps_zygote (zygote (not (specifyids)))) + + (classmap android_classes (set_1 set_2 set_3)) + + (classmapping android_classes set_1 (binder (all))) + (classmapping android_classes set_1 (property_service (set))) + (classmapping android_classes set_1 (zygote (not (specifycapabilities)))) + + (classmapping android_classes set_2 (binder (impersonate call set_context_mgr transfer))) + (classmapping android_classes set_2 (zygote (specifyids specifyrlimits specifycapabilities specifyinvokewith))) + + (classmapping android_classes set_3 cps_zygote) + (classmapping android_classes set_3 (binder (impersonate call set_context_mgr))) + + (block map_example + (type type_1) + (type type_2) + (type type_3) + + (allow type_1 self (android_classes (set_1))) + (allow type_2 self (android_classes (set_2))) + (allow type_3 self (android_classes (set_3))) + ) + + ; The above will resolve to the following AV rules: + ;; allow map_example.type_1 map_example.type_1 : binder { impersonate call set_context_mgr transfer receive } ; + ;; allow map_example.type_1 map_example.type_1 : property_service set ; + ;; allow map_example.type_1 map_example.type_1 : zygote { specifyids specifyrlimits specifyinvokewith specifyseinfo } ; + + ;; allow map_example.type_2 map_example.type_2 : binder { impersonate call set_context_mgr transfer } ; + ;; allow map_example.type_2 map_example.type_2 : zygote { specifyids specifyrlimits specifycapabilities specifyinvokewith } ; + + ;; allow map_example.type_3 map_example.type_3 : binder { impersonate call set_context_mgr } ; + ;; allow map_example.type_3 map_example.type_3 : zygote { specifyrlimits specifycapabilities specifyinvokewith specifyseinfo } ; + +permissionx +----------- + +Defines a named extended permission, which can be used in the [`allowx`](cil_access_vector_rules.md#allowx), [`auditallowx`](cil_access_vector_rules.md#auditallowx), [`dontauditx`](cil_access_vector_rules.md#dontauditx), and [`neverallowx`](cil_access_vector_rules.md#neverallowx) statements. + +**Statement definition:** + + (permissionx permissionx_id (kind class_id (permission ... | expr ...))) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

permissionx

The permissionx keyword.

kind

A keyword specifying how to interpret the extended permission values. Must be one of:

+ + + + + + + + + + + + + +

kind

description

ioctl

Permissions define a whitelist of ioctl values. Permission values must range from 0x0000 to 0xFFFF, inclusive.

class_id

A single previously declared class identifier.

permission

One or more numeric values, specified in decimal, or hexadecimal if prefixed with 0x, or octal if prefixed with 0. Values are interpreted based on the value of kind.

expr

An expression, with valid operators and syntax:

+

(range (permission ...) (permission ...))

+

(and (permission ...) (permission ...))

+

(or (permission ...) (permission ...))

+

(xor (permission ...) (permission ...))

+

(not (permission ...))

+

(all)

+ +**Examples:** + + (permissionx ioctl_1 (ioctl tcp_socket (0x2000 0x3000 0x4000))) + (permissionx ioctl_2 (ioctl tcp_socket (range 0x6000 0x60FF))) + (permissionx ioctl_3 (ioctl tcp_socket (and (range 0x8000 0x90FF) (not (range 0x8100 0x82FF))))) diff --git a/secilc/docs/cil_class_and_permission_statements.xml b/secilc/docs/cil_class_and_permission_statements.xml deleted file mode 100644 index f4982e0..0000000 --- a/secilc/docs/cil_class_and_permission_statements.xml +++ /dev/null @@ -1,604 +0,0 @@ - - - - - Class and Permission Statements - - common - Declares a common identifier in the current namespace with a set of common permissions that can be used by one or more class identifiers. The classcommon statement is used to associate a common identifier to a specific class identifier. - Statement definition: - - Where: - - - - - - - - common - - - The common keyword. - - - - - common_id - - - The common identifier. - - - - - permission_id - - - One or more permissions. - - - - - - Example: - This common statement will associate the common identifier 'file' with the list of permissions: - - - - - - classcommon - Associate a class identifier to a one or more permissions declared by a common identifier. - Statement definition: - - Where: - - - - - - - - classcommon - - - The classcommon keyword. - - - - - class_id - - - A single previously declared class identifier. - - - - - common_id - - - A single previously declared common identifier that defines the common permissions for that class. - - - - - Example: - This associates the dir class with the list of permissions declared by the file common identifier: - - - - - - class - Declares a class and zero or more permissions in the current namespace. - Statement definition: - - Where: - - - - - - - - class - - - The class keyword. - - - - - class_id - - - The class identifier. - - - - - permission_id - - - Zero or more permissions declared for the class. Note that if zero permissions, an empty list is required as shown in the example. - - - - - - Examples: - This example defines a set of permissions for the binder class indentifier: - - - - This example defines a common set of permissions to be used by the sem class, the (class sem ()) does not define any other permissions (i.e. an empty list): - - - and will produce the following set of permissions for the sem class identifier of: - - - - This example, with the following combination of the common, classcommon and class statements: - - - will produce a set of permissions for the dir class identifier of: - - - - - classorder - Defines the order of class's. This is a mandatory statement. Multiple classorder statements declared in the policy will form an ordered list. - Statement definition: - - Where: - - - - - - - - classorder - - - The classorder keyword. - - - - - class_id - - - One or more class identifiers. - - - - - - Example: - This will produce an ordered list of "file dir process" - - - Unordered Classorder Statement: - If users do not have knowledge of the existing classorder, the unordered keyword may be used in a classorder statement. The classes in an unordered statement are appended to the existing classorder. A class in an ordered statement always supercedes the class redeclaration in an unordered statement. The unordered keyword must be the first item in the classorder listing. - Example: - This will produce an ordered list of "file dir foo a bar baz" - - - - - classpermission - Declares a class permission set identifier in the current namespace that can be used by one or more classpermissionsets to associate one or more classes and permissions to form a named set. - Statement definition: - - Where: - - - - - - - - classpermission - - - The classpermission keyword. - - - - - classpermissionset_id - - - The classpermissionset identifier. - - - - - Example: - See the classpermissionset statement for examples. - - - - classpermissionset - Defines a class permission set identifier in the current namespace that associates a class and one or more permissions to form a named set. Nested expressions may be used to determine the required permissions as shown in the examples. Anonymous classpermissionsets may be used in av rules and constraints. - Statement definition: - - Where: - - - - - - - - classpermissionset - - - The classpermissionset keyword. - - - - - classpermissionset_id - - - The classpermissionset identifier. - - - - - class_id - - - A single previously declared class identifier. - - - - - permission_id - - - Zero or more permissions required by the class. - Note that there must be at least one permission identifier or expr declared). - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and (permission_id ...) (permission_id ...)) - (or (permission_id ...) (permission_id ...)) - (xor (permission_id ...) (permission_id ...)) - (not (permission_id ...)) - (all) - - - - - - Examples: - These class permission set statements will resolve to the permission sets shown in the kernel policy language allow rules: - - - - - - classmap - Declares a class map identifier in the current namespace and one or more class mapping identifiers. This will allow: - - Multiple classpermissionsets to be linked to a pair of classmap / classmapping identifiers. - Multiple classs to be associated to statements and rules that support a list of classes: - - typetransition - typechange - typemember - rangetransition - roletransition - defaultuser - defaultrole - defaulttype - defaultrange - validatetrans - mlsvalidatetrans - - - Statement definition: - - Where: - - - - - - - - classmap - - - The classmap keyword. - - - - - classmap_id - - - The classmap identifier. - - - - - classmapping_id - - - One or more classmapping identifiers. - - - - - Example: - See the classmapping statement for examples. - - - - classmapping - Define sets of classpermissionsets (named or anonymous) to form a consolidated classmapping set. Generally there are multiple classmapping statements with the same classmap and classmapping identifiers that form a set of different classpermissionset's. This is useful when multiple class / permissions are required in rules such as the allow rules (as shown in the examples). - Statement definition: - - Where: - - - - - - - - classmapping - - - The classmapping keyword. - - - - - classmap_id - - - A single previously declared classmap identifier. - - - - - classmapping_id - - - The classmapping identifier. - - - - - classpermissionset_id - - - A single named classpermissionset identifier or a single anonymous classpermissionset using expr's as required (see the classpermissionset statement). - - - - - Examples: - These class mapping statements will resolve to the permission sets shown in the kernel policy language allow rules: - - - - - - permissionx - Defines a named extended permission, which can be used in the allowx, auditallowx, dontauditx, and neverallowx statements. - Statement definition: - - Where: - - - - - - - - permissionx - - - The permissionx keyword. - - - - - kind - - - A keyword specifying how to interpret the extended permission values. Must be one of: - - - - - - - - - kind - - - description - - - - - - - ioctl - - - Permissions define a whitelist of ioctl values. Permission values must range from 0x0000 to 0xFFFF, inclusive. - - - - - - - - - - class_id - - - A single previously declared class identifier. - - - - - permission - - - One or more numeric values, specified in decimal, or hexadecimal if prefixed with 0x, or octal if prefixed with 0. Values are interpreted based on the value of kind. - - - - - expr - - - An expression, with valid operators and syntax: - (range (permission ...) (permission ...)) - (and (permission ...) (permission ...)) - (or (permission ...) (permission ...)) - (xor (permission ...) (permission ...)) - (not (permission ...)) - (all) - - - - - Examples: - - - - - diff --git a/secilc/docs/cil_conditional_statements.md b/secilc/docs/cil_conditional_statements.md new file mode 100644 index 0000000..f30d2cc --- /dev/null +++ b/secilc/docs/cil_conditional_statements.md @@ -0,0 +1,222 @@ +Conditional Statements +====================== + +boolean +------- + +Declares a run time boolean as true or false in the current namespace. The [`booleanif`](cil_conditional_statements.md#booleanif) statement contains the CIL code that will be in the binary policy file. + +**Statement definition:** + + (boolean boolean_id true|false) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

boolean

The boolean keyword.

boolean_id

The boolean identifier.

true | false

The initial state of the boolean. This can be changed at run time using setsebool(8) and its status queried using getsebool(8).

+ +**Example:** + +See the [`booleanif`](cil_conditional_statements.md#booleanif) statement for an example. + +booleanif +--------- + +Contains the run time conditional statements that are instantiated in the binary policy according to the computed boolean identifier(s) state. + +[`call`](cil_call_macro_statements.md#call) statements are allowed within a [`booleanif`](cil_conditional_statements.md#booleanif), however the contents of the resulting macro must be limited to those of the [`booleanif`](cil_conditional_statements.md#booleanif) statement (i.e. [`allow`](cil_access_vector_rules.md#allow), [`auditallow`](cil_access_vector_rules.md#auditallow), [`dontaudit`](cil_access_vector_rules.md#dontaudit), [`typemember`](cil_type_statements.md#typemember), [`typetransition`](cil_type_statements.md#typetransition), [`typechange`](cil_type_statements.md#typechange) and the compile time [`tunableif`](cil_conditional_statements.md#tunableif) statement)). + +**Statement definition:** + + (booleanif boolean_id | expr ...) + (true + cil_statements + ...) + (false + cil_statements + ...) + ) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

booleanif

The booleanif keyword.

boolean_id

Either a single boolean identifier or one or more expr's.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and (boolean_id boolean_id))

+

(or (boolean_id boolean_id))

+

(xor (boolean_id boolean_id))

+

(eq (boolean_id boolean_id))

+

(neq (boolean_id boolean_id))

+

(not (boolean_id))

true

An optional set of CIL statements that will be instantiated when the boolean is evaluated as true.

false

An optional set of CIL statements that will be instantiated when the boolean is evaluated as false.

+ +**Examples:** + +The second example also shows the kernel policy language equivalent: + + (boolean disableAudio false) + + (booleanif disableAudio + (false + (allow process mediaserver.audio_device (chr_file_set (rw_file_perms))) + ) + ) + + (boolean disableAudioCapture false) + + ;;; if(!disableAudio && !disableAudioCapture) { + (booleanif (and (not disableAudio) (not disableAudioCapture)) + (true + (allow process mediaserver.audio_capture_device (chr_file_set (rw_file_perms))) + ) + ) + +tunable +------- + +Tunables are similar to booleans, however they are used to manage areas of CIL statements that may or may not be in the final CIL policy that will be compiled (whereas booleans are embedded in the binary policy and can be enabled or disabled during run-time). + +Note that tunables can be treated as booleans by the CIL compiler command line parameter `-P` or `--preserve-tunables` flags. + +**Statement definition:** + + (tunable tunable_id true|false) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

tunable

The tunable keyword.

tunable_id

The tunable identifier.

true | false

The initial state of the tunable.

+ +**Example:** + +See the [`tunableif`](cil_conditional_statements.md#tunableif) statement for an example. + +tunableif +--------- + +Compile time conditional statement that may or may not add CIL statements to be compiled. + +**Statement definition:** + + (tunableif tunable_id | expr ...) + (true + cil_statements + ...) + (false + cil_statements + ...) + ) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

tunableif

The tunableif keyword.

tunable_id

Either a single tunable identifier or one or more expr's.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and (tunable_id tunable_id))

+

(or (tunable_id tunable_id))

+

(xor (tunable_id tunable_id))

+

(eq (tunable_id tunable_id))

+

(neq (tunable_id tunable_id))

+

(not (tunable_id))

true

An optional set of CIL statements that will be instantiated when the tunable is evaluated as true.

false

An optional set of CIL statements that will be instantiated when the tunable is evaluated as false.

+ +**Example:** + +This example will not add the range transition rule to the binary policy: + + (tunable range_trans_rule false) + + (block init + (class process (process)) + (type process) + + (tunableif range_trans_rule + (true + (rangetransition process sshd.exec process low_high) + ) + ) ; End tunableif + ) ; End block diff --git a/secilc/docs/cil_conditional_statements.xml b/secilc/docs/cil_conditional_statements.xml deleted file mode 100644 index aa30afa..0000000 --- a/secilc/docs/cil_conditional_statements.xml +++ /dev/null @@ -1,269 +0,0 @@ - - - - - Conditional Statements - - boolean - Declares a run time boolean as true or false in the current namespace. The booleanif statement contains the CIL code that will be in the binary policy file. - Statement definition: - - Where: - - - - - - - - boolean - - - The boolean keyword. - - - - - boolean_id - - - The boolean identifier. - - - - - true | false - - - The initial state of the boolean. This can be changed at run time using setsebool(8) and its status queried using getsebool(8). - - - - - Example: - See the booleanif statement for an example. - - - - booleanif - Contains the run time conditional statements that are instantiated in the binary policy according to the computed boolean identifier(s) state. - call statements are allowed within a booleanif, however the contents of the resulting macro must be limited to those of the booleanif statement (i.e. allow, auditallow, dontaudit, typemember, typetransition, typechange and the compile time tunableif statement)). - Statement definition: - - - Where: - - - - - - - - booleanif - - - The booleanif keyword. - - - - - boolean_id - - - Either a single boolean identifier or one or more expr's. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and (boolean_id boolean_id)) - (or (boolean_id boolean_id)) - (xor (boolean_id boolean_id)) - (eq (boolean_id boolean_id)) - (neq (boolean_id boolean_id)) - (not (boolean_id)) - - - - - true - - - An optional set of CIL statements that will be instantiated when the boolean is evaluated as true. - - - - - false - - - An optional set of CIL statements that will be instantiated when the boolean is evaluated as false. - - - - - - Examples: - The second example also shows the kernel policy language equivalent: - - - - - - - - tunable - Tunables are similar to booleans, however they are used to manage areas of CIL statements that may or may not be in the final CIL policy that will be compiled (whereas booleans are embedded in the binary policy and can be enabled or disabled during run-time). - Note that tunables can be treated as booleans by the CIL compiler command line parameter -P or --preserve-tunables flags. - Statement definition: - - Where: - - - - - - - - tunable - - - The tunable keyword. - - - - - tunable_id - - - The tunable identifier. - - - - - true | false - - - The initial state of the tunable. - - - - - Example: - See the tunableif statement for an example. - - - - tunableif - Compile time conditional statement that may or may not add CIL statements to be compiled. - Statement definition: - - - Where: - - - - - - - - tunableif - - - The tunableif keyword. - - - - - tunable_id - - - Either a single tunable identifier or one or more expr's. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and (tunable_id tunable_id)) - (or (tunable_id tunable_id)) - (xor (tunable_id tunable_id)) - (eq (tunable_id tunable_id)) - (neq (tunable_id tunable_id)) - (not (tunable_id)) - - - - - true - - - An optional set of CIL statements that will be instantiated when the tunable is evaluated as true. - - - - - false - - - An optional set of CIL statements that will be instantiated when the tunable is evaluated as false. - - - - - - Example: - This example will not add the range transition rule to the binary policy: - - - - - diff --git a/secilc/docs/cil_constraint_statements.md b/secilc/docs/cil_constraint_statements.md new file mode 100644 index 0000000..df03ae6 --- /dev/null +++ b/secilc/docs/cil_constraint_statements.md @@ -0,0 +1,313 @@ +Constraint Statements +===================== + +constrain +--------- + +Enable constraints to be placed on the specified permissions of the object class based on the source and target security context components. + +**Statement definition:** + + (constrain classpermissionset_id ... expression | expr ...) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

constrain

The constrain keyword.

classpermissionset_id

A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers.

expression

There must be one constraint expression or one or more expr's. The expression consists of an operator and two operands as follows:

+

(op u1 u2)

+

(role_op r1 r2)

+

(op t1 t2)

+

(op u1 user_id)

+

(op u2 user_id)

+

(op r1 role_id)

+

(op r2 role_id)

+

(op t1 type_id)

+

(op t2 type_id)

+

where:

+

u1, r1, t1 = Source context: user, role or type

+

u2, r2, t2 = Target context: user, role or type

+

and:

+

op : eq neq

+

role_op : eq neq dom domby incomp

+

user_id : A single user or userattribute identifier.

+

role_id : A single role or roleattribute identifier.

+

type_id : A single type, typealias or typeattribute identifier.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and expression expression)

+

(or expression expression)

+

(not expression)

+ +**Examples:** + +Two constrain statements are shown with their equivalent kernel policy language statements: + + ;; constrain { file } { write } + ;; (( t1 == unconfined.process ) and ( t2 == unconfined.object ) or ( r1 eq r2 )); + (constrain (file (write)) + (or + (and + (eq t1 unconfined.process) + (eq t2 unconfined.object) + ) + (eq r1 r2) + ) + ) + + ;; constrain { file } { read } + ;; (not( t1 == unconfined.process ) and ( t2 == unconfined.object ) or ( r1 eq r2 )); + (constrain (file (read)) + (not + (or + (and + (eq t1 unconfined.process) + (eq t2 unconfined.object) + ) + (eq r1 r2) + ) + ) + ) + +validatetrans +------------- + +The [`validatetrans`](cil_constraint_statements.md#validatetrans) statement is only used for `file` related object classes where it is used to control the ability to change the objects security context based on old, new and the current process security context. + +**Statement definition:** + + (validatetrans class_id expression | expr ...) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

validatetrans

The validatetrans keyword.

class_id

A single previously declared class or classmap identifier.

expression

There must be one constraint expression or one or more expr's. The expression consists of an operator and two operands as follows:

+

(op u1 u2)

+

(role_op r1 r2)

+

(op t1 t2)

+

(op u1 user_id)

+

(op u2 user_id)

+

(op u3 user_id)

+

(op r1 role_id)

+

(op r2 role_id)

+

(op r3 role_id)

+

(op t1 type_id)

+

(op t2 type_id)

+

(op t3 type_id)

+

where:

+

u1, r1, t1 = Old context: user, role or type

+

u2, r2, t2 = New context: user, role or type

+

u3, r3, t3 = Process context: user, role or type

+

and:

+

op : eq neq

+

role_op : eq neq dom domby incomp

+

user_id : A single user or userattribute identifier.

+

role_id : A single role or roleattribute identifier.

+

type_id : A single type, typealias or typeattribute identifier.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and expression expression)

+

(or expression expression)

+

(not expression)

+ +**Example:** + +A validate transition statement with the equivalent kernel policy language statement: + + ; validatetrans { file } ( t1 == unconfined.process ); + + (validatetrans file (eq t1 unconfined.process)) + +mlsconstrain +------------ + +Enable MLS constraints to be placed on the specified permissions of the object class based on the source and target security context components. + +**Statement definition:** + + (mlsconstrain classpermissionset_id ... expression | expr ...) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

mlsconstrain

The mlsconstrain keyword.

classpermissionset_id

A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers.

expression

There must be one constraint expression or one or more expr's. The expression consists of an operator and two operands as follows:

+

(op u1 u2)

+

(mls_role_op r1 r2)

+

(op t1 t2)

+

(mls_role_op l1 l2)

+

(mls_role_op l1 h2)

+

(mls_role_op h1 l2)

+

(mls_role_op h1 h2)

+

(mls_role_op l1 h1)

+

(mls_role_op l2 h2)

+

(op u1 user_id)

+

(op u2 user_id)

+

(op r1 role_id)

+

(op r2 role_id)

+

(op t1 type_id)

+

(op t2 type_id)

+

where:

+

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

+

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

+

and:

+

op : eq neq

+

mls_role_op : eq neq dom domby incomp

+

user_id : A single user or userattribute identifier.

+

role_id : A single role or roleattribute identifier.

+

type_id : A single type, typealias or typeattribute identifier.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and expression expression)

+

(or expression expression)

+

(not expression)

+ +**Example:** + +An MLS constrain statement with the equivalent kernel policy language statement: + + ;; mlsconstrain { file } { open } + ;; (( l1 eq l2 ) and ( u1 == u2 ) or ( r1 != r2 )); + + (mlsconstrain (file (open)) + (or + (and + (eq l1 l2) + (eq u1 u2) + ) + (neq r1 r2) + ) + ) + +mlsvalidatetrans +---------------- + +The [`mlsvalidatetrans`](cil_constraint_statements.md#mlsvalidatetrans) statement is only used for `file` related object classes where it is used to control the ability to change the objects security context based on old, new and the current process security context. + +**Statement definition:** + + (mlsvalidatetrans class_id expression | expr ...) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

mlsvalidatetrans

The mlsvalidatetrans keyword.

class_id

A single previously declared class or classmap identifier.

expression

There must be one constraint expression or one or more expr's. The expression consists of an operator and two operands as follows:

+

(op u1 u2)

+

(mls_role_op r1 r2)

+

(op t1 t2)

+

(mls_role_op l1 l2)

+

(mls_role_op l1 h2)

+

(mls_role_op h1 l2)

+

(mls_role_op h1 h2)

+

(mls_role_op l1 h1)

+

(mls_role_op l2 h2)

+

(op u1 user_id)

+

(op u2 user_id)

+

(op u3 user_id)

+

(op r1 role_id)

+

(op r2 role_id)

+

(op r3 role_id)

+

(op t1 type_id)

+

(op t2 type_id)

+

(op t3 type_id)

+

where:

+

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

+

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

+

u3, r3, t3 = Process context: user, role or type

+

and:

+

op : eq neq

+

mls_role_op : eq neq dom domby incomp

+

user_id : A single user or userattribute identifier.

+

role_id : A single role or roleattribute identifier.

+

type_id : A single type, typealias or typeattribute identifier.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and expression expression)

+

(or expression expression)

+

(not expression)

+ +**Example:** + +An MLS validate transition statement with the equivalent kernel policy language statement: + + ;; mlsvalidatetrans { file } ( l1 domby h2 ); + + (mlsvalidatetrans file (domby l1 h2)) diff --git a/secilc/docs/cil_constraint_statements.xml b/secilc/docs/cil_constraint_statements.xml deleted file mode 100644 index 8ef1642..0000000 --- a/secilc/docs/cil_constraint_statements.xml +++ /dev/null @@ -1,363 +0,0 @@ - - - - - Constraint Statements - - constrain - Enable constraints to be placed on the specified permissions of the object class based on the source and target security context components. - Statement definition: - - Where: - - - - - - - - constrain - - - The constrain keyword. - - - - - classpermissionset_id - - - A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers. - - - - - expression - - - There must be one constraint expression or one or more expr's. The expression consists of an operator and two operands as follows: - (op u1 u2) - (role_op r1 r2) - (op t1 t2) - (op u1 user_id) - (op u2 user_id) - (op r1 role_id) - (op r2 role_id) - (op t1 type_id) - (op t2 type_id) - where: - u1, r1, t1 = Source context: user, role or type - u2, r2, t2 = Target context: user, role or type - and: - op : eq neq - role_op : eq neq dom domby incomp - user_id : A single user or userattribute identifier. - role_id : A single role or roleattribute identifier. - type_id : A single type, typealias or typeattribute identifier. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and expression expression) - (or expression expression) - (not expression) - - - - - - Examples: - Two constrain statements are shown with their equivalent kernel policy language statements: - - - - - - validatetrans - The validatetrans statement is only used for file related object classes where it is used to control the ability to change the objects security context based on old, new and the current process security context. - Statement definition: - - - Where: - - - - - - - - validatetrans - - - The validatetrans keyword. - - - - - class_id - - - A single previously declared class or classmap identifier. - - - - - expression - - - There must be one constraint expression or one or more expr's. The expression consists of an operator and two operands as follows: - (op u1 u2) - (role_op r1 r2) - (op t1 t2) - (op u1 user_id) - (op u2 user_id) - (op u3 user_id) - (op r1 role_id) - (op r2 role_id) - (op r3 role_id) - (op t1 type_id) - (op t2 type_id) - (op t3 type_id) - where: - u1, r1, t1 = Old context: user, role or type - u2, r2, t2 = New context: user, role or type - u3, r3, t3 = Process context: user, role or type - and: - op : eq neq - role_op : eq neq dom domby incomp - user_id : A single user or userattribute identifier. - role_id : A single role or roleattribute identifier. - type_id : A single type, typealias or typeattribute identifier. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and expression expression) - (or expression expression) - (not expression) - - - - - - Example: - A validate transition statement with the equivalent kernel policy language statement: - - - - - - mlsconstrain - Enable MLS constraints to be placed on the specified permissions of the object class based on the source and target security context components. - Statement definition: - - Where: - - - - - - - - mlsconstrain - - - The mlsconstrain keyword. - - - - - classpermissionset_id - - - A single named or anonymous classpermissionset or a single set of classmap/classmapping identifiers. - - - - - expression - - - There must be one constraint expression or one or more expr's. The expression consists of an operator and two operands as follows: - (op u1 u2) - (mls_role_op r1 r2) - (op t1 t2) - (mls_role_op l1 l2) - (mls_role_op l1 h2) - (mls_role_op h1 l2) - (mls_role_op h1 h2) - (mls_role_op l1 h1) - (mls_role_op l2 h2) - (op u1 user_id) - (op u2 user_id) - (op r1 role_id) - (op r2 role_id) - (op t1 type_id) - (op t2 type_id) - where: - u1, r1, t1, l1, h1 = Source context: user, role, type, low level or high level - u2, r2, t2, l2, h2 = Target context: user, role, type, low level or high level - and: - op : eq neq - mls_role_op : eq neq dom domby incomp - user_id : A single user or userattribute identifier. - role_id : A single role or roleattribute identifier. - type_id : A single type, typealias or typeattribute identifier. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and expression expression) - (or expression expression) - (not expression) - - - - - - Example: - An MLS constrain statement with the equivalent kernel policy language statement: - - - - - - mlsvalidatetrans - The mlsvalidatetrans statement is only used for file related object classes where it is used to control the ability to change the objects security context based on old, new and the current process security context. - Statement definition: - - - Where: - - - - - - - - mlsvalidatetrans - - - The mlsvalidatetrans keyword. - - - - - class_id - - - A single previously declared class or classmap identifier. - - - - - expression - - - There must be one constraint expression or one or more expr's. The expression consists of an operator and two operands as follows: - (op u1 u2) - (mls_role_op r1 r2) - (op t1 t2) - (mls_role_op l1 l2) - (mls_role_op l1 h2) - (mls_role_op h1 l2) - (mls_role_op h1 h2) - (mls_role_op l1 h1) - (mls_role_op l2 h2) - (op u1 user_id) - (op u2 user_id) - (op u3 user_id) - (op r1 role_id) - (op r2 role_id) - (op r3 role_id) - (op t1 type_id) - (op t2 type_id) - (op t3 type_id) - where: - u1, r1, t1, l1, h1 = Source context: user, role, type, low level or high level - u2, r2, t2, l2, h2 = Target context: user, role, type, low level or high level - u3, r3, t3 = Process context: user, role or type - and: - op : eq neq - mls_role_op : eq neq dom domby incomp - user_id : A single user or userattribute identifier. - role_id : A single role or roleattribute identifier. - type_id : A single type, typealias or typeattribute identifier. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and expression expression) - (or expression expression) - (not expression) - - - - - - Example: - An MLS validate transition statement with the equivalent kernel policy language statement: - - - - - diff --git a/secilc/docs/cil_container_statements.md b/secilc/docs/cil_container_statements.md new file mode 100644 index 0000000..a570cb2 --- /dev/null +++ b/secilc/docs/cil_container_statements.md @@ -0,0 +1,296 @@ +Container Statements +==================== + +block +----- + +Start a new namespace where any CIL statement is valid. + +**Statement definition:** + + (block block_id + cil_statement + ... + ) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

block

The block keyword.

block_id

The namespace identifier.

cil_statement

Zero or more valid CIL statements.

+ +**Example:** + +See the [`blockinherit`](cil_container_statements.md#blockinherit) statement for an example. + +blockabstract +------------- + +Declares the namespace as a 'template' and does not generate code until instantiated by another namespace that has a [`blockinherit`](cil_container_statements.md#blockinherit) statement. + +**Statement definition:** + + (block block_id + (blockabstract template_id) + cil_statement + ... + ) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

block

The block keyword.

block_id

The namespace identifier.

blockabstract

The blockabstract keyword.

template_id

The abstract namespace identifier. This must match the block_id entry.

cil_statement

Zero or more valid CIL statements forming the abstract block.

+ +**Example:** + +See the [`blockinherit`](cil_container_statements.md#blockinherit) statement for an example. + +blockinherit +------------ + +Used to add common policy rules to the current namespace via a template that has been defined with the [`blockabstract`](cil_container_statements.md#blockabstract) statement. All [`blockinherit`](cil_container_statements.md#blockinherit) statements are resolved first and then the contents of the block are copied. This is so that inherited blocks will not be inherited. For a concrete example, please see the examples section. + +**Statement definition:** + + (block block_id + (blockinherit template_id) + cil_statement + ... + ) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

block

The block keyword.

block_id

The namespace identifier.

blockinherit

The blockinherit keyword.

template_id

The inherited namespace identifier.

cil_statement

Zero or more valid CIL statements.

+ +**Example:** + +This example contains a template `client_server` that is instantiated in two blocks (`netserver_app` and `netclient_app`): + + ; This is the template block: + (block client_server + (blockabstract client_server) + + ; Log file labeling + (type log_file) + (typeattributeset file_type (log_file)) + (typeattributeset data_file_type (log_file)) + (allow process log_file (dir (write search create setattr add_name))) + (allow process log_file (file (create open append getattr setattr))) + (roletype object_r log_file) + (context log_file_context (u object_r log_file low_low)) + + ; Process labeling + (type process) + (typeattributeset domain (process)) + (call app_domain (process)) + (call net_domain (process)) + ) + + ; This is a policy block that will inherit the abstract block above: + (block netclient_app + ; Add common policy rules to namespace: + (blockinherit client_server) + ; Label the log files + (filecon "/data/data/com.se4android.netclient/.*" file log_file_context) + ) + + ; This is another policy block that will inherit the abstract block above: + (block netserver_app + ; Add common policy rules to namespace: + (blockinherit client_server) + + ; Label the log files + (filecon "/data/data/com.se4android.netserver/.*" file log_file_context) + ) + + ; This is an example of how blockinherits resolve inherits before copying + (block a + (type one)) + + (block b + ; Notice that block a is declared here as well + (block a + (type two))) + + ; This will first copy the contents of block b, which results in type b.a.two being copied. + ; Next, the contents of block a will be copied which will result in type a.one. + (block ab + (blockinherit b) + (blockinherit a)) + +optional +-------- + +Declare an [`optional`](cil_container_statements.md#optional) namespace. All CIL statements in the optional block must be satisfied before instantiation in the binary policy. [`tunableif`](cil_conditional_statements.md#tunableif) and [`macro`](cil_call_macro_statements.md#macro) statements are not allowed in optional containers. The same restrictions apply to CIL policy statements within [`optional`](cil_container_statements.md#optional)'s that apply to kernel policy statements, i.e. only the policy statements shown in the following table are valid: + +| | | | | +| ------------------- | -------------- | ------------------ | ------------------ | +| [`allow`](cil_access_vector_rules.md#allow) | [`allowx`](cil_access_vector_rules.md#allowx) | [`auditallow`](cil_access_vector_rules.md#auditallow) | [`auditallowx`](cil_access_vector_rules.md#auditallowx) | +| [`booleanif`](cil_conditional_statements.md#booleanif) | [`dontaudit`](cil_access_vector_rules.md#dontaudit) | [`dontauditx`](cil_access_vector_rules.md#dontauditx) | [`typepermissive`](cil_type_statements.md#typepermissive) | +| [`rangetransition`](cil_mls_labeling_statements.md#rangetransition) | [`role`](cil_role_statements.md#role) | [`roleallow`](cil_role_statements.md#roleallow) | [`roleattribute`](cil_role_statements.md#roleattribute) | +| [`roletransition`](cil_role_statements.md#roletransition) | [`type`](cil_type_statements.md#type) | [`typealias`](cil_type_statements.md#typealias) | [`typeattribute`](cil_type_statements.md#typeattribute) | +| [`typechange`](cil_type_statements.md#typechange) | [`typemember`](cil_type_statements.md#typemember) | [`typetransition`](cil_type_statements.md#typetransition) | | + +**Statement definition:** + + (optional optional_id + cil_statement + ... + ) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

optional

The optional keyword.

optional_id

The optional namespace identifier.

cil_statement

Zero or more valid CIL statements.

+ +**Example:** + +This example will instantiate the optional block `ext_gateway.move_file` into policy providing all optional CIL statements can be resolved: + + (block ext_gateway + ...... + (optional move_file + (typetransition process msg_filter.move_file.in_queue file msg_filter.move_file.in_file) + (allow process msg_filter.move_file.in_queue (dir (read getattr write search add_name))) + (allow process msg_filter.move_file.in_file (file (write create getattr))) + (allow msg_filter.move_file.in_file unconfined.object (filesystem (associate))) + (typetransition msg_filter.int_gateway.process msg_filter.move_file.out_queue file + msg_filter.move_file.out_file) + (allow msg_filter.int_gateway.process msg_filter.move_file.out_queue (dir (read write search))) + (allow msg_filter.int_gateway.process msg_filter.move_file.out_file (file (read getattr unlink))) + ) ; End optional block + + ..... + ) ; End block + +in +-- + +Allows the insertion of CIL statements into a named container ([`block`](cil_container_statements.md#block), [`optional`](cil_container_statements.md#optional) or [`macro`](cil_call_macro_statements.md#macro)). This statement is not allowed in [`booleanif`](cil_conditional_statements.md#booleanif) or [`tunableif`](cil_conditional_statements.md#tunableif) statements. + +**Statement definition:** + + (in container_id + cil_statement + ... + ) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

in

The in keyword.

container_id

A valid block, optional or macro namespace identifier.

cil_statement

Zero or more valid CIL statements.

+ +**Example:** + +This will add rules to the container named `system_server`: + + (in system_server + (dontaudit process secmark_demo.dns_packet (packet (send recv))) + (allow process secmark_demo.dns_packet (packet (send recv))) + ) diff --git a/secilc/docs/cil_container_statements.xml b/secilc/docs/cil_container_statements.xml deleted file mode 100644 index 3e3d2f6..0000000 --- a/secilc/docs/cil_container_statements.xml +++ /dev/null @@ -1,424 +0,0 @@ - - - - - - Container Statements - - block - Start a new namespace where any CIL statement is valid. - Statement definition: - - - Where: - - - - - - - - block - - - The block keyword. - - - - - block_id - - - The namespace identifier. - - - - - cil_statement - - - Zero or more valid CIL statements. - - - - - Example: - See the blockinherit statement for an example. - - - - blockabstract - Declares the namespace as a 'template' and does not generate code until instantiated by another namespace that has a blockinherit statement. - Statement definition: - - - Where: - - - - - - - - block - - - The block keyword. - - - - - block_id - - - The namespace identifier. - - - - - blockabstract - - - The blockabstract keyword. - - - - - template_id - - - The abstract namespace identifier. This must match the block_id entry. - - - - - cil_statement - - - Zero or more valid CIL statements forming the abstract block. - - - - - Example: - See the blockinherit statement for an example. - - - - blockinherit - Used to add common policy rules to the current namespace via a template that has been defined with the blockabstract statement. All blockinherit statements are resolved first and then the contents of the block are copied. This is so that inherited blocks will not be inherited. For a concrete example, please see the examples section. - Statement definition: - - - Where: - - - - - - - - block - - - The block keyword. - - - - - block_id - - - The namespace identifier. - - - - - blockinherit - - - The blockinherit keyword. - - - - - template_id - - - The inherited namespace identifier. - - - - - cil_statement - - - Zero or more valid CIL statements. - - - - - Example: - This example contains a template client_server that is instantiated in two blocks (netserver_app and netclient_app): - - - - - - optional - Declare an optional namespace. All CIL statements in the optional block must be satisfied before instantiation in the binary policy. tunableif and macro statements are not allowed in optional containers. The same restrictions apply to CIL policy statements within optional's that apply to kernel policy statements, i.e. only the policy statements shown in the following table are valid: - - - - - - - allow - - - allowx - - - auditallow - - - auditallowx - - - - - booleanif - - - dontaudit - - - dontauditx - - - typepermissive - - - - - rangetransition - - - role - - - roleallow - - - roleattribute - - - - - roletransition - - - type - - - typealias - - - typeattribute - - - - - typechange - - - typemember - - - typetransition - - - - - - - Statement definition: - - - Where: - - - - - - - - optional - - - The optional keyword. - - - - - optional_id - - - The optional namespace identifier. - - - - - cil_statement - - - Zero or more valid CIL statements. - - - - - - Example: - This example will instantiate the optional block ext_gateway.move_file into policy providing all optional CIL statements can be resolved: - - - - - - in - Allows the insertion of CIL statements into a named container (block, optional or macro). This statement is not allowed in booleanif or tunableif statements. - Statement definition: - - - Where: - - - - - - - - in - - - The in keyword. - - - - - container_id - - - A valid block, optional or macro namespace identifier. - - - - - cil_statement - - - Zero or more valid CIL statements. - - - - - - Example: - This will add rules to the container named system_server: - - - - - diff --git a/secilc/docs/cil_context_statement.md b/secilc/docs/cil_context_statement.md new file mode 100644 index 0000000..57ad3c6 --- /dev/null +++ b/secilc/docs/cil_context_statement.md @@ -0,0 +1,77 @@ +Context Statement +================= + +Contexts are formed using previously declared parameters and may be named or anonymous where: + +- Named - The context is declared with a context identifer that is used as a reference. + +- Anonymous - They are defined within the CIL labeling statement using user, role etc. identifiers. + +Each type is shown in the examples. + +context +------- + +Declare an SELinux security context identifier for labeling. The range (or current and clearance levels) MUST be defined whether the policy is MLS/MCS enabled or not. + +**Statement definition:** + + (context context_id (user_id role_id type_id levelrange_id))) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +

context

The context keyword.

context_id

The context identifier.

user_id

A single previously declared user identifier.

role_id

A single previously declared role identifier.

type_id

A single previously declared type or typealias identifier.

levelrange_id

A single previously declared levelrange identifier. This entry may also be defined by anonymous or named level, sensitivity, sensitivityalias, category, categoryalias or categoryset as discussed in the Multi-Level Security Labeling Statements section and shown in the examples.

+ +**Examples:** + +This example uses a named context definition: + + (context runas_exec_context (u object_r exec low_low)) + + (filecon "/system/bin/run-as" file runas_exec_context) + +to resolve/build a `file_contexts` entry of (assuming MLS enabled policy): + + /system/bin/run-as -- u:object_r:runas.exec:s0-s0 + +This example uses an anonymous context where the previously declared `user role type levelrange` identifiers are used to specifiy two [`portcon`](cil_network_labeling_statements.md#portcon) statements: + + (portcon udp 1024 (test.user object_r test.process ((s0) (s1)))) + (portcon tcp 1024 (test.user object_r test.process (system_low system_high))) + +This example uses an anonymous context for the first and named context for the second in a [`netifcon`](cil_network_labeling_statements.md#netifcon) statement: + + (context netif_context (test.user object_r test.process ((s0 (c0)) (s1 (c0))))) + + (netifcon eth04 (test.user object_r test.process ((s0 (c0)) (s1 (c0)))) netif_context) diff --git a/secilc/docs/cil_context_statement.xml b/secilc/docs/cil_context_statement.xml deleted file mode 100644 index 648278a..0000000 --- a/secilc/docs/cil_context_statement.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - Context Statement - Contexts are formed using previously declared parameters and may be named or anonymous where: - - Named - The context is declared with a context identifer that is used as a reference. - Anonymous - They are defined within the CIL labeling statement using user, role etc. identifiers. - - Each type is shown in the examples. - - - context - Declare an SELinux security context identifier for labeling. The range (or current and clearance levels) MUST be defined whether the policy is MLS/MCS enabled or not. - Statement definition: - - Where: - - - - - - - - context - - - The context keyword. - - - - - context_id - - - The context identifier. - - - - - user_id - - - A single previously declared user identifier. - - - - - role_id - - - A single previously declared role identifier. - - - - - type_id - - - A single previously declared type or typealias identifier. - - - - - levelrange_id - - - A single previously declared levelrange identifier. This entry may also be defined by anonymous or named level, sensitivity, sensitivityalias, category, categoryalias or categoryset as discussed in the Multi-Level Security Labeling Statements section and shown in the examples. - - - - - - Examples: - This example uses a named context definition: - - - to resolve/build a file_contexts entry of (assuming MLS enabled policy): - - - This example uses an anonymous context where the previously declared user role type levelrange identifiers are used to specifiy two portcon statements: - - - - This example uses an anonymous context for the first and named context for the second in a netifcon statement: - - - - - - diff --git a/secilc/docs/cil_default_object_statements.md b/secilc/docs/cil_default_object_statements.md new file mode 100644 index 0000000..73d84d6 --- /dev/null +++ b/secilc/docs/cil_default_object_statements.md @@ -0,0 +1,183 @@ +Default Object Statements +========================= + +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. + +defaultuser +----------- + +Allows the default user to be taken from the source or target context when computing a new context for the object [`class`](cil_class_and_permission_statements.md#class) identifier. Requires policy version 27. + +**Statement definition:** + + (defaultuser class_id default) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

defaultuser

The defaultuser keyword.

class_id

A single previously declared class or classmap identifier, or a list of previously declared class or classmap identifiers enclosed within parentheses.

default

A keyword of either source or target.

+ +**Example:** + +When creating new `binder`, `property_service`, `zygote` or `memprotect` objects the [`user`](cil_user_statements.md#user) component of the new security context will be taken from the `source` context: + + (class binder (impersonate call set_context_mgr transfer receive)) + (class property_service (set)) + (class zygote (specifyids specifyrlimits specifycapabilities specifyinvokewith specifyseinfo)) + (class memprotect (mmap_zero)) + + (classmap android_classes (android)) + (classmapping android_classes android (binder (all))) + (classmapping android_classes android (property_service (set))) + (classmapping android_classes android (zygote (not (specifycapabilities)))) + + (defaultuser (android_classes memprotect) source) + + ; Will produce the following in the binary policy file: + ;; default_user binder source; + ;; default_user zygote source; + ;; default_user property_service source; + ;; default_user memprotect source; + +defaultrole +----------- + +Allows the default role to be taken from the source or target context when computing a new context for the object [`class`](cil_class_and_permission_statements.md#class) identifier. Requires policy version 27. + + (defaultrole class_id default) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

defaultrole

The defaultrole keyword.

class_id

A single previously declared class or classmap identifier, or a list of previously declared class or classmap identifiers enclosed within parentheses.

default

A keyword of either source or target.

+ +**Example:** + +When creating new `binder`, `property_service` or `zygote` objects the [`role`](cil_role_statements.md#role) component of the new security context will be taken from the `target` context: + + (class binder (impersonate call set_context_mgr transfer receive)) + (class property_service (set)) + (class zygote (specifyids specifyrlimits specifycapabilities specifyinvokewith specifyseinfo)) + + (defaultrole (binder property_service zygote) target) + + ; Will produce the following in the binary policy file: + ;; default_role binder target; + ;; default_role zygote target; + ;; default_role property_service target; + +defaulttype +----------- + +Allows the default type to be taken from the source or target context when computing a new context for the object [`class`](cil_class_and_permission_statements.md#class) identifier. Requires policy version 28. + +**Statement definition:** + + (defaulttype class_id default) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

defaulttype

The defaulttype keyword.

class_id

A single previously declared class or classmap identifier, or a list of previously declared class or classmap identifiers enclosed within parentheses.

default

A keyword of either source or target.

+ +**Example:** + +When creating a new `socket` object, the [`type`](cil_type_statements.md#type) component of the new security context will be taken from the `source` context: + + (defaulttype socket source) + +defaultrange +------------ + +Allows the default level or range to be taken from the source or target context when computing a new context for the object [`class`](cil_class_and_permission_statements.md#class) identifier. Requires policy version 27. + +**Statement definition:** + + (defaultrange class_id default range) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

defaultrange

The defaultrange keyword.

class_id

A single previously declared class or classmap identifier, or a list of previously declared class or classmap identifiers enclosed within parentheses.

default

A keyword of either source or target.

range

A keyword of either low, high or low-high.

+ +**Example:** + +When creating a new `file` object, the appropriate `range` component of the new security context will be taken from the `target` context: + + (defaultrange file target low_high) diff --git a/secilc/docs/cil_default_object_statements.xml b/secilc/docs/cil_default_object_statements.xml deleted file mode 100644 index c654435..0000000 --- a/secilc/docs/cil_default_object_statements.xml +++ /dev/null @@ -1,215 +0,0 @@ - - - - - Default Object Statements - 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. - - defaultuser - Allows the default user to be taken from the source or target context when computing a new context for the object class identifier. Requires policy version 27. - Statement definition: - - Where: - - - - - - - - defaultuser - - - The defaultuser keyword. - - - - - class_id - - - A single previously declared class or classmap identifier, or a list of previously declared class or classmap identifiers enclosed within parentheses. - - - - - default - - - A keyword of either source or target. - - - - - - Example: - When creating new binder, property_service, zygote or memprotect objects the user component of the new security context will be taken from the source context: - - - - - - defaultrole - Allows the default role to be taken from the source or target context when computing a new context for the object class identifier. Requires policy version 27. - - Where: - - - - - - - - defaultrole - - - The defaultrole keyword. - - - - - class_id - - - A single previously declared class or classmap identifier, or a list of previously declared class or classmap identifiers enclosed within parentheses. - - - - - default - - - A keyword of either source or target. - - - - - - Example: - When creating new binder, property_service or zygote objects the role component of the new security context will be taken from the target context: - - - - - - defaulttype - Allows the default type to be taken from the source or target context when computing a new context for the object class identifier. Requires policy version 28. - Statement definition: - - Where: - - - - - - - - defaulttype - - - The defaulttype keyword. - - - - - class_id - - - A single previously declared class or classmap identifier, or a list of previously declared class or classmap identifiers enclosed within parentheses. - - - - - default - - - A keyword of either source or target. - - - - - - Example: - When creating a new socket object, the type component of the new security context will be taken from the source context: - - - - - defaultrange - Allows the default level or range to be taken from the source or target context when computing a new context for the object class identifier. Requires policy version 27. - Statement definition: - - Where: - - - - - - - - defaultrange - - - The defaultrange keyword. - - - - - class_id - - - A single previously declared class or classmap identifier, or a list of previously declared class or classmap identifiers enclosed within parentheses. - - - - - default - - - A keyword of either source or target. - - - - - range - - - A keyword of either low, high or low-high. - - - - - - Example: - When creating a new file object, the appropriate range component of the new security context will be taken from the target context: - - - - diff --git a/secilc/docs/cil_file_labeling_statements.md b/secilc/docs/cil_file_labeling_statements.md new file mode 100644 index 0000000..3175ebc --- /dev/null +++ b/secilc/docs/cil_file_labeling_statements.md @@ -0,0 +1,228 @@ +File Labeling Statements +======================== + +filecon +------- + +Define entries for labeling files. The compiler will produce these entries in a file called **`file_contexts`**`(5)` by default in the `cwd`. The compiler option `[-f|--filecontext ]` may be used to specify a different path or file name. + +**Statement definition:** + + (filecon "path" file_type context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

filecon

The filecon keyword.

path

A string representing the file path that may be in the form of a regular expression. The string must be enclosed within double quotes (e.g. "/this/is/a/path(/.*)?")

file_type

A single keyword representing a file type in the file_contexts file as follows:

+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

keyword

file_contexts entry

file

--

dir

-d

char

-c

block

-b

socket

-s

pipe

-p

symlink

-l

any

no entry

context_id

The security context to be allocated to the file, which may be:

+
    +

  • A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

    • +

  • An empty context list represented by () can be used to indicate that matching files should not be re-labeled. This will be interpreted as <<none>> within the file_contexts(5) file.

    • +
+ +**Examples:** + +These examples use one named, one anonymous and one empty context definition: + + (context runas_exec_context (u object_r exec low_low)) + + (filecon "/system/bin/run-as" file runas_exec_context) + (filecon "/dev/socket/wpa_wlan[0-9]" any u:object_r:wpa.socket:s0-s0) + (filecon "/data/local/mine" dir ()) + +to resolve/build `file_contexts` entries of (assuming MLS enabled policy): + + /system/bin/run-as -- u:object_r:runas.exec:s0 + /dev/socket/wpa_wlan[0-9] u:object_r:wpa.socket:s0 + /data/local/mine -d <> + +fsuse +----- + +Label filesystems that support SELinux security contexts. + +**Statement definition:** + + (fsuse fstype fsname context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

fsuse

The fsuse keyword.

fstype

A single keyword representing the type of filesystem as follows:

+
    +

  • task - For pseudo filesystems supporting task related services such as pipes and sockets.

    • +

  • trans - For pseudo filesystems such as pseudo terminals and temporary objects.

    • +

  • xattr - Filesystems supporting the extended attribute security.selinux. The labeling is persistent for filesystems that support extended attributes.

    • +

fsname

Name of the supported filesystem (e.g. ext4 or pipefs).

context_id

The security context to be allocated to the network interface.

+

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Examples:** + +The [context](#context) identifiers are declared in the `file` namespace and the [`fsuse`](cil_file_labeling_statements.md#fsuse) statements in the global namespace: + + (block file + (type labeledfs) + (roletype object_r labeledfs) + (context labeledfs_context (u object_r labeledfs low_low)) + + (type pipefs) + (roletype object_r pipefs) + (context pipefs_context (u object_r pipefs low_low)) + ... + ) + + (fsuse xattr ex4 file.labeledfs_context) + (fsuse xattr btrfs file.labeledfs_context) + + (fsuse task pipefs file.pipefs_context) + (fsuse task sockfs file.sockfs_context) + + (fsuse trans devpts file.devpts_context) + (fsuse trans tmpfs file.tmpfs_context) + +genfscon +-------- + +Used to allocate a security context to filesystems that cannot support any of the [`fsuse`](cil_file_labeling_statements.md#fsuse) file labeling options. Generally a filesystem would have a single default security context assigned by [`genfscon`](cil_file_labeling_statements.md#genfscon) from the root `(/)` that would then be inherited by all files and directories on that filesystem. The exception to this is the `/proc` filesystem, where directories can be labeled with a specific security context (as shown in the examples). + +**Statement definition:** + + (genfscon fsname path context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

genfscon

The genfscon keyword.

fsname

Name of the supported filesystem (e.g. rootfs or proc).

path

If fsname is proc, then the partial path (see examples). For all other types this must be ‘/’.

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Examples:** + +The [context](#context) identifiers are declared in the `file` namespace and the [`genfscon`](cil_file_labeling_statements.md#genfscon) statements are then inserted using the [`in`](cil_container_statements.md#in) container statement: + + (file + (type rootfs) + (roletype object_r rootfs) + (context rootfs_context (u object_r rootfs low_low)) + + (type proc) + (roletype object_r proc) + (context rootfs_context (u object_r proc low_low)) + ... + ) + + (in file + (genfscon rootfs / rootfs_context) + ; proc labeling can be further refined (longest matching prefix). + (genfscon proc / proc_context) + (genfscon proc /net/xt_qtaguid/ctrl qtaguid_proc_context) + (genfscon proc /sysrq-trigger sysrq_proc_context) + (genfscon selinuxfs / selinuxfs_context) + ) diff --git a/secilc/docs/cil_file_labeling_statements.xml b/secilc/docs/cil_file_labeling_statements.xml deleted file mode 100644 index 8cfdb24..0000000 --- a/secilc/docs/cil_file_labeling_statements.xml +++ /dev/null @@ -1,302 +0,0 @@ - - - - - File Labeling Statements - - filecon - Define entries for labeling files. The compiler will produce these entries in a file called file_contexts(5) by default in the cwd. The compiler option [-f|--filecontext <filename>] may be used to specify a different path or file name. - Statement definition: - - Where: - - - - - - - - filecon - - - The filecon keyword. - - - - - path - - - A string representing the file path that may be in the form of a regular expression. The string must be enclosed within double quotes (e.g. "/this/is/a/path(/.*)?") - - - - - file_type - - - A single keyword representing a file type in the file_contexts file as follows: - - - - - - - - - keyword - - - file_contexts entry - - - - - file - - - -- - - - - - dir - - - -d - - - - - char - - - -c - - - - - block - - - -b - - - - - socket - - - -s - - - - - pipe - - - -p - - - - - symlink - - - -l - - - - - any - - - no entry - - - - - - - - - - context_id - - - The security context to be allocated to the file, which may be: - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - An empty context list represented by () can be used to indicate that matching files should not be re-labeled. This will be interpreted as <<none>> within the file_contexts(5) file. - - - - - - - Examples: - These examples use one named, one anonymous and one empty context definition: - - - to resolve/build file_contexts entries of (assuming MLS enabled policy): - >]]> - - - - - fsuse - Label filesystems that support SELinux security contexts. - Statement definition: - - Where: - - - - - - - - fsuse - - - The fsuse keyword. - - - - - fstype - - - A single keyword representing the type of filesystem as follows: - - task - For pseudo filesystems supporting task related services such as pipes and sockets. - trans - For pseudo filesystems such as pseudo terminals and temporary objects. - xattr - Filesystems supporting the extended attribute security.selinux. The labeling is persistent for filesystems that support extended attributes. - - - - - - fsname - - - Name of the supported filesystem (e.g. ext4 or pipefs). - - - - - context_id - - - The security context to be allocated to the network interface. - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Examples: - The context identifiers are declared in the file namespace and the fsuse statements in the global namespace: - - - - - - genfscon - Used to allocate a security context to filesystems that cannot support any of the fsuse file labeling options. Generally a filesystem would have a single default security context assigned by genfscon from the root (/) that would then be inherited by all files and directories on that filesystem. The exception to this is the /proc filesystem, where directories can be labeled with a specific security context (as shown in the examples). - Statement definition: - - Where: - - - - - - - - genfscon - - - The genfscon keyword. - - - - - fsname - - - Name of the supported filesystem (e.g. rootfs or proc). - - - - - path - - - If fsname is proc, then the partial path (see examples). For all other types this must be ‘/’. - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Examples: - The context identifiers are declared in the file namespace and the genfscon statements are then inserted using the in container statement: - - - - - diff --git a/secilc/docs/cil_introduction.md b/secilc/docs/cil_introduction.md new file mode 100644 index 0000000..c9f52e6 --- /dev/null +++ b/secilc/docs/cil_introduction.md @@ -0,0 +1,59 @@ +Introduction +=================== + +The SELinux Common Intermediate Language (CIL) is designed to be a language that sits between one or more high level policy languages (such as the current module language) and the low-level kernel policy representation. The intermediate language provides several benefits: + +* Enables the creation of multiple high-level languages that can both consume and produce language constructs with more features than the raw kernel policy (e.g., interfaces). Pushing these features into CIL enables cross-language interaction. + +* Eases the creation of high-level languages, encouraging the creation of more domain specific policy languages (e.g., CDS Framework, Lobster, and Shrimp). + +* Provides a semantically rich representation suitable for policy analysis, allowing the analysis of the output of multiple high-level languages using a single analysis tool set without losing needed high-level information. + +Design Philosophy +------------------ + +CIL is guided by several key decision principles: + +* Be an intermediate language - provide rich semantics needed for cross-language interaction but not for convenience. If a feature can be handled by a high-level language without sacrificing cross-language interoperability leave the feature out. Less is more. + +* Facilitate easy parsing and generation - provide clear, simple syntax that is easy to parse and to generate by high-level compilers, analysis tools, and policy generation tools. Machine processing should be prioritized higher than human processing when there is a conflict as humans should be reading and writing high-level languages instead. + +* Fully and faithfully represent the kernel language - the ultimate goal of CIL is the generation of the policy that will be enforced by the kernel. That policy must be full represented so that all of the policy can be represented in CIL. And that representation should not adorn, obscure, or otherwise hide the kernel policy. CIL should allow additional high-level language semantics but should not abstract away the essence of the kernel enforcement. Be C (portable assembler) not a pure functional language (which hides how the processor actually works). + +* The only good binary file format is a non-existent one - CIL is meant for a source policy oriented world, so assume and leverage that. The only binary policy format moving forward should be for communication with the kernel. + +* Enable backwards compatibility but don't be a slave to it - source, but not binary, compatibility with existing policies is a goal but not an absolute requirement. Where necessary it is assumed that manual or automated policy conversion will be required to move to enable the freedom needed to make CIL compelling. + +* Don't fix what isn't broken - CIL is an opportunity to make bold changes to SELinux policy, but there is no reason to re-think core concepts that are working well. All changes to existing language constructs need a clear and compelling reason. One key aspect of the current policy to retain is it's order-independent, declarative style. + +* No more M4 - the pervasive use of M4 and pre-processing in general has eased policy creation, but the side-effects cause many additional problems. CIL should eliminate the need for a pre-processor. + +* Shift more compilation work to happen per-module instead of globally - the current toolchain performance is often driven by the size of the policy and the need to have the entire policy loaded to do much of the processing. If possible, make it possible to do more compilation of one module at a time to increase performance. At the very least, clearly identify and manage language constructs that cause work on the global policy. + +Goals and Primary Features +----- + +CIL is meant to enable several features that are currently difficult or impossible to achieve with the current policy languages and tools. While generality is always a goal, with CIL there are also several well-known and clear motivating language needs. + +* Policy customization without breaking updates - one of the challenges in SELinux is allowing a system builder or administrator to change the access allowed on a system - including removing unwanted access - while not preventing the application of future policy updates from the vendor. It is desirable, therefore, to allow an administrator to make changes to vendor policy without necessitating the direct modification of the shipped policy files. This is most clearly seen when an administrator wants to remove access allowed by a vendor policy that is not already controlled by a policy boolean. + +* Interfaces as a first class feature - interfaces, and macros before them, have been a successful mechanism to allow policy authors to define related sets of access and easily grant that access to new types. However, this success has been hampered by interfaces existing solely as pre-processor constructs, preventing compilers, management tools, and analysis tools from understanding them. This has many unintended consequences, including the need to recompile all modules to include the changes to an interface. Interfaces or some similar construct should become first class language features. + +* Rich policy relationships - templates, interfaces, and attributes are currently the only means of quickly creating new types or sets of types with commonly needed access. However, use of these constructs require up-front design by the policy developer, limiting their use by system builders and administrators to rapidly create or mold existing policy. Policy authors need language features to create new types or modules based upon existing ones with large or small changes. These features should allow ad-hoc creation of new policy modules or types related to existing types. + +* Support for policy management - semanage and related tools currently make policy modifications using private data stores and code to directly manipulate the binary policy format before it is generated for loading into the kernel. These tools should be able to generate and consume CIL to accomplish the same goals. + +Design Overview +------------------ + +The design is aims to provide simplicity in several ways: + +1. The syntax is extremely regular and easy to parse being based upon s-expressions. +2. The statements are reduced to the bare minimum. There is one - and only one - way to express any given syntax. +3. The statements are unambiguous and overlap in very well defined ways. This is in contrast to the current language where a statement, such as a role statement, might be a declaration, a further definition, or both depending on context. + +The language, like the existing policy languages, is declarative. It removes all of the ordering constraints from the previous languages. Finally, the language is meant to be processed in source form as a single compilation unit - there is no module-by-module compilation. This has advantages (no need for compiled disk representation, better error reporting, simpler processing) with the primary disadvantage of space. However, this is not a problem in practice as the linking process for the binary policy modules required the entire representation in memory as well. It is, in many ways, a natural result of the declarative nature of the language. + +In many ways, this design document describes what is different between the current language and CIL. For example, types have exactly the same semantics as they currently do, CIL simply uses a different syntax for declaring and referencing them. Consequently, no space is spent describing the semantics of types and only a small amount of space spent discussing the new syntax separate from interaction with new CIL features. Contrastingly, CIL has new constructs for creating, managing, and traversing namespace. There is a corresponding amount of space describing the semantics of those features. + +When referring to current semantics it is important to note that there are currently three separate policy languages in common usage: the reference policy syntax created in M4 (which includes interfaces and templates), the module syntax understood by checkmodule, and what is commonly called the kernel policy which is the policy understood by checkpolicy. In general, CIL preserves the current kernel policy almost unchanged (just with different syntax) and layers on features from the module language, reference policy, and novel new features. When discussing current semantics, if the context is not clear attempts will be made to clarify which policy language is being referenced. diff --git a/secilc/docs/cil_mls_labeling_statements.md b/secilc/docs/cil_mls_labeling_statements.md new file mode 100644 index 0000000..9b3a36a --- /dev/null +++ b/secilc/docs/cil_mls_labeling_statements.md @@ -0,0 +1,638 @@ +Multi-Level Security Labeling Statements +======================================== + +Because there are many options for MLS labeling, the examples show a limited selection of statements, however there is a simple policy that will build shown in the [`levelrange`](cil_mls_labeling_statements.md#levelrange) section. + +sensitivity +----------- + +Declare a sensitivity identifier in the current namespace. Multiple [`sensitivity`](cil_mls_labeling_statements.md#sensitivity) statements in the policy will form an ordered list. + +**Statement definition:** + + (sensitivity sensitivity_id) + +**Where:** + + ++++ + + + + + + + + + + +

sensitivity

The sensitivity keyword.

sensitivity_id

The sensitivity identifier.

+ +**Example:** + +This example declares three [`sensitivity`](cil_mls_labeling_statements.md#sensitivity) identifiers: + + (sensitivity s0) + (sensitivity s1) + (sensitivity s2) + +sensitivityalias +---------------- + +Declares a sensitivity alias identifier in the current namespace. See the [`sensitivityaliasactual`](cil_mls_labeling_statements.md#sensitivityaliasactual) statement for an example that associates the [`sensitivityalias`](cil_mls_labeling_statements.md#sensitivityalias) identifier. + +**Statement definition:** + + (sensitivityalias sensitivityalias_id) + +**Where:** + + ++++ + + + + + + + + + + +

sensitivityalias

The sensitivityalias keyword.

sensitivityalias_id

The sensitivityalias identifier.

+ +**Example:** + +See the [`sensitivityaliasactual`](cil_mls_labeling_statements.md#sensitivityaliasactual) statement. + +sensitivityaliasactual +---------------------- + +Associates a previously declared [`sensitivityalias`](cil_mls_labeling_statements.md#sensitivityalias) identifier to a previously declared [`sensitivity`](cil_mls_labeling_statements.md#sensitivity) identifier. + +**Statement definition:** + + (sensitivityaliasactual sensitivityalias_id sensitivity_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

sensitivityaliasactual

The sensitivityaliasactual keyword.

sensitivityalias_id

A single previously declared sensitivityalias identifier.

sensitivity_id

A single previously declared sensitivity identifier.

+ +**Example:** + +This example will associate sensitivity `s0` with two sensitivity alias's: + + (sensitivity s0) + (sensitivityalias unclassified) + (sensitivityalias SystemLow) + (sensitivityaliasactual unclassified s0) + (sensitivityaliasactual SystemLow s0) + +sensitivityorder +---------------- + +Define the sensitivity order - lowest to highest. Multiple [`sensitivityorder`](cil_mls_labeling_statements.md#sensitivityorder) statements in the policy will form an ordered list. + +**Statement definition:** + + (sensitivityorder (sensitivity_id ...)) + +**Where:** + + ++++ + + + + + + + + + + +

sensitivityorder

The sensitivityorder keyword.

sensitivity_id

One or more previously declared sensitivity or sensitivityalias identifiers..

+ +**Example:** + +This example shows two [`sensitivityorder`](cil_mls_labeling_statements.md#sensitivityorder) statements that when compiled will form an ordered list. Note however that the second [`sensitivityorder`](cil_mls_labeling_statements.md#sensitivityorder) statement starts with `s2` so that the ordered list can be built. + + (sensitivity s0) + (sensitivityalias s0 SystemLow) + (sensitivity s1) + (sensitivity s2) + (sensitivityorder (SystemLow s1 s2)) + + (sensitivity s3) + (sensitivity s4) + (sensitivityalias s4 SystemHigh) + (sensitivityorder (s2 s3 SystemHigh)) + +category +-------- + +Declare a category identifier in the current namespace. Multiple category statements declared in the policy will form an ordered list. + +**Statement definition:** + + (category category_id) + +**Where:** + + ++++ + + + + + + + + + + +

category

The category keyword.

category_id

The category identifier.

+ +**Example:** + +This example declares a three [`category`](cil_mls_labeling_statements.md#category) identifiers: + + (category c0) + (category c1) + (category c2) + +categoryalias +------------- + +Declares a category alias identifier in the current namespace. See the [`categoryaliasactual`](cil_mls_labeling_statements.md#categoryaliasactual) statement for an example that associates the [`categoryalias`](cil_mls_labeling_statements.md#categoryalias) identifier. + +**Statement definition:** + + (categoryalias categoryalias_id) + +**Where:** + + ++++ + + + + + + + + + + +

categoryalias

The categoryalias keyword.

categoryalias_id

The categoryalias identifier.

+ +categoryaliasactual +------------------- + +Associates a previously declared [`categoryalias`](cil_mls_labeling_statements.md#categoryalias) identifier to a previously declared [`category`](cil_mls_labeling_statements.md#category) identifier. + +**Statement definition:** + + (categoryaliasactual categoryalias_id category_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

categoryaliasactual

The categoryaliasactual keyword.

categoryalias_id

A single previously declared categoryalias identifier.

category_id

A single previously declared category identifier.

+ +**Example:** + +Declares a category `c0`, a category alias of `documents`, and then associates them: + + (category c0) + (categoryalias documents) + (categoryaliasactual documents c0) + +categoryorder +------------- + +Define the category order. Multiple [`categoryorder`](cil_mls_labeling_statements.md#categoryorder) statements declared in the policy will form an ordered list. Note that this statement orders the categories to allow validation of category ranges. + +**Statement definition:** + + (categoryorder (category_id ...)) + +**Where:** + + ++++ + + + + + + + + + + +

categoryorder

The categoryorder keyword.

category_id

One or more previously declared category or categoryalias identifiers.

+ +**Example:** + +This example orders one category alias and nine categories: + + (categoryorder (documents c1 c2 c3 c4 c5 c6 c7 c8 c9) + +categoryset +----------- + +Declare an identifier for a set of contiguous or non-contiguous categories in the current namespace. + +Notes: + +- Category expressions are allowed in [`categoryset`](cil_mls_labeling_statements.md#categoryset), [`sensitivitycategory`](cil_mls_labeling_statements.md#sensitivitycategory), [`level`](cil_mls_labeling_statements.md#level), and [`levelrange`](cil_mls_labeling_statements.md#levelrange) statements. + +- Category sets are not allowed in [`categoryorder`](cil_mls_labeling_statements.md#categoryorder) statements. + +**Statement definition:** + + (categoryset categoryset_id (category_id ... | expr ...)) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

categoryset

The categoryset keyword.

categoryset_id

The categoryset identifier.

category_id

Zero or more previously declared category or categoryalias identifiers.

+

Note that there must be at least one category_id identifier or expr parameter declared.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and (category_id ...) (category_id ...))

+

(or (category_id ...) (category_id ...))

+

(xor (category_id ...) (category_id ...))

+

(not (category_id ...))

+

(range category_id category_id)

+

(all)

+ +**Examples:** + +These examples show a selection of [`categoryset`](cil_mls_labeling_statements.md#categoryset) statements: + + ; Declare categories with two alias's: + (category c0) + (categoryalias documents) + (categoryaliasactual documents c0) + (category c1) + (category c2) + (category c3) + (category c4) + (categoryalias spreadsheets) + (categoryaliasactual spreadsheets c4) + + ; Set the order to determine ranges: + (categoryorder (c0 c1 c2 c3 spreadsheets)) + + (categoryset catrange_1 (range c2 c3)) + + ; Two methods to associate all categories: + (categoryset all_cats (range c0 c4)) + (categoryset all_cats1 (all)) + + (categoryset catset_1 (documents c1)) + (categoryset catset_2 (c2 c3)) + (categoryset catset_3 (c4)) + + (categoryset just_c0 (xor (c1 c2) (documents c1 c2))) + +sensitivitycategory +------------------- + +Associate a [`sensitivity`](cil_mls_labeling_statements.md#sensitivity) identifier with one or more [category](#category)'s. Multiple definitions for the same [`sensitivity`](cil_mls_labeling_statements.md#sensitivity) form an ordered list of categories for that sensitivity. This statement is required before a [`level`](cil_mls_labeling_statements.md#level) identifier can be declared. + +**Statement definition:** + + (sensitivitycategory sensitivity_id categoryset_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

sensitivitycategory

The sensitivitycategory keyword.

sensitivity_id

A single previously declared sensitivity or sensitivityalias identifier.

categoryset_id

A single previously declared categoryset (named or anonymous), or a list of category and/or categoryalias identifiers. The examples show each variation.

+ +**Examples:** + +These [`sensitivitycategory`](cil_mls_labeling_statements.md#sensitivitycategory) examples use a selection of [`category`](cil_mls_labeling_statements.md#category), [`categoryalias`](cil_mls_labeling_statements.md#categoryalias) and [`categoryset`](cil_mls_labeling_statements.md#categoryset)'s: + + (sensitivitycategory s0 catrange_1) + (sensitivitycategory s0 catset_1) + (sensitivitycategory s0 catset_3) + (sensitivitycategory s0 (all)) + (sensitivitycategory unclassified (range documents c2)) + +level +----- + +Declare a [`level`](cil_mls_labeling_statements.md#level) identifier in the current namespace and associate it to a previously declared [`sensitivity`](cil_mls_labeling_statements.md#sensitivity) and zero or more categories. Note that if categories are required, then before this statement can be resolved the [`sensitivitycategory`](cil_mls_labeling_statements.md#sensitivitycategory) statement must be used to associate categories with the sensitivity. + +**Statement definition:** + + level level_id (sensitivity_id [categoryset_id]) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

level

The level keyword.

level_id

The level identifier.

sensitivity_id

A single previously declared sensitivity or sensitivityalias identifier.

categoryset_id

A single previously declared categoryset (named or anonymous), or a list of category and/or categoryalias identifiers. The examples show each variation.

+ +**Examples:** + +These [`level`](cil_mls_labeling_statements.md#level) examples use a selection of [`category`](cil_mls_labeling_statements.md#category), [`categoryalias`](cil_mls_labeling_statements.md#categoryalias) and [`categoryset`](cil_mls_labeling_statements.md#categoryset)'s: + + (level systemLow (s0)) + (level level_1 (s0)) + (level level_2 (s0 (catrange_1))) + (level level_3 (s0 (all_cats))) + (level level_4 (unclassified (c2 c3 c4))) + +levelrange +---------- + +Declare a level range identifier in the current namespace and associate a current and clearance level. + +**Statement definition:** + + (levelrange levelrange_id (low_level_id high_level_id)) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

levelrange

The levelrange keyword.

levelrange_id

The levelrange identifier.

low_level_id

The current level specified by a previously declared level identifier. This may be formed by named or anonymous components as discussed in the level section and shown in the examples.

high_level_id

The clearance or high level specified by a previously declared level identifier. This may be formed by named or anonymous components as discussed in the level section and shown in the examples.

+ +**Examples:** + +This example policy shows [`levelrange`](cil_mls_labeling_statements.md#levelrange) statement and all the other MLS labeling statements discussed in this section and will compile as a standalone policy: + + (handleunknown allow) + (mls true) + + ; There must be least one set of SID statements in a policy: + (sid kernel) + (sidorder (kernel)) + (sidcontext kernel unconfined.context_1) + + (sensitivitycategory s0 (c4 c2 c3 c1 c0 c3)) + + (category c0) + (categoryalias documents) + (categoryaliasactual documents c0) + (category c1) + (category c2) + (category c3) + (category c4) + (categoryalias spreadsheets) + (categoryaliasactual spreadsheets c4) + + (categoryorder (c0 c1 c2 c3 spreadsheets)) + + (categoryset catrange_1 (range c2 c3)) + (categoryset all_cats (range c0 c4)) + (categoryset all_cats1 (all)) + + (categoryset catset_1 (documents c1)) + (categoryset catset_2 (c2 c3)) + (categoryset catset_3 (c4)) + + (categoryset just_c0 (xor (c1 c2) (documents c1 c2))) + + (sensitivity s0) + (sensitivityalias unclassified) + (sensitivityaliasactual unclassified s0) + + (sensitivityorder (s0)) + (sensitivitycategory s0 (c0)) + + (sensitivitycategory s0 catrange_1) + (sensitivitycategory s0 catset_1) + (sensitivitycategory s0 catset_3) + (sensitivitycategory s0 (all)) + (sensitivitycategory s0 (range documents c2)) + + (level systemLow (s0)) + (level level_1 (s0)) + (level level_2 (s0 (catrange_1))) + (level level_3 (s0 (all_cats))) + (level level_4 (unclassified (c2 c3 c4))) + + (levelrange levelrange_2 (level_2 level_2)) + (levelrange levelrange_1 ((s0) level_2)) + (levelrange low_low (systemLow systemLow)) + + (context context_2 (unconfined.user object_r unconfined.object (level_1 level_3))) + + ; Define object_r role. This must be assigned in CIL. + (role object_r) + + (block unconfined + (user user) + (role role) + (type process) + (type object) + (userrange user (systemLow systemLow)) + (userlevel user systemLow) + (userrole user role) + (userrole user object_r) + (roletype role process) + (roletype role object) + (roletype object_r object) + + (class file (open execute read write)) + + ; There must be least one allow rule in a policy: + (allow process self (file (read))) + + (context context_1 (user object_r object low_low)) + ) ; End unconfined namespace + +rangetransition +--------------- + +Allows an objects level to transition to a different level. Generally used to ensure processes run with their correct MLS range, for example `init` would run at `SystemHigh` and needs to initialise / run other processes at their correct MLS range. + +**Statement definition:** + + (rangetransition source_id target_id class_id new_range_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

rangetransition

The rangetransition keyword.

source_type_id

A single previously declared type, typealias or typeattribute identifier.

target_type_id

A single previously declared type, typealias or typeattribute identifier.

class_id

A single previously declared class or classmap identifier.

new_range_id

The new MLS range for the object class that is a previously declared levelrange identifier. This entry may also be defined as an anonymous or named level, sensitivity, sensitivityalias, category, categoryalias or categoryset identifier.

+ +**Examples:** + +This rule will transition the range of `sshd.exec` to `s0 - s1:c0.c3` on execution from the `init.process`: + + (sensitivity s0) + (sensitivity s1) + (sensitivityorder s0 s1) + (category c0) + ... + (level systemlow (s0) + (level systemhigh (s1 (c0 c1 c2))) + (levelrange low_high (systemlow systemhigh)) + + (rangetransition init.process sshd.exec process low_high) diff --git a/secilc/docs/cil_mls_labeling_statements.xml b/secilc/docs/cil_mls_labeling_statements.xml deleted file mode 100644 index 3738789..0000000 --- a/secilc/docs/cil_mls_labeling_statements.xml +++ /dev/null @@ -1,733 +0,0 @@ - - - - - Multi-Level Security Labeling Statements - Because there are many options for MLS labeling, the examples show a limited selection of statements, however there is a simple policy that will build shown in the levelrange section. - - sensitivity - Declare a sensitivity identifier in the current namespace. Multiple sensitivity statements in the policy will form an ordered list. - Statement definition: - - Where: - - - - - - - - sensitivity - - - The sensitivity keyword. - - - - - sensitivity_id - - - The sensitivity identifier. - - - - - - Example: - This example declares three sensitivity identifiers: - - - - - - sensitivityalias - Declares a sensitivity alias identifier in the current namespace. See the sensitivityaliasactual statement for an example that associates the sensitivityalias identifier. - Statement definition: - - Where: - - - - - - - - sensitivityalias - - - The sensitivityalias keyword. - - - - - sensitivityalias_id - - - The sensitivityalias identifier. - - - - - Example: - See the sensitivityaliasactual statement. - - - - sensitivityaliasactual - Associates a previously declared sensitivityalias identifier to a previously declared sensitivity identifier. - Statement definition: - - Where: - - - - - - - - sensitivityaliasactual - - - The sensitivityaliasactual keyword. - - - - - sensitivityalias_id - - - A single previously declared sensitivityalias identifier. - - - - - sensitivity_id - - - A single previously declared sensitivity identifier. - - - - - - Example: - This example will associate sensitivity s0 with two sensitivity alias's: - - - - - - sensitivityorder - Define the sensitivity order - lowest to highest. Multiple sensitivityorder statements in the policy will form an ordered list. - Statement definition: - - Where: - - - - - - - - sensitivityorder - - - The sensitivityorder keyword. - - - - - sensitivity_id - - - One or more previously declared sensitivity or sensitivityalias identifiers.. - - - - - - Example: - This example shows two sensitivityorder statements that when compiled will form an ordered list. Note however that the second sensitivityorder statement starts with s2 so that the ordered list can be built. - - - - - - category - Declare a category identifier in the current namespace. Multiple category statements declared in the policy will form an ordered list. - Statement definition: - - Where: - - - - - - - - category - - - The category keyword. - - - - - category_id - - - The category identifier. - - - - - - Example: - This example declares a three category identifiers: - - - - - - categoryalias - Declares a category alias identifier in the current namespace. See the categoryaliasactual statement for an example that associates the categoryalias identifier. - Statement definition: - - Where: - - - - - - - - categoryalias - - - The categoryalias keyword. - - - - - categoryalias_id - - - The categoryalias identifier. - - - - - - - - categoryaliasactual - Associates a previously declared categoryalias identifier to a previously declared category identifier. - Statement definition: - - Where: - - - - - - - - categoryaliasactual - - - The categoryaliasactual keyword. - - - - - categoryalias_id - - - A single previously declared categoryalias identifier. - - - - - category_id - - - A single previously declared category identifier. - - - - - - Example: - Declares a category c0, a category alias of documents, and then associates them: - - - - - - categoryorder - Define the category order. Multiple categoryorder statements declared in the policy will form an ordered list. Note that this statement orders the categories to allow validation of category ranges. - Statement definition: - - Where: - - - - - - - - categoryorder - - - The categoryorder keyword. - - - - - category_id - - - One or more previously declared category or categoryalias identifiers. - - - - - - Example: - This example orders one category alias and nine categories: - - - - - - categoryset - Declare an identifier for a set of contiguous or non-contiguous categories in the current namespace. - Notes: - - Category expressions are allowed in categoryset, sensitivitycategory, level, and levelrange statements. - Category sets are not allowed in categoryorder statements. - - Statement definition: - - Where: - - - - - - - - categoryset - - - The categoryset keyword. - - - - - categoryset_id - - - The categoryset identifier. - - - - - category_id - - - Zero or more previously declared category or categoryalias identifiers. - Note that there must be at least one category_id identifier or expr parameter declared. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and (category_id ...) (category_id ...)) - (or (category_id ...) (category_id ...)) - (xor (category_id ...) (category_id ...)) - (not (category_id ...)) - (range category_id category_id) - (all) - - - - - - Examples: - These examples show a selection of categoryset statements: - - - - - - sensitivitycategory - Associate a sensitivity identifier with one or more category's. Multiple definitions for the same sensitivity form an ordered list of categories for that sensitivity. This statement is required before a level identifier can be declared. - Statement definition: - - Where: - - - - - - - - sensitivitycategory - - - The sensitivitycategory keyword. - - - - - sensitivity_id - - - A single previously declared sensitivity or sensitivityalias identifier. - - - - - categoryset_id - - - A single previously declared categoryset (named or anonymous), or a list of category and/or categoryalias identifiers. The examples show each variation. - - - - - - Examples: - These sensitivitycategory examples use a selection of category, categoryalias and categoryset's: - - - - - - level - Declare a level identifier in the current namespace and associate it to a previously declared sensitivity and zero or more categories. Note that if categories are required, then before this statement can be resolved the sensitivitycategory statement must be used to associate categories with the sensitivity. - Statement definition: - - Where: - - - - - - - - level - - - The level keyword. - - - - - level_id - - - The level identifier. - - - - - sensitivity_id - - - A single previously declared sensitivity or sensitivityalias identifier. - - - - - categoryset_id - - - A single previously declared categoryset (named or anonymous), or a list of category and/or categoryalias identifiers. The examples show each variation. - - - - - - Examples: - These level examples use a selection of category, categoryalias and categoryset's: - - - - - - levelrange - Declare a level range identifier in the current namespace and associate a current and clearance level. - Statement definition: - - Where: - - - - - - - - levelrange - - - The levelrange keyword. - - - - - levelrange_id - - - The levelrange identifier. - - - - - low_level_id - - - The current level specified by a previously declared level identifier. This may be formed by named or anonymous components as discussed in the level section and shown in the examples. - - - - - high_level_id - - - The clearance or high level specified by a previously declared level identifier. This may be formed by named or anonymous components as discussed in the level section and shown in the examples. - - - - - Examples: - This example policy shows levelrange statement and all the other MLS labeling statements discussed in this section and will compile as a standalone policy: - - - - - - rangetransition - Allows an objects level to transition to a different level. Generally used to ensure processes run with their correct MLS range, for example init would run at SystemHigh and needs to initialise / run other processes at their correct MLS range. - Statement definition: - - Where: - - - - - - - - rangetransition - - - The rangetransition keyword. - - - - - source_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - target_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - class_id - - - A single previously declared class or classmap identifier. - - - - - new_range_id - - - The new MLS range for the object class that is a previously declared levelrange identifier. This entry may also be defined as an anonymous or named level, sensitivity, sensitivityalias, category, categoryalias or categoryset identifier. - - - - - - Examples: - This rule will transition the range of sshd.exec to s0 - s1:c0.c3 on execution from the init.process: - - - - - - mlsconstrain - This is described in the Contraints section. - - - - mlsvalidatetrans - This is described in the Contraints section. - - - diff --git a/secilc/docs/cil_network_labeling_statements.md b/secilc/docs/cil_network_labeling_statements.md new file mode 100644 index 0000000..183b350 --- /dev/null +++ b/secilc/docs/cil_network_labeling_statements.md @@ -0,0 +1,201 @@ +Network Labeling Statements +=========================== + +ipaddr +------ + +Declares a named IP address in IPv4 or IPv6 format that may be referenced by other CIL statements (i.e. [`netifcon`](cil_network_labeling_statements.md#netifcon)). + +Notes: + +- CIL statements utilising an IP address may reference a named IP address or use an anonymous address, the examples will show each option. + +- IP Addresses may be declared without a previous declaration by enclosing within parentheses e.g. `(127.0.0.1)` or `(::1)`. + +**Statement definition:** + + (ipaddr ipaddr_id ip_address) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

ipaddr

The ipaddr keyword.

ipaddr_id

The IP address identifier.

ip_address

A correctly formatted IP address in IPv4 or IPv6 format.

+ +**Example:** + +This example declares a named IP address and also passes an 'explicit anonymously declared' IP address to a macro: + + (ipaddr netmask_1 255.255.255.0) + (context netlabel_1 (system.user object_r unconfined.object low_low) + + (call build_nodecon ((192.168.1.64) netmask_1)) + + (macro build_nodecon ((ipaddr ARG1) (ipaddr ARG2)) + (nodecon ARG1 ARG2 netlabel_1)) + +netifcon +-------- + +Label network interface objects (e.g. `eth0`). + +**Statement definition:** + + (netifcon netif_name netif_context_id packet_context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

netifcon

The netifcon keyword.

netif_name

The network interface name (e.g. wlan0).

netif_context_id

The security context to be allocated to the network interface.

+

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

packet_context_id

The security context to be allocated to packets. Note that these are defined but currently unused as the iptables(8) SECMARK services should be used to label packets.

+

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Examples:** + +These examples show named and anonymous [`netifcon`](cil_network_labeling_statements.md#netifcon) statements: + + (context context_1 (unconfined.user object_r unconfined.object low_low)) + (context context_2 (unconfined.user object_r unconfined.object (systemlow level_2))) + + (netifcon eth0 context_1 (unconfined.user object_r unconfined.object levelrange_1)) + (netifcon eth1 context_1 (unconfined.user object_r unconfined.object ((s0) level_1))) + (netifcon eth3 context_1 context_2) + +nodecon +------- + +Label network address objects that represent IPv4 or IPv6 IP addresses and network masks. + +IP Addresses may be declared without a previous declaration by enclosing within parentheses e.g. `(127.0.0.1)` or `(::1)`. + +**Statement definition:** + + (nodecon subnet_id netmask_id context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

nodecon

The nodecon keyword.

subnet_id

A previously declared ipaddr identifier, or an anonymous IPv4 or IPv6 formatted address.

netmask_id

A previously declared ipaddr identifier, or an anonymous IPv4 or IPv6 formatted address.

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Examples:** + +These examples show named and anonymous [`nodecon`](cil_network_labeling_statements.md#nodecon) statements: + + (context context_1 (unconfined.user object_r unconfined.object low_low)) + (context context_2 (unconfined.user object_r unconfined.object (systemlow level_2))) + + (ipaddr netmask_1 255.255.255.0) + (ipaddr ipv4_1 192.168.1.64) + + (nodecon netmask_1 ipv4_1 context_2) + (nodecon (255.255.255.0) (192.168.1.64) context_1) + (nodecon netmask_1 (192.168.1.64) (unconfined.user object_r unconfined.object ((s0) (s0 (c0))))) + +portcon +------- + +Label a udp or tcp port. + +**Statement definition:** + + (portcon protocol port|(port_low port_high) context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

portcon

The portcon keyword.

protocol

The protocol keyword tcp or udp.

port |

+

(port_low port_high)

A single port to apply the context, or a range of ports.

+

The entries must consist of numerics [0-9].

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Examples:** + +These examples show named and anonymous [`portcon`](cil_network_labeling_statements.md#portcon) statements: + + (portcon tcp 1111 (unconfined.user object_r unconfined.object ((s0) (s0 (c0))))) + (portcon tcp 2222 (unconfined.user object_r unconfined.object levelrange_2)) + (portcon tcp 3333 (unconfined.user object_r unconfined.object levelrange_1)) + (portcon udp 4444 (unconfined.user object_r unconfined.object ((s0) level_2))) + (portcon tcp (2000 20000) (unconfined.user object_r unconfined.object (systemlow level_3))) diff --git a/secilc/docs/cil_network_labeling_statements.xml b/secilc/docs/cil_network_labeling_statements.xml deleted file mode 100644 index 1047108..0000000 --- a/secilc/docs/cil_network_labeling_statements.xml +++ /dev/null @@ -1,244 +0,0 @@ - - - - - Network Labeling Statements - - ipaddr - Declares a named IP address in IPv4 or IPv6 format that may be referenced by other CIL statements (i.e. netifcon). - Notes: - - CIL statements utilising an IP address may reference a named IP address or use an anonymous address, the examples will show each option. - - IP Addresses may be declared without a previous declaration by enclosing within parentheses e.g. (127.0.0.1) or (::1). - - Statement definition: - - Where: - - - - - - - - ipaddr - - - The ipaddr keyword. - - - - - ipaddr_id - - - The IP address identifier. - - - - - ip_address - - - A correctly formatted IP address in IPv4 or IPv6 format. - - - - - - Example: - This example declares a named IP address and also passes an 'explicit anonymously declared' IP address to a macro: - - - - - - netifcon - Label network interface objects (e.g. eth0). - Statement definition: - - Where: - - - - - - - - netifcon - - - The netifcon keyword. - - - - - netif_name - - - The network interface name (e.g. wlan0). - - - - - netif_context_id - - - The security context to be allocated to the network interface. - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - packet_context_id - - - The security context to be allocated to packets. Note that these are defined but currently unused as the iptables(8) SECMARK services should be used to label packets. - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Examples: - These examples show named and anonymous netifcon statements: - - - - - - nodecon - Label network address objects that represent IPv4 or IPv6 IP addresses and network masks. - IP Addresses may be declared without a previous declaration by enclosing within parentheses e.g. (127.0.0.1) or (::1). - Statement definition: - - Where: - - - - - - - - nodecon - - - The nodecon keyword. - - - - - subnet_id - - - A previously declared ipaddr identifier, or an anonymous IPv4 or IPv6 formatted address. - - - - - netmask_id - - - A previously declared ipaddr identifier, or an anonymous IPv4 or IPv6 formatted address. - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Examples: - These examples show named and anonymous nodecon statements: - - - - - - portcon - Label a udp or tcp port. - Statement definition: - - Where: - - - - - - - - portcon - - - The portcon keyword. - - - - - protocol - - - The protocol keyword tcp or udp. - - - - - port | - (port_low port_high) - - - A single port to apply the context, or a range of ports. - The entries must consist of numerics [0-9]. - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Examples: - These examples show named and anonymous portcon statements: - - - - - diff --git a/secilc/docs/cil_policy_config_statements.md b/secilc/docs/cil_policy_config_statements.md new file mode 100644 index 0000000..392976f --- /dev/null +++ b/secilc/docs/cil_policy_config_statements.md @@ -0,0 +1,113 @@ +Policy Configuration Statements +=============================== + +mls +--- + +Defines whether the policy is built as an MLS or non-MLS policy by the CIL compiler. There MUST only be one [`mls`](cil_policy_config_statements.md#mls) entry in the policy otherwise the compiler will exit with an error. + +Note that this can be over-ridden by the CIL compiler command line parameter `-M true|false` or `--mls true|false` flags. + +**Statement definition:** + + (mls boolean) + +**Where:** + + ++++ + + + + + + + + + + +

mls

The mls keyword.

boolean

Set to either true or false.

+ +**Example:** + + (mls true) + +handleunknown +------------- + +Defines how the kernel will handle unknown object classes and permissions when loading the policy. There MUST only be one [`handleunknown`](cil_policy_config_statements.md#handleunknown) entry in the policy otherwise the compiler will exit with an error. + +Note that this can be over-ridden by the CIL compiler command line parameter `-U` or `--handle-unknown` flags. + +**Statement definition:** + + (handleunknown action) + +**Where:** + + ++++ + + + + + + + + + + +

handleunknown

The handleunknown keyword.

action

A keyword of either allow, deny or reject. The kernel will handle these keywords as follows:

+

allow unknown class / permissions. This will set the returned AV with all 1's.

+

deny unknown class / permissions (the default). This will set the returned AV with all 0's.

+

reject loading the policy if it does not contain all the object classes / permissions.

+ +**Example:** + +This will allow unknown classes / permissions to be present in the policy: + + (handleunknown allow) + +policycap +--------- + +Allow policy capabilities to be enabled via policy. These should be declared in the global namespace and be valid policy capabilities as they are checked against those known in libsepol by the CIL compiler. + +**Statement definition:** + + (policycap policycap_id) + +**Where:** + + ++++ + + + + + + + + + + +

policycap

The policycap keyword.

policycap_id

The policycap identifer (e.g. open_perms).

+ +**Example:** + +These set two valid policy capabilities: + + ; Enable networking controls. + (policycap network_peer_controls) + + ; Enable open permission check. + (policycap open_perms) diff --git a/secilc/docs/cil_policy_config_statements.xml b/secilc/docs/cil_policy_config_statements.xml deleted file mode 100644 index 771e4dd..0000000 --- a/secilc/docs/cil_policy_config_statements.xml +++ /dev/null @@ -1,118 +0,0 @@ - - - - - Policy Configuration Statements - - mls - Defines whether the policy is built as an MLS or non-MLS policy by the CIL compiler. There MUST only be one mls entry in the policy otherwise the compiler will exit with an error. - Note that this can be over-ridden by the CIL compiler command line parameter -M true|false or --mls true|false flags. - Statement definition: - - Where: - - - - - - - - mls - - - The mls keyword. - - - - - boolean - - - Set to either true or false. - - - - - Example: - - - - - handleunknown - Defines how the kernel will handle unknown object classes and permissions when loading the policy. There MUST only be one handleunknown entry in the policy otherwise the compiler will exit with an error. - Note that this can be over-ridden by the CIL compiler command line parameter -U or --handle-unknown flags. - Statement definition: - - Where: - - - - - - - - handleunknown - - - The handleunknown keyword. - - - - - action - - - A keyword of either allow, deny or reject. The kernel will handle these keywords as follows: - allow unknown class / permissions. This will set the returned AV with all 1's. - deny unknown class / permissions (the default). This will set the returned AV with all 0's. - reject loading the policy if it does not contain all the object classes / permissions. - - - - - Example: - This will allow unknown classes / permissions to be present in the policy: - - - - - policycap - Allow policy capabilities to be enabled via policy. These should be declared in the global namespace and be valid policy capabilities as they are checked against those known in libsepol by the CIL compiler. - Statement definition: - - Where: - - - - - - - - policycap - - - The policycap keyword. - - - - - policycap_id - - - The policycap identifer (e.g. open_perms). - - - - - Example: - These set two valid policy capabilities: - - - - - diff --git a/secilc/docs/cil_reference_guide.md b/secilc/docs/cil_reference_guide.md new file mode 100644 index 0000000..d179c3c --- /dev/null +++ b/secilc/docs/cil_reference_guide.md @@ -0,0 +1,298 @@ +CIL Information +=============== + +1. Not all possible alternate statement permutations are shown, however there should be enough variation to work out any other valid formats. There is also an example [`policy.cil`](../test/policy.cil#example-policy) file in the test directory. + +2. The MLS components on contexts and user statements must be declared even if the policy does not support MCS/MLS. + +3. The CIL compiler will not build a policy unless it also has as a minimum: one [`allow`](cil_access_vector_rules.md#allow) rule, one [`sid`](cil_sid_statements.md#sid), [`sidorder`](cil_sid_statements.md#sidorder) and [`sidcontext`](cil_sid_statements.md#sidcontext) statement. + +4. The role `object_r` must be explicitly associated to contexts used for labeling objects. The original **`checkpolicy`**`(8)` and **`checkmodule`**`(8)` compilers did this by default - CIL does not. + +5. Be aware that CIL allows [`class`](cil_class_and_permission_statements.md#class) statements to be declared in a namespace, however the policy author needs to note that applications (and the kernel) generally reference a class by its well known class identifier (e.g. `zygote`) however if declared in a namespace (e.g. `(block zygote (class zygote (...)))` or `(block zygote (class class (...)))`) it would be prefixed with that namespace (e.g. `zygote.zygote` or `zygote.class`). Unless the application / kernel code was updated the class would never be resolved, therefore it is recommended that classes are declared in the global namespace. + +6. Where possible use [`typeattribute`](cil_type_statements.md#typeattribute)'s when defining source/target [`allow`](cil_access_vector_rules.md#allow) rules instead of multiple [`allow`](cil_access_vector_rules.md#allow) rules with individual [`type`](cil_type_statements.md#type)'s. This will lead to the generation of much smaller kernel policy files. + +7. The [](http://github.com/SELinuxProject/cil/wiki) site explains the language however some of the statement definitions are dated. + +Declarations +------------ + +Declarations may be named or anonymous and have three different forms: + +1. Named declarations - These create new objects that introduce a name or identifier, for example: + + `(type process)` - creates a [`type`](cil_type_statements.md#type) with an identifier of `process`. + + `(typeattribute domain)` - creates a [`typeattribute`](cil_type_statements.md#typeattribute) with an identifier of `domain`. + + `(class file (read write))` - creates a [`class`](cil_class_and_permission_statements.md#class) with an identifier of `file` that has `read` and `write` permissions associated to it. + + The list of declaration type statement keywords are: + + block + optional + common + class + classmap + classmapping + sid + user + role + roleattribute + type + classpermission + classpermissionset + typeattribute + typealias + tunable + sensitivity + sensitivityalias + category + categoryalias + categoryset + level + levelrange + context + ipaddr + macro + policycap +2. Explicit anonymous declarations - These are currently restricted to IP addesses where they can be declared directly in statements by enclosing them within parentheses e.g. `(127.0.0.1)` or `(::1)`. See the [Network Labeling Statements](#network_labeling) section for examples. + +3. Anonymous declarations - These have been previously declared and the object already exists, therefore they may be referenced by their name or identifier within statements. For example the following declare all the components required to specify a context: + + (sensitivity s0) + (category c0) + (role object_r) + + (block unconfined + (user user) + (type object) + ) + + now a [`portcon`](cil_network_labeling_statements.md#portcon) statement can be defined that uses these individual components to build a context as follows: + + (portcon udp 12345 (unconfined.user object_r unconfined.object ((s0) (s0(c0))))) + +Definitions +----------- + +Statements that build on the objects, for example: + +- `(typeattributeset domain (process))` - Adds the [`type`](cil_type_statements.md#type) '`process`' to the [`typeattribute`](cil_type_statements.md#typeattribute) '`domain`'. + +- `(allow domain process (file (read write))))` - Adds an [`allow`](cil_access_vector_rules.md#allow) rule referencing `domain`, `process` and the `file class`. + +Definitions may be repeated many times throughout the policy. Duplicates will resolve to a single definition during compilation. + +Symbol Character Set +-------------------- + +Symbols (any string not enclosed in double quotes) must only contain alphanumeric `[a-z A-Z] [0-9]` characters plus the following special characters: `\.@=/-_$%@+!|&^:` + +However symbols are checked for any specific character set limitations, for example: + +- Names or identifiers must start with an alpa character `[a-z A-Z]`, the remainder may be alphanumeric `[a-z A-Z] [0-9]` characters plus underscore `[_]` or hyphen `[-]`. + +- IP addresses must conform to IPv4 or IPv6 format. + +- Memory, ports, irqs must be numeric `[0-9]`. + +String Character Set +-------------------- + +Strings are enclosed within double quotes (e.g. `"This is a string"`), and may contain any character except the double quote ("). + +Comments +-------- + +Comments start with a semicolon '`;`' and end when a new line is started. + +Namespaces +---------- + +CIL supports namespaces via containers such as the [`block`](cil_container_statements.md#block) statement. When a block is resolved to form the parent / child relationship a dot '`.`' is used, for example the following [`allow`](cil_access_vector_rules.md#allow) rule: + + (block example_ns + (type process) + (type object) + (class file (open read write getattr)) + + (allow process object (file (open read getattr))) + ) + +will resolve to the following kernel policy language statement: + + allow example_ns.process example_ns.object : example_ns.file { open read getattr }; + +Global Namespace +---------------- + +CIL has a global namespace that is always present. Any symbol that is declared outside a container is in the global namespace. To reference a symbol in global namespace, the symbol should be prefixed with a dot '`.`' as shown in the following example: + + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; + ; This example has three namespace 'tmpfs' types declared: + ; 1) Global .tmpfs + ; 2) file.tmpfs + ; 3) other_ns.tmpfs + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; + + ; This type is the global tmpfs: + (type tmpfs) + + (block file + ; file namespace tmpfs + (type tmpfs) + (class file (open read write getattr)) + + ; This rule will reference the local namespace for src and tgt: + (allow tmpfs tmpfs (file (open))) + ; Resulting policy rule: + ; allow file.tmpfs file.tmpfs : file.file open; + + ; This rule will reference the local namespace for src and global for tgt: + (allow tmpfs .tmpfs (file (read))) + ; Resulting policy rule: + ; allow file.tmpfs tmpfs : file.file read; + + ; This rule will reference the global namespace for src and tgt: + (allow .tmpfs .tmpfs (file (write))) + ; Resulting policy rule: + ; allow tmpfs tmpfs : file.file write; + + ; This rule will reference the other_ns namespace for src and + ; local namespace for tgt: + (allow other_ns.tmpfs tmpfs (file (getattr))) + ; Resulting policy rule: + ; allow other_ns.tmpfs file.tmpfs : file.file getattr; + ) + + (block other_ns + (type tmpfs) + ) + +Should the symbol not be prefixed with a dot, the current namespace would be searched first and then the global namespace (provided there is not a symbol of that name in the current namespace). + +Expressions +----------- + +Expressions may occur in the following CIL statements: [`booleanif`](cil_conditional_statements.md#booleanif), [`tunableif`](cil_conditional_statements.md#tunableif), [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset), [`typeattributeset`](cil_type_statements.md#typeattributeset), [`roleattributeset`](cil_role_statements.md#roleattributeset), [`categoryset`](cil_mls_labeling_statements.md#categoryset), [`constrain`](cil_constraint_statements.md#constrain), [`mlsconstrain`](cil_constraint_statements.md#mlsconstrain), [`validatetrans`](cil_constraint_statements.md#validatetrans), [`validatetrans`](cil_constraint_statements.md#validatetrans) + +CIL expressions use the [prefix](http://www.cs.man.ac.uk/~pjj/cs212/fix.html) or Polish notation and may be nested (note that the kernel policy language uses postfix or reverse Polish notation). The syntax is as follows, where the parenthesis are part of the syntax: + + expr_set = (name ... | expr ...) + expr = (expr_key expr_set ...) + expr_key = and | or | xor | not | all | eq | neq | dom | domby | incomp | range + +The number of `expr_set`'s in an `expr` is dependent on the statement type (there are four different classes as defined below) that also influence the valid `expr_key` entries (e.g. `dom`, `domby`, `incomp` are only allowed in constraint statements). + +| expr_key | classpermissionset roleattributeset typeattributeset | categoryset | booleanif tunableif | constrain mlsconstrain validatetrans mlsvalidatetrans | +|:----------:|:----------:|:----------:|:----------:|:----------:| +| **`dom`** | | | | **X** | +| **`domby`** | | | | **X** | +| **`incomp`** | | | | **X** | +| **`eq`** | | | **X** | **X** | +| **`ne`** | | | **X** | **X** | +| **`and`** | **X** | **X** | **X** | **X** | +| **`or`** | **X** | **X** | **X** | **X** | +| **`not`** | **X** | **X** | **X** | **X** | +| **`xor`** | **X** | **X** | **X** | | +| **`all`** | **X** | **X** | | | +| **`range`** | | **X** | | | + +1. The [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset), [`roleattributeset`](cil_role_statements.md#roleattributeset) and [`typeattributeset`](cil_type_statements.md#typeattributeset) statements allow `expr_set` to mix names and `expr`s with `expr_key` values of: `and`, `or`, `xor`, `not`, `all` as shown in the examples: + + This example includes all `fs_type type` entries except `file.usermodehelper` and `file.proc_security` in the associated [`typeattribute`](cil_type_statements.md#typeattribute) identifier `all_fs_type_except_usermodehelper_and_proc_security`: + + (typeattribute all_fs_type_except_usermodehelper_and_proc_security) + + (typeattributeset all_fs_type_except_usermodehelper_and_proc_security + (and + (and + fs_type + (not file.usermodehelper) + ) + (not file.proc_security) + ) + ) + + The `cps_1 classpermissionset` identifier includes all permissions except `load_policy` and `setenforce`: + + (class security (compute_av compute_create compute_member check_context load_policy compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot read_policy)) + + (classpermission cps_1) + + (classpermissionset cps_1 (security (not (load_policy setenforce)))) + + This example includes all permissions in the associated [`classpermissionset`](cil_class_and_permission_statements.md#classpermissionset) identifer `security_all_perms`: + + (class security (compute_av compute_create compute_member check_context load_policy + compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot + read_policy) + ) + + (classpermission security_all_perms) + + (classpermissionset security_all_perms (security (all))) + +2. The [`categoryset`](cil_mls_labeling_statements.md#categoryset) statement allows `expr_set` to mix names and `expr_key` values of: `and`, `or`, `not`, `xor`, `all`, `range` as shown in the examples. + + Category expressions are also allowed in [`sensitivitycategory`](cil_mls_labeling_statements.md#sensitivitycategory), [`level`](cil_mls_labeling_statements.md#level), and [`levelrange`](cil_mls_labeling_statements.md#levelrange) statements. + +3. The [`booleanif`](cil_conditional_statements.md#booleanif) and [`tunableif`](cil_conditional_statements.md#tunableif) statements only allow an `expr_set` to have one `name` or `expr` with `expr_key` values of `and`, `or`, `xor`, `not`, `eq`, `neq` as shown in the examples: + + (booleanif disableAudio + (false + (allow process device.audio_device (chr_file_set (rw_file_perms))) + ) + ) + + (booleanif (and (not disableAudio) (not disableAudioCapture)) + (true + (allow process device.audio_capture_device (chr_file_set (rw_file_perms))) + ) + ) + +4. The [`constrain`](cil_constraint_statements.md#constrain), [`mlsconstrain`](cil_constraint_statements.md#mlsconstrain), [`validatetrans`](cil_constraint_statements.md#validatetrans) and [`mlsvalidatetrans`](cil_constraint_statements.md#mlsvalidatetrans) statements only allow an `expr_set` to have one `name` or `expr` with `expr_key` values of `and`, `or`, `not`, `all`, `eq`, `neq`, `dom`, `domby`, `incomp`. When `expr_key` is `dom`, `domby` or `incomp`, it must be followed by a string (e.g. `h1`, `l2`) and another string or a set of `name`s. The following examples show CIL constraint statements and their policy language equivalents: + + ; Process transition: Require equivalence unless the subject is trusted. + (mlsconstrain (process (transition dyntransition)) + (or (and (eq h1 h2) (eq l1 l2)) (eq t1 mlstrustedsubject))) + + ; The equivalent policy language mlsconstrain statememt is: + ;mlsconstrain process { transition dyntransition } + ; ((h1 eq h2 and l1 eq l2) or t1 == mlstrustedsubject); + + ; Process read operations: No read up unless trusted. + (mlsconstrain (process (getsched getsession getpgid getcap getattr ptrace share)) + (or (dom l1 l2) (eq t1 mlstrustedsubject))) + + ; The equivalent policy language mlsconstrain statememt is: + ;mlsconstrain process { getsched getsession getpgid getcap getattr ptrace share } + ; (l1 dom l2 or t1 == mlstrustedsubject); + +Name String +----------- + +Used to define [`macro`](cil_call_macro_statements.md#macro) statement parameter string types: + + (call macro1("__kmsg__")) + + (macro macro1 ((string ARG1)) + (typetransition audit.process device.device chr_file ARG1 device.klog_device) + ) + +Alternatively: + + (call macro1("__kmsg__")) + + (macro macro1 ((name ARG1)) + (typetransition audit.process device.device chr_file ARG1 device.klog_device) + ) + +self +---- + +The [`self`](cil_reference_guide.md#self) keyword may be used as the target in AVC rule statements, and means that the target is the same as the source as shown in the following example:. + + (allow unconfined.process self (file (read write))) diff --git a/secilc/docs/cil_role_statements.md b/secilc/docs/cil_role_statements.md new file mode 100644 index 0000000..0c4cadb --- /dev/null +++ b/secilc/docs/cil_role_statements.md @@ -0,0 +1,320 @@ +Role Statements +=============== + +role +---- + +Declares a role identifier in the current namespace. + +**Statement definition:** + + (role role_id) + +**Where:** + + ++++ + + + + + + + + + + +

role

The role keyword.

role_id

The role identifier.

+ +**Example:** + +This example declares two roles: `object_r` in the global namespace and `unconfined.role`: + + (role object_r) + + (block unconfined + (role role) + ) + +roletype +-------- + +Authorises a [`role`](cil_role_statements.md#role) to access a [`type`](cil_type_statements.md#type) identifier. + +**Statement definition:** + + (role role_id type_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

roletype

The roletype keyword.

role_id

A single previously declared role or roleattribute identifier.

type_id

A single previously declared type, typealias or typeattribute identifier.

+ +**Example:** + +This example will declare [`role`](cil_role_statements.md#role) and [`type`](cil_type_statements.md#type) identifiers, then associate them: + + (block unconfined + (role role) + (type process) + (roletype role process) + ) + +roleattribute +------------- + +Declares a role attribute identifier in the current namespace. The identifier may have zero or more [`role`](cil_role_statements.md#role) and [`roleattribute`](cil_role_statements.md#roleattribute) identifiers associated to it via the [`typeattributeset`](cil_type_statements.md#typeattributeset) statement. + +**Statement definition:** + + (roleattribute roleattribute_id) + +**Where:** + + ++++ + + + + + + + + + + +

roleattribute

The roleattribute keyword.

roleattribute_id

The roleattribute identifier.

+ +**Example:** + +This example will declare a role attribute `roles.role_holder` that will have an empty set: + + (block roles + (roleattribute role_holder) + ) + +roleattributeset +---------------- + +Allows the association of one or more previously declared [`role`](cil_role_statements.md#role) identifiers to a [`roleattribute`](cil_role_statements.md#roleattribute) identifier. Expressions may be used to refine the associations as shown in the examples. + +**Statement definition:** + + (roleattributeset roleattribute_id (role_id ... | expr ...)) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

roleattributeset

The roleattributeset keyword.

roleattribute_id

A single previously declared roleattribute identifier.

role_id

Zero or more previously declared role or roleattribute identifiers.

+

Note that there must be at least one role_id or expr parameter declared.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and (role_id ...) (role_id ...))

+

(or (role_id ...) (role_id ...))

+

(xor (role_id ...) (role_id ...))

+

(not (role_id ...))

+

(all)

+ +**Example:** + +This example will declare three roles and two role attributes, then associate all the roles to them as shown: + + (block roles + (role role_1) + (role role_2) + (role role_3) + + (roleattribute role_holder) + (roleattributeset role_holder (role_1 role_2 role_3)) + + (roleattribute role_holder_all) + (roleattributeset role_holder_all (all)) + ) + +roleallow +--------- + +Authorise the current role to assume a new role. + +Notes: + +- May require a [`roletransition`](cil_role_statements.md#roletransition) rule to ensure transition to the new role. + +- This rule is not allowed in [`booleanif`](cil_conditional_statements.md#booleanif) statements. + +**Statement definition:** + + (roleallow current_role_id new_role_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

roleallow

The roleallow keyword.

current_role_id

A single previously declared role or roleattribute identifier.

new_role_id

A single previously declared role or roleattribute identifier.

+ +**Example:** + +See the [`roletransition`](cil_role_statements.md#roletransition) statement for an example. + +roletransition +-------------- + +Specify a role transition from the current role to a new role when computing a context for the target type. The [`class`](cil_class_and_permission_statements.md#class) identifier would normally be `process`, however for kernel versions 2.6.39 with policy version \>= 25 and above, any valid class may be used. Note that a [`roleallow`](cil_role_statements.md#roleallow) rule must be used to authorise the transition. + +**Statement definition:** + + (roletransition current_role_id target_type_id class_id new_role_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

roletransition

The roletransition keyword.

current_role_id

A single previously declared role or roleattribute identifier.

target_type_id

A single previously declared type, typealias or typeattribute identifier.

class_id

A single previously declared class or classmap identifier.

new_role_id

A single previously declared role identifier to be set on transition.

+ +**Example:** + +This example will authorise the `unconfined.role` to assume the `msg_filter.role` role, and then transition to that role: + + (block ext_gateway + (type process) + (type exec) + + (roletype msg_filter.role process) + (roleallow unconfined.role msg_filter.role) + (roletransition unconfined.role exec process msg_filter.role) + ) + +rolebounds +---------- + +Defines a hierarchical relationship between roles where the child role cannot have more privileges than the parent. + +Notes: + +- It is not possible to bind the parent role to more than one child role. + +- While this is added to the binary policy, it is not enforced by the SELinux kernel services. + +**Statement definition:** + + (rolebounds parent_role_id child_role_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

rolebounds

The rolebounds keyword.

parent_role_id

A single previously declared role identifier.

child_role_id

A single previously declared role identifier.

+ +**Example:** + +In this example the role `test` cannot have greater priviledges than `unconfined.role`: + + (role test) + + (unconfined + (role role) + (rolebounds role .test) + ) diff --git a/secilc/docs/cil_role_statements.xml b/secilc/docs/cil_role_statements.xml deleted file mode 100644 index 47ca8c7..0000000 --- a/secilc/docs/cil_role_statements.xml +++ /dev/null @@ -1,374 +0,0 @@ - - - - - - - Role Statements - - role - Declares a role identifier in the current namespace. - Statement definition: - - Where: - - - - - - - - role - - - The role keyword. - - - - - role_id - - - The role identifier. - - - - - - Example: - This example declares two roles: object_r in the global namespace and unconfined.role: - - - - - - roletype - Authorises a role to access a type identifier. - Statement definition: - - Where: - - - - - - - - roletype - - - The roletype keyword. - - - - - role_id - - - A single previously declared role or roleattribute identifier. - - - - - type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - - Example: - This example will declare role and type identifiers, then associate them: - - - - - - roleattribute - Declares a role attribute identifier in the current namespace. The identifier may have zero or more role and roleattribute identifiers associated to it via the typeattributeset statement. - Statement definition: - - Where: - - - - - - - - roleattribute - - - The roleattribute keyword. - - - - - roleattribute_id - - - The roleattribute identifier. - - - - - - Example: - This example will declare a role attribute roles.role_holder that will have an empty set: - - - - - - roleattributeset - Allows the association of one or more previously declared role identifiers to a roleattribute identifier. Expressions may be used to refine the associations as shown in the examples. - Statement definition: - - Where: - - - - - - - - roleattributeset - - - The roleattributeset keyword. - - - - - roleattribute_id - - - A single previously declared roleattribute identifier. - - - - - role_id - - - Zero or more previously declared role or roleattribute identifiers. - Note that there must be at least one role_id or expr parameter declared. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and (role_id ...) (role_id ...)) - (or (role_id ...) (role_id ...)) - (xor (role_id ...) (role_id ...)) - (not (role_id ...)) - (all) - - - - - - Example: - This example will declare three roles and two role attributes, then associate all the roles to them as shown: - - - - - - roleallow - Authorise the current role to assume a new role. - Notes: - - May require a roletransition rule to ensure transition to the new role. - This rule is not allowed in booleanif statements. - - Statement definition: - - Where: - - - - - - - - roleallow - - - The roleallow keyword. - - - - - current_role_id - - - A single previously declared role or roleattribute identifier. - - - - - new_role_id - - - A single previously declared role or roleattribute identifier. - - - - - Example: - See the roletransition statement for an example. - - - - roletransition - Specify a role transition from the current role to a new role when computing a context for the target type. The class identifier would normally be process, however for kernel versions 2.6.39 with policy version >= 25 and above, any valid class may be used. Note that a roleallow rule must be used to authorise the transition. - Statement definition: - - Where: - - - - - - - - roletransition - - - The roletransition keyword. - - - - - current_role_id - - - A single previously declared role or roleattribute identifier. - - - - - target_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - class_id - - - A single previously declared class or classmap identifier. - - - - - new_role_id - - - A single previously declared role identifier to be set on transition. - - - - - - Example: - This example will authorise the unconfined.role to assume the msg_filter.role role, and then transition to that role: - - - - - - rolebounds - Defines a hierarchical relationship between roles where the child role cannot have more privileges than the parent. - Notes: - - It is not possible to bind the parent role to more than one child role. - While this is added to the binary policy, it is not enforced by the SELinux kernel services. - - Statement definition: - - Where: - - - - - - - - rolebounds - - - The rolebounds keyword. - - - - - parent_role_id - - - A single previously declared role identifier. - - - - - child_role_id - - - A single previously declared role identifier. - - - - - Example: - In this example the role test cannot have greater priviledges than unconfined.role: - - - - - diff --git a/secilc/docs/cil_sid_statements.md b/secilc/docs/cil_sid_statements.md new file mode 100644 index 0000000..a9b2537 --- /dev/null +++ b/secilc/docs/cil_sid_statements.md @@ -0,0 +1,125 @@ +SID Statements +============== + +sid +--- + +Declares a new SID identifier in the current namespace. + +**Statement definition:** + + (sid sid_id) + +**Where:** + + ++++ + + + + + + + + + + +

sid

The sid keyword.

sid_id

The sid identifier.

+ +**Examples:** + +These examples show three [`sid`](cil_sid_statements.md#sid) declarations: + + (sid kernel) + (sid security) + (sid igmp_packet) + +sidorder +-------- + +Defines the order of [sid](#sid)'s. This is a mandatory statement when SIDs are defined. Multiple [`sidorder`](cil_sid_statements.md#sidorder) statements declared in the policy will form an ordered list. + +**Statement definition:** + + (sidorder (sid_id ...)) + +**Where:** + + ++++ + + + + + + + + + + +

sidorder

The sidorder keyword.

sid_id

One or more sid identifiers.

+ +**Example:** + +This will produce an ordered list of "`kernel security unlabeled`" + + (sid kernel) + (sid security) + (sid unlabeled) + (sidorder (kernel security)) + (sidorder (security unlabeled)) + +sidcontext +---------- + +Associates an SELinux security [context](#context) to a previously declared [`sid`](cil_sid_statements.md#sid) identifier. + +**Statement definition:** + + (sidcontext sid_id context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

sidcontext

The sidcontext keyword.

sid_id

A single previously declared sid identifier.

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Examples:** + +This shows two named security context examples plus an anonymous context: + + ; Two named context: + (sid kernel) + (context kernel_context (u r process low_low)) + (sidcontext kernel kernel_context) + + (sid security) + (context security_context (u object_r process low_low)) + (sidcontext security security_context) + + ; An anonymous context: + (sid unlabeled) + (sidcontext unlabeled (u object_r ((s0) (s0)))) diff --git a/secilc/docs/cil_sid_statements.xml b/secilc/docs/cil_sid_statements.xml deleted file mode 100644 index c0ca3ff..0000000 --- a/secilc/docs/cil_sid_statements.xml +++ /dev/null @@ -1,142 +0,0 @@ - - - - - SID Statements - - sid - Declares a new SID identifier in the current namespace. - Statement definition: - - Where: - - - - - - - - sid - - - The sid keyword. - - - - - sid_id - - - The sid identifier. - - - - - - Examples: - These examples show three sid declarations: - - - - - - sidorder - Defines the order of sid's. This is a mandatory statement when SIDs are defined. Multiple sidorder statements declared in the policy will form an ordered list. - Statement definition: - - Where: - - - - - - - - sidorder - - - The sidorder keyword. - - - - - sid_id - - - One or more sid identifiers. - - - - - - Example: - This will produce an ordered list of "kernel security unlabeled" - - - - - - sidcontext - Associates an SELinux security context to a previously declared sid identifier. - Statement definition: - - Where: - - - - - - - - sidcontext - - - The sidcontext keyword. - - - - - sid_id - - - A single previously declared sid identifier. - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Examples: - This shows two named security context examples plus an anonymous context: - - - - - diff --git a/secilc/docs/cil_type_statements.md b/secilc/docs/cil_type_statements.md new file mode 100644 index 0000000..f9dd3a7 --- /dev/null +++ b/secilc/docs/cil_type_statements.md @@ -0,0 +1,502 @@ +Type Statements +=============== + +type +---- + +Declares a type identifier in the current namespace. + +**Statement definition:** + + (type type_id) + +**Where:** + + ++++ + + + + + + + + + + +

type

The type keyword.

type_id

The type identifier.

+ +**Example:** + +This example declares a type identifier `bluetooth.process`: + + (block bluetooth + (type process) + ) + +typealias +--------- + +Declares a type alias in the current namespace. + +**Statement definition:** + + (typealias typealias_id) + +**Where:** + + ++++ + + + + + + + + + + +

typealias

The typealias keyword.

typealias_id

The typealias identifier.

+ +**Example:** + +See the [`typealiasactual`](cil_type_statements.md#typealiasactual) statement for an example that associates the [`typealias`](cil_type_statements.md#typealias) identifier. + +typealiasactual +--------------- + +Associates a previously declared [`typealias`](cil_type_statements.md#typealias) identifier to a previously declared [`type`](cil_type_statements.md#type) identifier. + +**Statement definition:** + + (typealiasactual typealias_id type_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

typealiasactual

The typealiasactual keyword.

typealias_id

A single previously declared typealias identifier.

type_id

A single previously declared type identifier.

+ +**Example:** + +This example will alias `unconfined.process` as `unconfined_t` in the global namespace: + + (typealias unconfined_t) + (typealiasactual unconfined_t unconfined.process) + + (block unconfined + (type process) + ) + +typeattribute +------------- + +Declares a type attribute identifier in the current namespace. The identifier may have zero or more [`type`](cil_type_statements.md#type), [`typealias`](cil_type_statements.md#typealias) and [`typeattribute`](cil_type_statements.md#typeattribute) identifiers associated to it via the [`typeattributeset`](cil_type_statements.md#typeattributeset) statement. + +**Statement definition:** + + (typeattribute typeattribute_id) + +**Where:** + + ++++ + + + + + + + + + + +

typeattribute

The typeattribute keyword.

typeattribute_id

The typeattribute identifier.

+ +**Example:** + +This example declares a type attribute `domain` in global namespace that will have an empty set: + + (typeattribute domain) + +typeattributeset +---------------- + +Allows the association of one or more previously declared [`type`](cil_type_statements.md#type), [`typealias`](cil_type_statements.md#typealias) or [`typeattribute`](cil_type_statements.md#typeattribute) identifiers to a [`typeattribute`](cil_type_statements.md#typeattribute) identifier. Expressions may be used to refine the associations as shown in the examples. + +**Statement definition:** + + (typeattributeset typeattribute_id (type_id ... | expr ...)) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

typeattributeset

The typeattributeset keyword.

typeattribute_id

A single previously declared typeattribute identifier.

type_id

Zero or more previously declared type, typealias or typeattribute identifiers.

+

Note that there must be at least one type_id or expr parameter declared.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and (type_id ...) (type_id ...))

+

(or (type_id ...) (type_id ...))

+

(xor (type_id ...) (type_id ...))

+

(not (type_id ...))

+

(all)

+ +**Examples:** + +This example will take all the policy types and exclude those in `appdomain`. It is equivalent to `~appdomain` in the kernel policy language. + + (typeattribute not_in_appdomain) + + (typeattributeset not_in_appdomain (not (appdomain))) + +This example is equivalent to `{ domain -kernel.process -ueventd.process -init.process }` in the kernel policy language: + + (typeattribute na_kernel_or_ueventd_or_init_in_domain) + + (typeattributeset na_kernel_or_ueventd_or_init_in_domain + (and + (and + (and + (domain) + (not (kernel.process)) + ) + (not (ueventd.process)) + ) + (not (init.process)) + ) + ) + +typebounds +---------- + +This defines a hierarchical relationship between domains where the bounded domain cannot have more permissions than its bounding domain (the parent). + +Requires kernel 2.6.28 and above to control the security context associated to threads in multi-threaded applications. Note that an [`allow`](cil_access_vector_rules.md#allow) rule must be used to authorise the bounding. + +**Statement definition:** + + (typebounds parent_type_id child_type_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

typebounds

The typebounds keyword.

parent_type_id

A single previously declared type or typealias identifier that is the parent domain.

child_type_id

A single previously declared type or typealias identifier that is the bound (child) domain.

+ +**Example:** + +In this example the `httpd.child.process` cannot have `file (write)` due to lack of permissions on `httpd.process` which is the parent. It means the child domain will always have equal or less privileges than the parent: + + (class file (getattr read write)) + + (block httpd + (type process) + (type object) + + (typebounds process child.process) + ; The parent is allowed file 'getattr' and 'read': + (allow process object (file (getattr read))) + + (block child + (type process) + (type object) + + ; However the child process has been given 'write' access that will be denied. + (allow process httpd.object (file (read write))) + ) + ) + +typechange +---------- + +The type change rule is used to define a different label of an object for userspace SELinux-aware applications. These applications would use **`security_compute_relabel`**`(3)` and [`typechange`](cil_type_statements.md#typechange) rules in the policy to determine the new context to be applied. Note that an [`allow`](cil_access_vector_rules.md#allow) rule must be used to authorise the change. + +**Statement definition:** + + (typechange source_type_id target_type_id class_id change_type_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

typechange

The typechange keyword.

source_type_id

A single previously declared type, typealias or typeattribute identifier.

target_type_id

A single previously declared type, typealias or typeattribute identifier.

class_id

A single previously declared class or classmap identifier.

change_type_id

A single previously declared type or typealias identifier that will become the new type.

+ +**Example:** + +Whenever **`security_compute_relabel`**`(3)` is called with the following parameters: + +` scon=unconfined.object tcon=unconfined.object class=file` + +the function will return a context of: + +` unconfined.object:object_r:unconfined.change_label:s0` + + (class file (getattr read write)) + + (block unconfined + (type process) + (type object) + (type change_label) + + (typechange object object file change_label) + ) + +typemember +---------- + +The type member rule is used to define a new polyinstantiated label of an object for SELinux-aware applications. These applications would use **`avc_compute_member`**`(3)` or **`security_compute_member`**`(3)` with the [`typemember`](cil_type_statements.md#typemember) rules in the policy to determine the context to be applied. The application would then manage any required polyinstantiation. Note that an [`allow`](cil_access_vector_rules.md#allow) rule must be used to authorise the membership. + +**Statement definition:** + + (typemember source_type_id target_type_id class_id member_type_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + +

typemember

The typemember keyword.

source_type_id

A single previously declared type, typealias or typeattribute identifier.

target_type_id

A single previously declared type, typealias or typeattribute identifier.

class_id

A single previously declared class or classmap identifier.

member_type_id

A single previously declared type or typealias identifier that will become the new member type.

+ +**Example:** + +Whenever **`avc_compute_member`**`(3)` or **`security_compute_member`**`(3)` is called with the following parameters: + +` scon=unconfined.object tcon=unconfined.object class=file` + +the function will return a context of: + +` unconfined.object:object_r:unconfined.member_label:s0` + + (class file (getattr read write)) + + (block unconfined + (type process) + (type object) + (type change_label) + + (typemember object object file member_label) + ) + +typetransition +-------------- + +The type transition rule specifies the labeling and object creation allowed between the `source_type` and `target`\_type when a domain transition is requested. Kernels from 2.6.39 with policy versions from 25 and above also support a 'name transition' rule, however this is not allowed inside conditionals and currently only supports the file classes. Note that an [`allow`](cil_access_vector_rules.md#allow) rule must be used to authorise the transition. + +**Statement definition:** + + (typetransition source_type_id target_type_id class_id [object_name] default_type_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +

typetransition

The typetransition keyword.

source_type_id

A single previously declared type, typealias or typeattribute identifier.

target_type_id

A single previously declared type, typealias or typeattribute identifier.

class_id

A single previously declared class or classmap identifier.

object_name

A optional string within double quotes representing an object name for the 'name transition' rule. This string will be matched against the objects name (if a path then the last component of that path). If the string matches exactly, the default_type_id will then become the new type.

default_type_id

A single previously declared type or typealias identifier that will become the new type.

+ +**Examples:** + +This example shows a process transition rule with its supporting [`allow`](cil_access_vector_rules.md#allow) rule: + + (macro domain_auto_trans ((type ARG1) (type ARG2) (type ARG3)) + ; Allow the necessary permissions. + (call domain_trans (ARG1 ARG2 ARG3)) + ; Make the transition occur by default. + (typetransition ARG1 ARG2 process ARG3) + ) + +This example shows a file object transition rule with its supporting [`allow`](cil_access_vector_rules.md#allow) rule: + + (macro tmpfs_domain ((type ARG1)) + (type tmpfs) + (typeattributeset file_type (tmpfs)) + (typetransition ARG1 file.tmpfs file tmpfs) + (allow ARG1 tmpfs (file (read write execute execmod))) + ) + +This example shows the 'name transition' rule with its supporting [`allow`](cil_access_vector_rules.md#allow) rule: + + (macro write_klog ((type ARG1)) + (typetransition ARG1 device.device chr_file "__kmsg__" device.klog_device) + (allow ARG1 device.klog_device (chr_file (create open write unlink))) + (allow ARG1 device.device (dir (write add_name remove_name))) + ) + +typepermissive +-------------- + +Policy database version 23 introduced the permissive statement to allow the named domain to run in permissive mode instead of running all SELinux domains in permissive mode (that was the only option prior to version 23). Note that the permissive statement only tests the source context for any policy denial. + +**Statement definition:** + + (typepermissive source_type_id) + +**Where:** + + ++++ + + + + + + + + + + +

typepermissive

The typepermissive keyword.

source_type_id

A single previously declared type or typealias identifier.

+ +**Example:** + +This example will allow SELinux to run the `healthd.process` domain in permissive mode even when enforcing is enabled: + + (block healthd + (type process) + (typepermissive process) + + (allow ...) + ) diff --git a/secilc/docs/cil_type_statements.xml b/secilc/docs/cil_type_statements.xml deleted file mode 100644 index b140f86..0000000 --- a/secilc/docs/cil_type_statements.xml +++ /dev/null @@ -1,581 +0,0 @@ - - - - - Type Statements - - type - Declares a type identifier in the current namespace. - Statement definition: - - Where: - - - - - - - - type - - - The type keyword. - - - - - type_id - - - The type identifier. - - - - - - Example: - This example declares a type identifier bluetooth.process: - - - - - - typealias - Declares a type alias in the current namespace. - Statement definition: - - Where: - - - - - - - - typealias - - - The typealias keyword. - - - - - typealias_id - - - The typealias identifier. - - - - - Example: - See the typealiasactual statement for an example that associates the typealias identifier. - - - - typealiasactual - Associates a previously declared typealias identifier to a previously declared type identifier. - Statement definition: - - Where: - - - - - - - - typealiasactual - - - The typealiasactual keyword. - - - - - typealias_id - - - A single previously declared typealias identifier. - - - - - type_id - - - A single previously declared type identifier. - - - - - - Example: - This example will alias unconfined.process as unconfined_t in the global namespace: - - - - - - typeattribute - Declares a type attribute identifier in the current namespace. The identifier may have zero or more type, typealias and typeattribute identifiers associated to it via the typeattributeset statement. - Statement definition: - - Where: - - - - - - - - typeattribute - - - The typeattribute keyword. - - - - - typeattribute_id - - - The typeattribute identifier. - - - - - - Example: - This example declares a type attribute domain in global namespace that will have an empty set: - - - - - - typeattributeset - Allows the association of one or more previously declared type, typealias or typeattribute identifiers to a typeattribute identifier. Expressions may be used to refine the associations as shown in the examples. - Statement definition: - - Where: - - - - - - - - typeattributeset - - - The typeattributeset keyword. - - - - - typeattribute_id - - - A single previously declared typeattribute identifier. - - - - - type_id - - - Zero or more previously declared type, typealias or typeattribute identifiers. - Note that there must be at least one type_id or expr parameter declared. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and (type_id ...) (type_id ...)) - (or (type_id ...) (type_id ...)) - (xor (type_id ...) (type_id ...)) - (not (type_id ...)) - (all) - - - - - - Examples: - This example will take all the policy types and exclude those in appdomain. It is equivalent to ~appdomain in the kernel policy language. - - - This example is equivalent to { domain -kernel.process -ueventd.process -init.process } in the kernel policy language: - - - - - - typebounds - This defines a hierarchical relationship between domains where the bounded domain cannot have more permissions than its bounding domain (the parent). - Requires kernel 2.6.28 and above to control the security context associated to threads in multi-threaded applications. Note that an allow rule must be used to authorise the bounding. - Statement definition: - - Where: - - - - - - - - typebounds - - - The typebounds keyword. - - - - - parent_type_id - - - A single previously declared type or typealias identifier that is the parent domain. - - - - - child_type_id - - - A single previously declared type or typealias identifier that is the bound (child) domain. - - - - - Example: - In this example the httpd.child.process cannot have file (write) due to lack of permissions on httpd.process which is the parent. It means the child domain will always have equal or less privileges than the parent: - - - - - - typechange - The type change rule is used to define a different label of an object for userspace SELinux-aware applications. These applications would use security_compute_relabel(3) and typechange rules in the policy to determine the new context to be applied. Note that an allow rule must be used to authorise the change. - Statement definition: - - Where: - - - - - - - - typechange - - - The typechange keyword. - - - - - source_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - target_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - class_id - - - A single previously declared class or classmap identifier. - - - - - change_type_id - - - A single previously declared type or typealias identifier that will become the new type. - - - - - Example: - Whenever security_compute_relabel(3) is called with the following parameters: - scon=unconfined.object tcon=unconfined.object class=file - the function will return a context of: - unconfined.object:object_r:unconfined.change_label:s0 - - - - - - typemember - The type member rule is used to define a new polyinstantiated label of an object for SELinux-aware applications. These applications would use avc_compute_member(3) or security_compute_member(3) with the typemember rules in the policy to determine the context to be applied. The application would then manage any required polyinstantiation. Note that an allow rule must be used to authorise the membership. - Statement definition: - - Where: - - - - - - - - typemember - - - The typemember keyword. - - - - - source_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - target_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - class_id - - - A single previously declared class or classmap identifier. - - - - - member_type_id - - - A single previously declared type or typealias identifier that will become the new member type. - - - - - Example: - Whenever avc_compute_member(3) or security_compute_member(3) is called with the following parameters: - scon=unconfined.object tcon=unconfined.object class=file - the function will return a context of: - unconfined.object:object_r:unconfined.member_label:s0 - - - - - - typetransition - The type transition rule specifies the labeling and object creation allowed between the source_type and target_type when a domain transition is requested. Kernels from 2.6.39 with policy versions from 25 and above also support a 'name transition' rule, however this is not allowed inside conditionals and currently only supports the file classes. Note that an allow rule must be used to authorise the transition. - Statement definition: - - Where: - - - - - - - - typetransition - - - The typetransition keyword. - - - - - source_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - target_type_id - - - A single previously declared type, typealias or typeattribute identifier. - - - - - class_id - - - A single previously declared class or classmap identifier. - - - - - object_name - - - A optional string within double quotes representing an object name for the 'name transition' rule. This string will be matched against the objects name (if a path then the last component of that path). If the string matches exactly, the default_type_id will then become the new type. - - - - - default_type_id - - - A single previously declared type or typealias identifier that will become the new type. - - - - - - Examples: - This example shows a process transition rule with its supporting allow rule: - - - - This example shows a file object transition rule with its supporting allow rule: - - - - This example shows the 'name transition' rule with its supporting allow rule: - - - - - - - typepermissive - Policy database version 23 introduced the permissive statement to allow the named domain to run in permissive mode instead of running all SELinux domains in permissive mode (that was the only option prior to version 23). Note that the permissive statement only tests the source context for any policy denial. - Statement definition: - - Where: - - - - - - - - typepermissive - - - The typepermissive keyword. - - - - - source_type_id - - - A single previously declared type or typealias identifier. - - - - - Example: - This example will allow SELinux to run the healthd.process domain in permissive mode even when enforcing is enabled: - - - - - diff --git a/secilc/docs/cil_user_statements.md b/secilc/docs/cil_user_statements.md new file mode 100644 index 0000000..4075187 --- /dev/null +++ b/secilc/docs/cil_user_statements.md @@ -0,0 +1,455 @@ +User Statements +=============== + +user +---- + +Declares an SELinux user identifier in the current namespace. + +**Statement definition:** + + (user user_id) + +**Where:** + + ++++ + + + + + + + + + + +

user

The user keyword.

user_id

The SELinux user identifier.

+ +**Example:** + +This will declare an SELinux user as `unconfined.user`: + + (block unconfined + (user user) + ) + +userrole +-------- + +Associates a previously declared [`user`](cil_user_statements.md#user) identifier with a previously declared [`role`](cil_role_statements.md#role) identifier. + +**Statement definition:** + + (userrole user_id role_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

userrole

The userrole keyword.

user_id

A previously declared SELinux user or userattribute identifier.

role_id

A previously declared role or roleattribute identifier.

+ +**Example:** + +This example will associate `unconfined.user` to `unconfined.role`: + + (block unconfined + (user user) + (role role) + (userrole user role) + ) + +userattribute +------------- + +Declares a user attribute identifier in the current namespace. The identifier may have zero or more [`user`](cil_user_statements.md#user) and [`userattribute`](cil_user_statements.md#userattribute) identifiers associated to it via the [`userattributeset`](cil_user_statements.md#userattributeset) statement. + +**Statement definition:** + + (userattribute userattribute_id) + +**Where:** + + ++++ + + + + + + + + + + +

userattribute

The userattribute keyword.

userattribute_id

The userattribute identifier.

+ +**Example:** + +This example will declare a user attribute `users.user_holder` that will have an empty set: + + (block users + (userattribute user_holder) + ) + +userattributeset +---------------- + +Allows the association of one or more previously declared [`user`](cil_user_statements.md#user) or [`userattribute`](cil_user_statements.md#userattribute) identifiers to a [`userattribute`](cil_user_statements.md#userattribute) identifier. Expressions may be used to refine the associations as shown in the examples. + +**Statement definition:** + + (userattributeset userattribute_id (user_id ... | expr ...)) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

userattributeset

The userattributeset keyword.

userattribute_id

A single previously declared userattribute identifier.

user_id

Zero or more previously declared user or userattribute identifiers.

+

Note that there must be at least one user_id or expr parameter declared.

expr

Zero or more expr's, the valid operators and syntax are:

+

(and (user_id ...) (user_id ...))

+

(or (user_id ...) (user_id ...))

+

(xor (user_id ...) (user_id ...))

+

(not (user_id ...))

+

(all)

+ +**Example:** + +This example will declare three users and two user attributes, then associate all the users to them as shown: + + (block users + (user user_1) + (user user_2) + (user user_3) + + (userattribute user_holder) + (userattributeset user_holder (user_1 user_2 user_3)) + + (userattribute user_holder_all) + (userattributeset user_holder_all (all)) + ) + +userlevel +--------- + +Associates a previously declared [`user`](cil_user_statements.md#user) identifier with a previously declared [`level`](cil_mls_labeling_statements.md#level) identifier. The [`level`](cil_mls_labeling_statements.md#level) may be named or anonymous. + +**Statement definition:** + + (userlevel user_id level_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

userlevel

The userlevel keyword.

user_id

A previously declared SELinux user identifier.

level_id

A previously declared level identifier. This may consist of a single sensitivity with zero or more mixed named and anonymous category's as discussed in the level statement.

+ +**Example:** + +This example will associate `unconfined.user` with a named [`level`](cil_mls_labeling_statements.md#level) of `systemlow`: + + (sensitivity s0) + (level systemlow (s0)) + + (block unconfined + (user user) + (userlevel user systemlow) + ; An anonymous example: + ;(userlevel user (s0)) + ) + +userrange +--------- + +Associates a previously declared [`user`](cil_user_statements.md#user) identifer with a previously declared [`levelrange`](cil_mls_labeling_statements.md#levelrange) identifier. The [`levelrange`](cil_mls_labeling_statements.md#levelrange) may be named or anonymous. + +**Statement definition:** + + (userrange user_id levelrange_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

userrange

The userrange keyword.

user_id

A previously declared SELinux user identifier.

levelrange_id

A previously declared levelrange identifier. This may be formed by named or anonymous components as discussed in the levelrange statement and shown in the examples.

+ +**Example:** + +This example will associate `unconfined.user` with a named [`levelrange`](cil_mls_labeling_statements.md#levelrange) of `low_high`, other anonymous examples are also shown: + + (category c0) + (category c1) + (categoryorder (c0 c1)) + (sensitivity s0) + (sensitivity s1) + (dominance (s0 s1)) + (sensitivitycategory s0 (c0 c1)) + (level systemLow (s0)) + (level systemHigh (s0 (c0 c1))) + (levelrange low_high (systemLow systemHigh)) + + (block unconfined + (user user) + (role role) + (userrole user role) + ; Named example: + (userrange user low_high) + ; Anonymous examples: + ;(userrange user (systemLow systemHigh)) + ;(userrange user (systemLow (s0 (c0 c1)))) + ;(userrange user ((s0) (s0 (c0 c1)))) + ) + +userbounds +---------- + +Defines a hierarchical relationship between users where the child user cannot have more priviledges than the parent. + +Notes: + +- It is not possible to bind the parent to more than one child. + +- While this is added to the binary policy, it is not enforced by the SELinux kernel services. + +**Statement definition:** + + (userbounds parent_user_id child_user_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

userbounds

The userbounds keyword.

parent_user_id

A previously declared SELinux user identifier.

child_user_id

A previously declared SELinux user identifier.

+ +**Example:** + +The user `test` cannot have greater priviledges than `unconfined.user`: + + (user test) + + (unconfined + (user user) + (userbounds user .test) + ) + +userprefix +---------- + +Declare a user prefix that will be replaced by the file labeling utilities described at [http://selinuxproject.org/page/PolicyStoreConfigurationFiles](http://selinuxproject.org/page/PolicyStoreConfigurationFiles#file_contexts.template_File) that details the `file_contexts` entries. + +**Statement definition:** + + (userprefix user_id prefix) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

userprefix

The userprefix keyword.

user_id

A previously declared SELinux user identifier.

prefix

The string to be used by the file labeling utilities.

+ +**Example:** + +This example will associate `unconfined.admin` user with a prefix of "[`user`](cil_user_statements.md#user)": + + (block unconfined + (user admin + (userprefix admin user) + ) + +selinuxuser +----------- + +Associates a GNU/Linux user to a previously declared [`user`](cil_user_statements.md#user) identifier with a previously declared MLS [`userrange`](cil_user_statements.md#userrange). Note that the [`userrange`](cil_user_statements.md#userrange) is required even if the policy is non-MCS/MLS. + +**Statement definition:** + + (selinuxuser user_name user_id userrange_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + + + + + +

selinuxuser

The selinuxuser keyword.

user_name

A string representing the GNU/Linux user name

user_id

A previously declared SELinux user identifier.

userrange_id

A previously declared userrange identifier that has been associated to the user identifier. This may be formed by named or anonymous components as discussed in the userrange statement and shown in the examples.

+ +**Example:** + +This example will associate `unconfined.admin` user with a GNU / Linux user "`admin_1`": + + (block unconfined + (user admin) + (selinuxuser admin_1 admin low_low) + ) + +selinuxuserdefault +------------------ + +Declares the default SELinux user. Only one [`selinuxuserdefault`](cil_user_statements.md#selinuxuserdefault) statement is allowed in the policy. Note that the [`userrange`](cil_user_statements.md#userrange) identifier is required even if the policy is non-MCS/MLS. + +**Statement definition:** + + (selinuxuserdefault user_id userrange_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

selinuxuserdefault

The selinuxuserdefault keyword.

user_id

A previously declared SELinux user identifier.

userrange_id

A previously declared userrange identifier that has been associated to the user identifier. This may be formed by named or anonymous components as discussed in the userrange statement and shown in the examples.

+ +**Example:** + +This example will define the `unconfined.user` as the default SELinux user: + + (block unconfined + (user user) + (selinuxuserdefault user low_low) + ) diff --git a/secilc/docs/cil_user_statements.xml b/secilc/docs/cil_user_statements.xml deleted file mode 100644 index 38a7d6e..0000000 --- a/secilc/docs/cil_user_statements.xml +++ /dev/null @@ -1,528 +0,0 @@ - - - - - User Statements - - user - Declares an SELinux user identifier in the current namespace. - Statement definition: - - Where: - - - - - - - - user - - - The user keyword. - - - - - user_id - - - The SELinux user identifier. - - - - - - Example: - This will declare an SELinux user as unconfined.user: - - - - - - userrole - Associates a previously declared user identifier with a previously declared role identifier. - Statement definition: - - Where: - - - - - - - - userrole - - - The userrole keyword. - - - - - user_id - - - A previously declared SELinux user or userattribute identifier. - - - - - role_id - - - A previously declared role or roleattribute identifier. - - - - - - Example: - This example will associate unconfined.user to unconfined.role: - - - - - - userattribute - Declares a user attribute identifier in the current namespace. The identifier may have zero or more user and userattribute identifiers associated to it via the userattributeset statement. - Statement definition: - - Where: - - - - - - - - userattribute - - - The userattribute keyword. - - - - - userattribute_id - - - The userattribute identifier. - - - - - - Example: - This example will declare a user attribute users.user_holder that will have an empty set: - - - - - - userattributeset - Allows the association of one or more previously declared user or userattribute identifiers to a userattribute identifier. Expressions may be used to refine the associations as shown in the examples. - Statement definition: - - Where: - - - - - - - - userattributeset - - - The userattributeset keyword. - - - - - userattribute_id - - - A single previously declared userattribute identifier. - - - - - user_id - - - Zero or more previously declared user or userattribute identifiers. - Note that there must be at least one user_id or expr parameter declared. - - - - - expr - - - Zero or more expr's, the valid operators and syntax are: - (and (user_id ...) (user_id ...)) - (or (user_id ...) (user_id ...)) - (xor (user_id ...) (user_id ...)) - (not (user_id ...)) - (all) - - - - - - Example: - This example will declare three users and two user attributes, then associate all the users to them as shown: - - - - - - userlevel - Associates a previously declared user identifier with a previously declared level identifier. The level may be named or anonymous. - Statement definition: - - Where: - - - - - - - - userlevel - - - The userlevel keyword. - - - - - user_id - - - A previously declared SELinux user identifier. - - - - - level_id - - - A previously declared level identifier. This may consist of a single sensitivity with zero or more mixed named and anonymous category's as discussed in the level statement. - - - - - - Example: - This example will associate unconfined.user with a named level of systemlow: - - - - - - userrange - Associates a previously declared user identifer with a previously declared levelrange identifier. The levelrange may be named or anonymous. - Statement definition: - - Where: - - - - - - - - userrange - - - The userrange keyword. - - - - - user_id - - - A previously declared SELinux user identifier. - - - - - levelrange_id - - - A previously declared levelrange identifier. This may be formed by named or anonymous components as discussed in the levelrange statement and shown in the examples. - - - - - - Example: - This example will associate unconfined.user with a named levelrange of low_high, other anonymous examples are also shown: - - - - - - userbounds - Defines a hierarchical relationship between users where the child user cannot have more priviledges than the parent. - Notes: - - It is not possible to bind the parent to more than one child. - While this is added to the binary policy, it is not enforced by the SELinux kernel services. - - Statement definition: - - Where: - - - - - - - - userbounds - - - The userbounds keyword. - - - - - parent_user_id - - - A previously declared SELinux user identifier. - - - - - child_user_id - - - A previously declared SELinux user identifier. - - - - - - Example: - The user test cannot have greater priviledges than unconfined.user: - - - - - - userprefix - Declare a user prefix that will be replaced by the file labeling utilities described at http://selinuxproject.org/page/PolicyStoreConfigurationFiles that details the file_contexts entries. - Statement definition: - - Where: - - - - - - - - userprefix - - - The userprefix keyword. - - - - - user_id - - - A previously declared SELinux user identifier. - - - - - prefix - - - The string to be used by the file labeling utilities. - - - - - - Example: - This example will associate unconfined.admin user with a prefix of "user": - - - - - - selinuxuser - Associates a GNU/Linux user to a previously declared user identifier with a previously declared MLS userrange. Note that the userrange is required even if the policy is non-MCS/MLS. - Statement definition: - - Where: - - - - - - - - selinuxuser - - - The selinuxuser keyword. - - - - - user_name - - - A string representing the GNU/Linux user name - - - - - user_id - - - A previously declared SELinux user identifier. - - - - - userrange_id - - - A previously declared userrange identifier that has been associated to the user identifier. This may be formed by named or anonymous components as discussed in the userrange statement and shown in the examples. - - - - - - Example: - This example will associate unconfined.admin user with a GNU / Linux user "admin_1": - - - - - - selinuxuserdefault - Declares the default SELinux user. Only one selinuxuserdefault statement is allowed in the policy. Note that the userrange identifier is required even if the policy is non-MCS/MLS. - Statement definition: - - Where: - - - - - - - - selinuxuserdefault - - - The selinuxuserdefault keyword. - - - - - user_id - - - A previously declared SELinux user identifier. - - - - - userrange_id - - - A previously declared userrange identifier that has been associated to the user identifier. This may be formed by named or anonymous components as discussed in the userrange statement and shown in the examples. - - - - - - Example: - This example will define the unconfined.user as the default SELinux user: - - - - - diff --git a/secilc/docs/cil_xen_statements.md b/secilc/docs/cil_xen_statements.md new file mode 100644 index 0000000..5ae03e6 --- /dev/null +++ b/secilc/docs/cil_xen_statements.md @@ -0,0 +1,200 @@ +Xen Statements +============== + +Policy version 30 introduced the [`devicetreecon`](cil_xen_statements.md#devicetreecon) statement and also expanded the existing I/O memory range to 64 bits in order to support hardware with more than 44 bits of physical address space (32-bit count of 4K pages). + +See the ["XSM/FLASK Configuration"](http://xenbits.xen.org/docs/4.2-testing/misc/xsm-flask.txt) document for further information ([](http://xenbits.xen.org/docs/4.2-testing/misc/xsm-flask.txt)) + +iomemcon +-------- + +Label i/o memory. This may be a single memory location or a range. + +**Statement definition:** + + (iomemcon mem_addr|(mem_low mem_high) context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

iomemcon

The iomemcon keyword.

mem_addr |

+

(mem_low mem_high)

A single memory address to apply the context, or a range of addresses.

+

The entries must consist of numerics [0-9].

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Example:** + +An anonymous context for a memory address range of `0xfebe0-0xfebff`: + + (iomemcon (1043424 1043455) (unconfined.user object_r unconfined.object low_low)) + +ioportcon +--------- + +Label i/o ports. This may be a single port or a range. + +**Statement definition:** + + (ioportcon port|(port_low port_high) context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

ioportcon

The ioportcon keyword.

port |

+

(port_low port_high)

A single port to apply the context, or a range of ports.

+

The entries must consist of numerics [0-9].

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Example:** + +An anonymous context for a single port of :`0xecc0`: + + (ioportcon 60608 (unconfined.user object_r unconfined.object low_low)) + +pcidevicecon +------------ + +Label a PCI device. + +**Statement definition:** + + (pcidevicecon device context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

pcidevicecon

The pcidevicecon keyword.

device

The device number.The entries must consist of numerics [0-9].

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Example:** + +An anonymous context for a pci device address of `0xc800`: + + (pcidevicecon 51200 (unconfined.user object_r unconfined.object low_low)) + +pirqcon +------- + +Label an interrupt level. + +**Statement definition:** + + (pirqcon irq_level context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

pirqcon

The pirqcon keyword.

irq_level

The interrupt request number. The entries must consist of numerics [0-9].

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Example:** + +An anonymous context for IRQ 33: + + (pirqcon 33 (unconfined.user object_r unconfined.object low_low)) + +devicetreecon +------------- + +Label device tree nodes. + +**Statement definition:** + + (devicetreecon path context_id) + +**Where:** + + ++++ + + + + + + + + + + + + + + +

devicetreecon

The devicetreecon keyword.

path

The device tree path. If this contains spaces enclose within "".

context_id

A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not.

+ +**Example:** + +An anonymous context for the specified path: + + (devicetreecon "/this is/a/path" (unconfined.user object_r unconfined.object low_low)) diff --git a/secilc/docs/cil_xen_statements.xml b/secilc/docs/cil_xen_statements.xml deleted file mode 100644 index c72ef6c..0000000 --- a/secilc/docs/cil_xen_statements.xml +++ /dev/null @@ -1,227 +0,0 @@ - - - - - Xen Statements - Policy version 30 introduced the devicetreecon statement and also expanded the existing I/O memory range to 64 bits in order to support hardware with more than 44 bits of physical address space (32-bit count of 4K pages). - See the "XSM/FLASK Configuration" document for further information () - - iomemcon - Label i/o memory. This may be a single memory location or a range. - Statement definition: - - Where: - - - - - - - - iomemcon - - - The iomemcon keyword. - - - - - mem_addr | - (mem_low mem_high) - - - A single memory address to apply the context, or a range of addresses. - The entries must consist of numerics [0-9]. - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Example: - An anonymous context for a memory address range of 0xfebe0-0xfebff: - - - - - ioportcon - Label i/o ports. This may be a single port or a range. - Statement definition: - - Where: - - - - - - - - ioportcon - - - The ioportcon keyword. - - - - - port | - (port_low port_high) - - - A single port to apply the context, or a range of ports. - The entries must consist of numerics [0-9]. - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Example: - An anonymous context for a single port of :0xecc0: - - - - - pcidevicecon - Label a PCI device. - Statement definition: - - Where: - - - - - - - - pcidevicecon - - - The pcidevicecon keyword. - - - - - device - - - The device number.The entries must consist of numerics [0-9]. - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Example: - An anonymous context for a pci device address of 0xc800: - - - - - pirqcon - Label an interrupt level. - Statement definition: - - Where: - - - - - - - - pirqcon - - - The pirqcon keyword. - - - - - irq_level - - - The interrupt request number. The entries must consist of numerics [0-9]. - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Example: - An anonymous context for IRQ 33: - - - - - devicetreecon - Label device tree nodes. - Statement definition: - - Where: - - - - - - - - devicetreecon - - - The devicetreecon keyword. - - - - - path - - - The device tree path. If this contains spaces enclose within "". - - - - - context_id - - - A previously declared context identifier or an anonymous security context (user role type levelrange), the range MUST be defined whether the policy is MLS/MCS enabled or not. - - - - - - Example: - An anonymous context for the specified path: - - - -