Difference between revisions of "PolicyLanguage"

From SELinux Wiki
Jump to: navigation, search
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
In progress to build pages from the SELinux Notebook - Need to do the actual rules & statements
 
 
= SELinux Policy Language =
 
= SELinux Policy Language =
 
== Introduction ==
 
== Introduction ==
This section is intended as a reference to give a basic understanding of the policy language statements and rules with supporting examples taken from the Reference Policy source. The language updates to Policy DB version 23 have been captured.
+
This section is intended as a reference to give a basic understanding of the policy language statements and rules with supporting examples taken from the Reference Policy sources. Also all of the language updates to Policy DB version 28 should have been captured. For a more detailed explanation of the policy language the "SELinux by Example" book is recommended.
 +
 
 +
There is currently a project underway called the Common Intermediate Language (CIL) project that will define a new policy definition language that could eventually replace the current policy language described in this section. Reference to CIL can be found at: [http://userspace.selinuxproject.org/trac/wiki/CilDesign http://userspace.selinuxproject.org/trac/wiki/CilDesign], however it is not yet complete although a simple compiler is available by:
 +
<pre>
 +
git clone http://oss.tresys.com/git/cil.git
 +
</pre>
 +
 
 +
=== CIL Overview ===
 +
While the CIL design web pages give the main objectives of CIL, from a language perspective it will:
 +
 
 +
* Apply consistancy to the current language statements. For example the <tt>type_transition</tt> statement has been extended to allow an additional parameter to support object names. With CIL this becomes two separate statements <tt>typetransition</tt> and <tt>nametypetransition</tt>.
 +
 
 +
Examples:
 +
 
 +
{| border="1"
 +
| <center>'''CIL'''</center>
 +
| <center>'''Current'''</center>
 +
 
 +
|-
 +
|  allow
 +
|  allow
 +
 
 +
|-
 +
|  roleallow
 +
| <tt>allow</tt> (role)
 +
 
 +
|-
 +
|  dominance
 +
|  dominance
 +
 
 +
|-
 +
|  roledominance
 +
| <tt>dominance</tt> (role)
 +
 
 +
|-
 +
|  roletransition
 +
|  role_transition
 +
 
 +
|}
 +
 
 +
 
 +
* Additional CIL statements have been defined to allow clarity, for example:
 +
:: typeattributeset
 +
:: classpermissionset
 +
:: classmap
 +
:: classmapping
 +
 
 +
 
 +
* Allow named an anonymous context definitions to be defined. This example shows the both context declarations and the supporting statements required to build them:
 +
 
 +
<pre>
 +
<nowiki>; These are declared in the Global Namespace</nowiki>
 +
<nowiki>;</nowiki>
 +
 
 +
<nowiki>; Declare range info:</nowiki>
 +
(category c0)
 +
(categoryorder (c0))
 +
(sensitivity s0)
 +
(dominance (s0))
 +
(sensitivitycategory s0 (c0))
 +
(levelrange default ((s0 (c0)) (s0 (c0))))
 +
(level low (s0 (c0)))
 +
 
 +
<nowiki>; Declare type info:</nowiki>
 +
(type unconfined_t)
 +
 
 +
<nowiki>; Declare role info</nowiki>
 +
(role unconfined_r)
 +
(roletype unconfined_r unconfined_t)
 +
(role object_r)
 +
(roletype object_r unconfined_t)
 +
 
 +
<nowiki>; Declare user info:</nowiki>
 +
(user unconfined_u)
 +
(userrole unconfined_u unconfined_r)
 +
(userrange unconfined_u (low low))
 +
(userlevel unconfined_u low)
 +
 
 +
(user system_u)
 +
(userrole system_u unconfined_r)
 +
(userrole system_u object_r)
 +
(userrange system_u (low low))
 +
(userlevel system_u low)
 +
 
 +
 
 +
<nowiki>; Declare sids:</nowiki>
 +
(sid kernel)
 +
(sid security)
 +
(sid unlabeled)
 +
 
 +
<nowiki>; Declare context ids (named) and info:</nowiki>
 +
(context default_context (unconfined_u unconfined_r unconfined_t default))
 +
(context system_context (system_u unconfined_r unconfined_t default))
 +
(context object_context (system_u object_r unconfined_t default))
 +
 
 +
<nowiki>; Use context ids in various statements:</nowiki>
 +
(sidcontext kernel system_context)
 +
(sidcontext security object_context)
 +
(sidcontext unlabeled object_context)
 +
 
 +
(fsuse xattr ext2 object_context)
 +
(fsuse task eventpollfs object_context)
 +
(fsuse trans mqueue object_context)
 +
(genfscon selinuxfs / object_context)
 +
 
 +
(filecon "/" "" any object_context)
 +
 
 +
<nowiki>; Declare this as an anonymous context:</nowiki>
 +
(filecon "/" ".*" any (unconfined_u unconfined_r unconfined_t (s0 (c0)) (s0 (c0))))
 +
</pre>
 +
 
 +
 
 +
* Support namespace features allowing policy modules to be defined within blocks with inheritance and template features. An example with blocks and inheritance:
 +
 
 +
<pre>
 +
<nowiki>; blockinherit.cil</nowiki>
 +
<nowiki>;</nowiki>
 +
<nowiki>; Need to include the cil-base.cil module when building this example to declare</nowiki>
 +
<nowiki>; the user, role, type and range.</nowiki>
 +
<nowiki>;</nowiki>
 +
<nowiki>; This example defines three nested blocks each declaring a different class</nowiki>
 +
<nowiki>; with two permissions and an allow rule. Three new namespaces are then created</nowiki>
 +
<nowiki>; and the respective levels (1, 2, 3) are then inherited by each new namespace.</nowiki>
 +
<nowiki>;</nowiki>
 +
<nowiki>; Using APOL, sedispol or sesearch 9 allow rules will be found:</nowiki>
 +
 
 +
<nowiki>; Three allow rules from the three nested blocks:</nowiki>
 +
<nowiki>; allow level1.level1_t level1.level1_t : level1.file { open execute } ;</nowiki>
 +
<nowiki>; allow level1.level2.level2_t level1.level2.level2_t : level1.level2.socket { recv_msg send_msg } ;</nowiki>
 +
<nowiki>; allow level1.level2.level3.level3_t level1.level2.level3.level3_t : level1.level2.level3.ipc { create destroy } ;</nowiki>
 +
 
 +
<nowiki>; Three allow rules from the new_namespace1 that inherited the three nested blocks:</nowiki>
 +
<nowiki>; allow new_namespace1.level1_t new_namespace1.level1_t : new_namespace1.file { open execute } ;</nowiki>
 +
<nowiki>; allow new_namespace1.level2.level2_t new_namespace1.level2.level2_t : new_namespace1.level2.socket { recv_msg send_msg } ;</nowiki>
 +
<nowiki>; allow new_namespace1.level2.level3.level3_t new_namespace1.level2.level3.level3_t : new_namespace1.level2.level3.ipc { create destroy } ;</nowiki>
 +
 
 +
<nowiki>; Two allow rules from the new_namespace2 that inherited the two lower nested blocks:</nowiki>
 +
<nowiki>; allow new_namespace2.level2_t new_namespace2.level2_t : new_namespace2.socket { recv_msg send_msg } ;</nowiki>
 +
<nowiki>; allow new_namespace2.level3.level3_t new_namespace2.level3.level3_t : new_namespace2.level3.ipc { create destroy } ;</nowiki>
 +
 
 +
<nowiki>; One allow rule from the new_namespace3 that inherited the last nested block:</nowiki>
 +
<nowiki>; allow new_namespace3.level3_t new_namespace3.level3_t : new_namespace3.ipc { create destroy } ;</nowiki>
 +
 
 +
(block level1
 +
    (type level1_t)
 +
    (class file (open execute))
 +
    (allow level1_t self (file (open execute)))
 +
 
 +
    (block level2
 +
        (type level2_t)
 +
        (class socket (recv_msg send_msg))
 +
        (allow level2_t self (socket (recv_msg send_msg)))
 +
 
 +
        (block level3
 +
            (type level3_t)
 +
            (class ipc (create destroy))
 +
            (allow level3_t self (ipc (create destroy)))
 +
 
 +
        ) ; End level3 block
 +
    ) ; End level2 block
 +
) ; End level1 block
 +
 
 +
(block new_namespace1
 +
    (blockinherit level1)
 +
) ; End new_namespace1 namespace
 +
 
 +
(block new_namespace2
 +
    (blockinherit level1.level2)
 +
) ; End new_namespace2 namespace
 +
 
 +
(block new_namespace3
 +
    (blockinherit level1.level2.level3)
 +
) ; End new_namespace3 namespace
 +
</pre>
 +
 
 +
 
 +
* Remove the order dependancy in that policy statements can be anywhere within the source (i.e. remove dependancy of class, sid etc. being within a base module).
 +
 
 +
 
 +
* Able to define macros and calls that will remove any dependancy on M4 macro support. This is a block that calls two different macros:
 +
 
 +
<pre>
 +
<nowiki>; SEAndroid dbus daemon - dbusd.cil</nowiki>
 +
(block dbusd
 +
    (type dbusd)
 +
    (typeattributeset domain dbusd)
 +
 
 +
    (type dbusd_exec)
 +
    (typeattributeset exec_type dbusd_exec)
 +
    (typeattributeset file_type dbusd_exec)
 +
 
 +
    (call init_daemon_domain (dbusd dbusd_exec))
 +
    <nowiki>; Reads /proc/pid/cmdline of clients</nowiki>
 +
    (call r_dir_file (dbusd system.system))
 +
    (call r_dir_file (dbusd bluetoothd.bluetoothd))
 +
)
 +
</pre>
 +
 
 +
These are the macros that are called:
 +
<pre>
 +
<nowiki>;</nowiki>
 +
<nowiki>; SEAndroid macros - te_macros.cil</nowiki>
 +
<nowiki>;</nowiki>
 +
<nowiki>; Macros are instantiated within the namespace that has the 'call'</nowiki>
 +
<nowiki>; statement.</nowiki>
 +
<nowiki>; These macros defined in the global namespace:</nowiki>
 +
 
 +
<nowiki>;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;</nowiki>
 +
<nowiki>; r_dir_file(domain, type)</nowiki>
 +
<nowiki>; Allow the specified domain to read directories, files</nowiki>
 +
<nowiki>; and symbolic links of the specified type.</nowiki>
 +
(macro r_dir_file ((type type_id1) (type type_id2))
 +
    (allow type_id1 type_id2 (kernel.dir r_dir_perms))
 +
    (allow type_id1 type_id2 (kernel.file r_file_perms))
 +
    (allow type_id1 type_id2 (kernel.lnk_file r_file_perms))
 +
)
 +
 
 +
<nowiki>;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;</nowiki>
 +
<nowiki>; init_daemon_domain(domain)</nowiki>
 +
<nowiki>; Set up a transition from init to the daemon domain</nowiki>
 +
<nowiki>; upon executing its binary.</nowiki>
 +
(macro init_daemon_domain ((type type_id1) (type type_id2))
 +
    (call domain_auto_trans (init.init type_id2 type_id1))
 +
    (call tmpfs_domain (type_id1))
 +
)
 +
</pre>
 +
 
 +
 
 +
* Directly generate the binary policy file and other configuration files - currently the<tt> file_contexts</tt> file.
 +
 
 +
 
 +
* Support transformation services such as delete, transform and inherit with except.
 +
 
  
 
== Policy Statements and Rules ==
 
== Policy Statements and Rules ==
Line 45: Line 276:
 
|Booleans
 
|Booleans
 
|<center>o</center>
 
|<center>o</center>
 +
|-
 +
| Default user, role, type, range rules
 +
| <center>o</center>
 
|-
 
|-
 
|Type / Type Alias
 
|Type / Type Alias
Line 170: Line 404:
  
 
{|border="1"
 
{|border="1"
|alias
+
| alias
|allow
+
| allow
|and
+
| and  
 +
 
 
|-
 
|-
|attribute
+
| attribute
|auditallow
+
| attribute_role
|auditdeny
+
| auditallow
 +
 
 
|-
 
|-
|bool
+
| auditdeny
|category
+
| bool
|cfalse
+
| category
 +
 
 
|-
 
|-
|class
+
| cfalse
|clone
+
| class
|common
+
| clone
 +
 
 
|-
 
|-
|constrain
+
| common
|ctrue
+
| constrain
|dom
+
| ctrue  
 +
 
 
|-
 
|-
|domby
+
| dom
|dominance
+
| domby
|dontaudit
+
| dominance
 +
 
 
|-
 
|-
|else
+
| dontaudit
|eq
+
| else
|false
+
| equals
 +
 
 
|-
 
|-
|fs_use_task
+
| false
|fs_use_trans
+
| filename
|fs_use_xattr
+
| filesystem
 +
 
 
|-
 
|-
|fscon
+
| fscon
|genfscon
+
| fs_use_task
|h1
+
| fs_use_trans
 +
 
 
|-
 
|-
|h2
+
| fs_use_xattr
|if
+
| genfscon
|incomp
+
| h1
 +
 
 
|-
 
|-
|inherits
+
| h2
|ipv4_addr
+
| identifier
|ipv6_addr
+
| if
 +
 
 
|-
 
|-
|l1
+
| incomp
|l2
+
| inherits
|level
+
| iomemcon
 +
 
 
|-
 
|-
|mlsconstrain
+
| ioportcon
|mlsvalidatetrans
+
| ipv4_addr
|module
+
| ipv6_addr
 +
 
 
|-
 
|-
|netifcon
+
| l1
|neverallow
+
| l2
|nodecon
+
| level
 +
 
 
|-
 
|-
|not
+
| mlsconstrain
|object_r
+
| mlsvalidatetrans
|optional
+
| module
 +
 
 
|-
 
|-
|or
+
| netifcon
|permissive
+
| neverallow
|policycap
+
| nodecon
 +
 
 +
|-
 +
| not
 +
| notequal
 +
| number
 +
 
 +
|-
 +
| object_r
 +
| optional
 +
| or
 +
 
 +
|-
 +
| path
 +
| pcidevicecon
 +
| permissive
 +
 
 +
|-
 +
| pirqcon
 +
| policycap
 +
| portcon
 +
 
 
|-
 
|-
|portcon
+
| r1
|r1
+
 
| r2
 
| r2
 +
| r3
 +
 
|-
 
|-
|r3
+
| range
|range
+
| range_transition
|range_transition
+
| require
 +
 
 
|-
 
|-
|require
+
| role
|role
+
| roleattribute
|role_transition
+
| roles
 +
 
 
|-
 
|-
|roles
+
| role_transition
|sameuser
+
| sameuser
|self
+
| sensitivity
 +
 
 
|-
 
|-
|sensitivity
+
| sid
|sid
+
| source
|source
+
| t1
 +
 
 
|-
 
|-
|t1
+
| t2
|t2
+
| t3
|t3
+
| target
 +
 
 
|-
 
|-
|target
+
| true
|true
+
| type
|type
+
| typealias
 +
 
 
|-
 
|-
|type_change
+
| typeattribute
|type_member
+
| typebounds
|type_transition
+
| type_change
 +
 
 
|-
 
|-
|typealias
+
| type_member
|typeattribute
+
| types
|types
+
| type_transition
 +
 
 
|-
 
|-
|u1
+
| u1
|u2
+
| u2
|u3
+
| u3  
 +
 
 
|-
 
|-
|user
+
| user
|validatetrans
+
| validatetrans
|version
+
| version_identifier
 +
 
 +
|-
 +
| xor
 +
| default_user
 +
| default_role
 +
 
 +
|-
 +
| default_type
 +
| default_range
 +
| low
 +
 
 
|-
 
|-
|version_identifier
+
| high
|xor
+
| low_high
 
|  
 
|  
 
|}
 
|}
Line 297: Line 588:
  
 
|-
 
|-
|allow
+
| allow
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''No'''</center>
+
| <center>'''No'''</center>
 +
 
 
|-
 
|-
|allow - Role
+
| allow - Role
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''No'''</center>
+
| <center>'''No'''</center>
|<center>'''Yes'''</center>
+
| <center>'''Yes'''</center>
|<center>'''No'''</center>
+
| <center>'''No'''</center>
 +
 
 
|-
 
|-
 
| attribute
 
| attribute
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
 +
|-
 +
| attribute_role
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
Line 331: Line 633:
  
 
|-
 
|-
| auditdeny (Depreciated)
+
| auditdeny (Deprecated)
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
Line 377: Line 679:
 
|-
 
|-
 
| constrain
 
| constrain
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
 +
|-
 +
| default_user
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
 +
|-
 +
| default_role
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
 +
|-
 +
| default_type
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''No'''</center>
 +
 +
|-
 +
| default_range
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
Line 394: Line 732:
  
 
|-
 
|-
| dominance - Role (Depreciated)
+
| dominance - Role (Deprecated)
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
Line 505: Line 843:
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
| <center>'''Yes'''</center>
+
| <center>'''Yes (1)'''</center>
 
| <center>'''No'''</center>
 
| <center>'''No'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
Line 567: Line 905:
 
| require
 
| require
 
| <center>'''No'''</center>
 
| <center>'''No'''</center>
| <center>'''Yes *'''</center>
+
| <center>'''Yes (2)'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
| <center>'''Yes *'''</center>
+
| <center>'''Yes (2)'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''No'''</center>
 
| <center>'''No'''</center>
Line 581: Line 919:
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 +
 +
|-
 +
| roleattribute
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
  
 
|-
 
|-
Line 641: Line 988:
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
| <center>'''Yes'''</center>
+
| <center>'''Yes (3)'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''No'''</center>
 
| <center>'''No'''</center>
Line 656: Line 1,003:
 
|-
 
|-
 
| typeattribute
 
| typeattribute
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
 +
| <center>'''Yes'''</center>
 +
| <center>'''No'''</center>
 +
 +
|-
 +
| typebounds
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
 
| <center>'''Yes'''</center>
Line 685: Line 1,041:
 
<center>'''Table 3: The policy language statements and rules that are allowed within each type of policy source file - '''''The left hand side of the table shows what Policy Language Statements and Rules are allowed within each type of policy source file. The right hand side of the table shows whether the statement is valid within the if / else construct, optional {rule_list}, or require {rule_list} statement.''</center>
 
<center>'''Table 3: The policy language statements and rules that are allowed within each type of policy source file - '''''The left hand side of the table shows what Policy Language Statements and Rules are allowed within each type of policy source file. The right hand side of the table shows whether the statement is valid within the if / else construct, optional {rule_list}, or require {rule_list} statement.''</center>
  
<nowiki>* Only if preceded by the </nowiki>optional statement.
+
(1)  <tt>neverallow</tt> statements are allowed in modules, however to detect these the <tt>semanage.conf</tt> file must have the <tt>expand-check=1</tt> entry present.
 +
(2) Only if preceded by the optional statement.
 +
(3) Excluding the 'file name transition' rule.  
  
 
== Policy Language Definition Links ==
 
== Policy Language Definition Links ==
 
The policy language statement and rule sections are as follows:
 
The policy language statement and rule sections are as follows:
 
* [[TypeStatements | Type Enforcement and Attribute Statements]]
 
* [[TypeStatements | Type Enforcement and Attribute Statements]]
 +
* [[DefaultRules | Default Rules]]
 
* [[TypeRules | Type Enforcement Rules]]
 
* [[TypeRules | Type Enforcement Rules]]
 
* [[AVCRules | Access Vector Rules]]
 
* [[AVCRules | Access Vector Rules]]
Line 703: Line 1,062:
 
* [[ObjectClassStatements |Object Class and Permission Statements]]
 
* [[ObjectClassStatements |Object Class and Permission Statements]]
 
* [[SIDStatements | Security ID (SID) Statement]]
 
* [[SIDStatements | Security ID (SID) Statement]]
 +
* [[XENStatements | XEN Statements]]

Revision as of 15:19, 5 September 2012

SELinux Policy Language

Introduction

This section is intended as a reference to give a basic understanding of the policy language statements and rules with supporting examples taken from the Reference Policy sources. Also all of the language updates to Policy DB version 28 should have been captured. For a more detailed explanation of the policy language the "SELinux by Example" book is recommended.

There is currently a project underway called the Common Intermediate Language (CIL) project that will define a new policy definition language that could eventually replace the current policy language described in this section. Reference to CIL can be found at: http://userspace.selinuxproject.org/trac/wiki/CilDesign, however it is not yet complete although a simple compiler is available by:

git clone http://oss.tresys.com/git/cil.git

CIL Overview

While the CIL design web pages give the main objectives of CIL, from a language perspective it will:

  • Apply consistancy to the current language statements. For example the type_transition statement has been extended to allow an additional parameter to support object names. With CIL this becomes two separate statements typetransition and nametypetransition.

Examples:

CIL
Current
allow allow
roleallow allow (role)
dominance dominance
roledominance dominance (role)
roletransition role_transition


  • Additional CIL statements have been defined to allow clarity, for example:
typeattributeset
classpermissionset
classmap
classmapping


  • Allow named an anonymous context definitions to be defined. This example shows the both context declarations and the supporting statements required to build them:
; These are declared in the Global Namespace
;

; Declare range info:
(category c0)
(categoryorder (c0))
(sensitivity s0)
(dominance (s0))
(sensitivitycategory s0 (c0))
(levelrange default ((s0 (c0)) (s0 (c0))))
(level low (s0 (c0)))

; Declare type info:
(type unconfined_t)

; Declare role info
(role unconfined_r)
(roletype unconfined_r unconfined_t)
(role object_r)
(roletype object_r unconfined_t)

; Declare user info:
(user unconfined_u)
(userrole unconfined_u unconfined_r)
(userrange unconfined_u (low low))
(userlevel unconfined_u low)

(user system_u)
(userrole system_u unconfined_r)
(userrole system_u object_r)
(userrange system_u (low low))
(userlevel system_u low)


; Declare sids:
(sid kernel)
(sid security)
(sid unlabeled)

; Declare context ids (named) and info:
(context default_context (unconfined_u unconfined_r unconfined_t default))
(context system_context (system_u unconfined_r unconfined_t default))
(context object_context (system_u object_r unconfined_t default))

; Use context ids in various statements:
(sidcontext kernel system_context)
(sidcontext security object_context)
(sidcontext unlabeled object_context)

(fsuse xattr ext2 object_context)
(fsuse task eventpollfs object_context)
(fsuse trans mqueue object_context)
(genfscon selinuxfs / object_context)

(filecon "/" "" any object_context)

; Declare this as an anonymous context:
(filecon "/" ".*" any (unconfined_u unconfined_r unconfined_t (s0 (c0)) (s0 (c0))))


  • Support namespace features allowing policy modules to be defined within blocks with inheritance and template features. An example with blocks and inheritance:
; blockinherit.cil
;
; Need to include the cil-base.cil module when building this example to declare
; the user, role, type and range.
;
; This example defines three nested blocks each declaring a different class
; with two permissions and an allow rule. Three new namespaces are then created
; and the respective levels (1, 2, 3) are then inherited by each new namespace.
;
; Using APOL, sedispol or sesearch 9 allow rules will be found:

; Three allow rules from the three nested blocks:
; allow level1.level1_t level1.level1_t : level1.file { open execute } ;
; allow level1.level2.level2_t level1.level2.level2_t : level1.level2.socket { recv_msg send_msg } ;
; allow level1.level2.level3.level3_t level1.level2.level3.level3_t : level1.level2.level3.ipc { create destroy } ;

; Three allow rules from the new_namespace1 that inherited the three nested blocks:
; allow new_namespace1.level1_t new_namespace1.level1_t : new_namespace1.file { open execute } ;
; allow new_namespace1.level2.level2_t new_namespace1.level2.level2_t : new_namespace1.level2.socket { recv_msg send_msg } ;
; allow new_namespace1.level2.level3.level3_t new_namespace1.level2.level3.level3_t : new_namespace1.level2.level3.ipc { create destroy } ;

; Two allow rules from the new_namespace2 that inherited the two lower nested blocks:
; allow new_namespace2.level2_t new_namespace2.level2_t : new_namespace2.socket { recv_msg send_msg } ;
; allow new_namespace2.level3.level3_t new_namespace2.level3.level3_t : new_namespace2.level3.ipc { create destroy } ;

; One allow rule from the new_namespace3 that inherited the last nested block:
; allow new_namespace3.level3_t new_namespace3.level3_t : new_namespace3.ipc { create destroy } ;

(block level1
    (type level1_t)
    (class file (open execute))
    (allow level1_t self (file (open execute)))

    (block level2
        (type level2_t)
        (class socket (recv_msg send_msg))
        (allow level2_t self (socket (recv_msg send_msg)))

        (block level3
            (type level3_t)
            (class ipc (create destroy))
            (allow level3_t self (ipc (create destroy)))

        ) ; End level3 block
    ) ; End level2 block
) ; End level1 block

(block new_namespace1
    (blockinherit level1)
) ; End new_namespace1 namespace

(block new_namespace2
    (blockinherit level1.level2)
) ; End new_namespace2 namespace

(block new_namespace3
    (blockinherit level1.level2.level3)
) ; End new_namespace3 namespace


  • Remove the order dependancy in that policy statements can be anywhere within the source (i.e. remove dependancy of class, sid etc. being within a base module).


  • Able to define macros and calls that will remove any dependancy on M4 macro support. This is a block that calls two different macros:
; SEAndroid dbus daemon - dbusd.cil
(block dbusd
    (type dbusd)
    (typeattributeset domain dbusd)

    (type dbusd_exec)
    (typeattributeset exec_type dbusd_exec)
    (typeattributeset file_type dbusd_exec)

    (call init_daemon_domain (dbusd dbusd_exec))
    ; Reads /proc/pid/cmdline of clients
    (call r_dir_file (dbusd system.system))
    (call r_dir_file (dbusd bluetoothd.bluetoothd))
)

These are the macros that are called:

;
; SEAndroid macros - te_macros.cil
;
; Macros are instantiated within the namespace that has the 'call'
; statement.
; These macros defined in the global namespace:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; r_dir_file(domain, type)
; Allow the specified domain to read directories, files
; and symbolic links of the specified type.
(macro r_dir_file ((type type_id1) (type type_id2))
    (allow type_id1 type_id2 (kernel.dir r_dir_perms))
    (allow type_id1 type_id2 (kernel.file r_file_perms))
    (allow type_id1 type_id2 (kernel.lnk_file r_file_perms))
)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; init_daemon_domain(domain)
; Set up a transition from init to the daemon domain
; upon executing its binary.
(macro init_daemon_domain ((type type_id1) (type type_id2))
    (call domain_auto_trans (init.init type_id2 type_id1))
    (call tmpfs_domain (type_id1))
)


  • Directly generate the binary policy file and other configuration files - currently the file_contexts file.


  • Support transformation services such as delete, transform and inherit with except.


Policy Statements and Rules

Policy Source Files

There are three basic types of policy source file that can contain language statements and rules. The three types of policy source file are:

Monolithic Policy - This is a single policy source file that contains all statements. By convention this file is called policy.conf and is compiled using the checkpolicy command that produces the binary policy file.
Base Policy - This is the mandatory base policy source file that supports the loadable module infrastructure. The whole system policy could be fully contained within this file, however it is more usual for the base policy to hold the mandatory components of a policy, with the optional components contained in loadable module source files. By convention this file is called base.conf and is compiled using the checkpolicy or checkmodule command.
Module (or Non-base) Policy - These are optional policy source files that when compiled, can be dynamically loaded or unloaded within the policy store. By convention these files are named after the module or application they represent, with the compiled binary having a ‘.pp’ extension. These files are compiled using the checkmodule command.

Table 1 shows the order in which the statements should appear in source files with the minimum (and therefore mandatory) statements that must be defined.


Base Entries M/O
Security Classes (class)
m
Initial SIDs
m
Access Vectors (permissions)
m
MLS sensitivity, category and level Statements
o
MLS Constraints
o
Policy Capability Statements
o
Attributes
o
Booleans
o
Default user, role, type, range rules
o
Type / Type Alias
m
Roles
m
Policy Rules
o
Users
m
Constraints
o
Default SID labeling
m
fs_use_xattr Statements
o
fs_use_task and fs_use_trans Statements
o
genfscon Statements
o
portcon, netifcon and nodecon Statements
o
Module Entries
module Statement
o
require Statement
o
Attributes
o
Booleans
o
Type / Type Alias
o
Roles
o
Policy Rules
o
Users
o
Table 1: Base and Module Policy Statements - A Monolithic source file would contain the same statements as the Base Module. The Mandatory policy entries are noted (the type, role and user require at least one entry each).

The language grammar defines what statements and rules can be used within the different types of source file. To highlight these rules, the following table is included in each statement and rule section to show what circumstances each one is valid within a policy source file:


Monolithic Policy
Base Policy
Module Policy
Yes/No
Yes/No
Yes/No

Where:

Monolithic Policy - Whether the statement is allowed within a monolithic policy source file or not.
Base Policy - Whether the statement is allowed within a base (for loadable module support) policy source file or not.
Module Policy - Whether the statement is allowed within the optional loadable module policy source file or not.

Table 3 shows a cross reference matrix of statements and rules allowed in each type of policy source file.

Conditional, Optional and Require Statement Rules

The language grammar specifies what statements and rules can be included within Conditional Policy, Optional Policy statements and the require statement. To highlight these rules the following table is included in each statement and rule section to show what circumstances each one is valid within a policy source file:


Conditional Policy (if) Statement
optional Statement
require Statement
Yes/No
Yes/No
Yes/No

Where:

Conditional Policy (if) Statement - Whether the statement is allowed within a conditional statement (IF / ELSE construct) as described in the if Statement section. Conditional statements can be in all types of policy source file.
optional Statement - Whether the statement is allowed within the optional { rule_list } construct as described in the optional Statement section.
require Statement - Whether the statement keyword is allowed within the require { rule_list } construct as described in the require Statement section.

Table 3 shows a cross reference matrix of statements and rules allowed in each of the above policy statements.

MLS Statements and Optional MLS Components

The MLS Statements section defines statements specifically for MLS support. However when MLS is enabled, there are other statements that require the MLS Security Context component as an argument, therefore these statements show an example taken from the Reference Policy MLS build.

General Statement Information

  • Identifiers can generally be any length but should be restricted to the following characters: a-z, A-Z, 0-9 and _ (underscore).
  • A “#” indicates the start of a comment in policy source files.
  • Statements that were defined in the older NSA documentation have been updated to capture changes such as to prohibit the use of * and ~ in type and role sets (other than in the neverallow statement). Note that some of these changes are not captured by the language grammar, but are managed within the policy_parse.y source code).
  • When multiple source and target entries are shown in a single statement or rule, the compiler (checkpolicy or checkmodule) will expand these to individual statements or rules as shown in the following example:
# This allow rule has two target entries ''console_device_t'' and ''tty_device_t'':
allow apm_t { console_device_t tty_device_t }:chr_file { getattr read write append ioctl lock };

# The compiler will expand this to become:
allow apm_t console_device_t:chr_file { getattr read write append ioctl lock };
# and:
allow apm_t tty_device_t:chr_file { getattr read write append ioctl lock };
Therefore when comparing the actual source code with a compiled binary using (for example) apol, sedispol or sedismod, the results will differ (however the resulting policy rules will be the same).
  • Some statements can be added to a policy (via the policy store) using the semanage(8) command. Examples of these are shown where applicable, however the semanage man page should be consulted for all the possible command line options.
  • Table 2 lists words reserved for the SELinux policy language.
alias allow and
attribute attribute_role auditallow
auditdeny bool category
cfalse class clone
common constrain ctrue
dom domby dominance
dontaudit else equals
false filename filesystem
fscon fs_use_task fs_use_trans
fs_use_xattr genfscon h1
h2 identifier if
incomp inherits iomemcon
ioportcon ipv4_addr ipv6_addr
l1 l2 level
mlsconstrain mlsvalidatetrans module
netifcon neverallow nodecon
not notequal number
object_r optional or
path pcidevicecon permissive
pirqcon policycap portcon
r1 r2 r3
range range_transition require
role roleattribute roles
role_transition sameuser sensitivity
sid source t1
t2 t3 target
true type typealias
typeattribute typebounds type_change
type_member types type_transition
u1 u2 u3
user validatetrans version_identifier
xor default_user default_role
default_type default_range low
high low_high
Table 2: Policy language reserved words.
  • Table 3 shows what policy language statements and rules are allowed within each type of policy source file, and whether the statement is valid within an if / else construct, optional {rule_list}, or require {rule_list} statement.


Statement / Rule
Monolithic Policy
Base Policy
Module Policy
Conditional Statements
optional Statement
require Statement
allow
Yes
Yes
Yes
Yes
Yes
No
allow - Role
Yes
Yes
Yes
No
Yes
No
attribute
Yes
Yes
Yes
No
Yes
Yes
attribute_role
Yes
Yes
Yes
No
Yes
Yes
auditallow
Yes
Yes
Yes
Yes
Yes
No
auditdeny (Deprecated)
Yes
Yes
Yes
Yes
Yes
No
bool
Yes
Yes
Yes
No
Yes
Yes
category
Yes
Yes
No
No
No
Yes
class
Yes
Yes
No
No
No
Yes
common
Yes
Yes
No
No
No
No
constrain
Yes
Yes
No
No
No
No
default_user
Yes
Yes
No
No
No
No
default_role
Yes
Yes
No
No
No
No
default_type
Yes
Yes
No
No
No
No
default_range
Yes
Yes
No
No
No
No
dominance - MLS
Yes
Yes
No
No
No
No
dominance - Role (Deprecated)
Yes
Yes
Yes
No
Yes
No
dontaudit
Yes
Yes
Yes
Yes
Yes
No
fs_use_task
Yes
Yes
No
No
No
No
fs_use_trans
Yes
Yes
No
No
No
No
fs_use_xattr
Yes
Yes
No
No
No
No
genfscon
Yes
Yes
No
No
No
No
if
Yes
Yes
Yes
No
Yes
No
level
Yes
Yes
No
No
No
No
mlsconstrain
Yes
Yes
No
No
No
No
mlsvalidatetrans
Yes
Yes
No
No
No
No
module
No
No
Yes
No
No
No
netifcon
Yes
Yes
No
No
No
No
neverallow
Yes
Yes
Yes (1)
No
Yes
No
nodecon
Yes
Yes
No
No
No
No
optional
No
Yes
Yes
Yes
Yes
Yes
permissive
Yes
Yes
Yes
Yes
Yes
No
policycap
Yes
Yes
No
No
No
No
portcon
Yes
Yes
No
No
No
No
range_transition
Yes
Yes
Yes
No
Yes
No
require
No
Yes (2)
Yes
Yes (2)
Yes
No
role
Yes
Yes
Yes
No
Yes
Yes
roleattribute
Yes
Yes
Yes
No
Yes
No
role_transition
Yes
Yes
Yes
No
Yes
No
sensitivity
Yes
Yes
No
No
No
Yes
sid
Yes
Yes
No
No
No
No
type
Yes
Yes
Yes
No
No
Yes
type_change
Yes
Yes
Yes
Yes
Yes
No
type_member
Yes
Yes
Yes
Yes
Yes
No
type_transition
Yes
Yes
Yes
Yes (3)
Yes
No
typealias
Yes
Yes
Yes
No
Yes
No
typeattribute
Yes
Yes
Yes
No
Yes
No
typebounds
Yes
Yes
Yes
No
Yes
No
user
Yes
Yes
Yes
No
Yes
Yes
validatetrans
Yes
Yes
No
No
No
No
Table 3: The policy language statements and rules that are allowed within each type of policy source file - The left hand side of the table shows what Policy Language Statements and Rules are allowed within each type of policy source file. The right hand side of the table shows whether the statement is valid within the if / else construct, optional {rule_list}, or require {rule_list} statement.

(1) neverallow statements are allowed in modules, however to detect these the semanage.conf file must have the expand-check=1 entry present. (2) Only if preceded by the optional statement. (3) Excluding the 'file name transition' rule.

Policy Language Definition Links

The policy language statement and rule sections are as follows: