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.

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 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 rule, one sid, sidorder and 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 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’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.

7. 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:

1. 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

2. Explicit anonymous declarations - These are currently restricted to IP addresses 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.

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 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 ‘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:

    (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, tunableif, classpermissionset, typeattributeset, roleattributeset, categoryset, constrain, mlsconstrain, validatetrans, mlsvalidatetrans

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:

    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).

1. 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:

       (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 identifier 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 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.

3. 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:

       (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, 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:

       ; 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 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 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)))

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:

    (allow source_id target_id|self classpermissionset_id ...)

Where:

Examples:

These examples show a selection of possible permutations of 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:

Example:

This example will log an audit event whenever the corresponding 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:

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:

Example:

This example will not compile as type_3 is not allowed to be a source type for the 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 statement, the statements validatetrans, mlsvalidatetrans, constrain, and mlsconstrain do not limit accesses granted by allowx.

Note that for this to work there must also be valid equivalent allow rules present.

Rule definition:

    (allowx source_id target_id|self permissionx_id)

Where:

Examples:

These examples show a selection of possible permutations of allowx rules:

    (allow type_1 type_2 (tcp_socket (ioctl))) ;; pre-requisite
    (allowx type_1 type_2 (ioctl tcp_socket (range 0x2000 0x20FF)))

    (permissionx ioctl_nodebug (ioctl udp_socket (not (range 0x4000 0x4010))))
    (allow type_3 type_4 (udp_socket (ioctl))) ;; pre-requisite
    (allowx type_3 type_4 ioctl_nodebug)

auditallowx

Audit the access rights defined if there is a valid allowx rule. It does NOT allow access, it only audits the event.

Note that for this to work there must also be valid equivalent auditallow rules present.

Rule definition:

    (auditallowx source_id target_id|self permissionx_id)

Where:

Examples:

This example will log an audit event whenever the corresponding allowx rule grants access to the specified extended permissions:

    (allowx type_1 type_2 (ioctl tcp_socket (range 0x2000 0x20FF)))

    (auditallow type_1 type_2 (tcp_socket (ioctl))) ;; pre-requisite
    (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 for this to work there must also be atleast one allowx rule associated with the target type.

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:

Examples:

This example will not audit the denied access:

    (allowx type_1 type_2 (ioctl tcp_socket (0x1))) ;; pre-requisite, just some irrelevant random ioctl
    (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:

Examples:

This example will not compile as type_3 is not allowed to be a source type and ioctl range for the 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)))
    )

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:

    (call macro_id [(param ...)])

Where:

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.

When resolving macros the following places are checked in this order:

• 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 callers namespace

• Items defined in the global namespace

Statement definition:

    (macro macro_id ([(param_type param_id) ...])
        cil_statements
        ...
    )

Where:

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 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)
    )

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:

    (common common_id (permission_id ...))

Where:

Example:

This common statement will associate the 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 identifier to a one or more permissions declared by a common identifier.

Statement definition:

    (classcommon class_id common_id)

Where:

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:

Examples:

This example defines a set of permissions for the binder class identifier:

    (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, classcommon and 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’s. This is a mandatory statement. Multiple classorder statements declared in the policy will form an ordered list.

Statement definition:

    (classorder (class_id ...))

Where:

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, 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 supersedes the class redeclaration in an unordered statement. The unordered keyword must be the first item in the 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 classpermissionsets to associate one or more classes and permissions to form a named set.

Statement definition:

    (classpermission classpermissionset_id)

Where:

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:

    (classpermissionset classpermissionset_id (class_id (permission_id | expr ...)))

Where:

Examples:

These class permission set statements will resolve to the permission sets shown in the kernel policy language 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 classpermissionsets to be linked to a pair of classmap / classmapping identifiers.

2. 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:

    (classmap classmap_id (classmapping_id ...))

Where:

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:

    (classmapping classmap_id classmapping_id classpermissionset_id)

Where:

Examples:

These class mapping statements will resolve to the permission sets shown in the kernel policy language 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, auditallowx, dontauditx, and neverallowx statements.

Statement definition:

    (permissionx permissionx_id (kind class_id (permission ... | expr ...)))

Where:

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)))))

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:

    (boolean boolean_id true|false)

Where:

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:

    (booleanif boolean_id | expr ...
        (true
            cil_statements
            ...)
        (false
            cil_statements
            ...)
    )

Where:

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:

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:

    (tunableif tunable_id | expr ...
        (true
            cil_statements
            ...)
        (false
            cil_statements
            ...)
    )

Where:

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

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:

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 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:

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:

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 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:

Example:

An MLS validate transition statement with the equivalent kernel policy language statement:

    ;; mlsvalidatetrans { file } ( l1 domby h2 );

    (mlsvalidatetrans file (domby l1 h2))

Container Statements

block

Start a new namespace where any CIL statement is valid.

Statement definition:

    (block block_id
        cil_statement
        ...
    )

Where:

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:

    (block block_id
        (blockabstract template_id)
        cil_statement
        ...
    )

Where:

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:

    (block block_id
        (blockinherit template_id)
        cil_statement
        ...
    )

Where:

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 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:

Statement definition:

    (optional optional_id
        cil_statement
        ...
    )

Where:

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, optional or macro). This statement is not allowed in booleanif or tunableif statements. This only works for containers that aren’t inherited using blockinherit.

Statement definition:

    (in container_id
        cil_statement
        ...
    )

Where:

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)))
    )

Context Statement

Contexts are formed using previously declared parameters and may be named or anonymous where:

• Named - The context is declared with a context identifier 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:

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 specify two 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 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)

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:

    (defaultuser class_id default)

Where:

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:

    (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 identifier. Requires policy version 27.

    (defaultrole class_id default)

Where:

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:

    (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 identifier. Requires policy version 28.

Statement definition:

    (defaulttype class_id default)

Where:

Example:

When creating a new socket object, the 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, target, or both contexts when computing a new context for the object class identifier. Requires policy version 27. glblub as the default requires policy version 32.

Statement definition:

    (defaultrange class_id default <range>)

Where:

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)

MLS userspace object managers may need to compute the common parts of a range such that the object is created with the range common to the subject and containing object:

    (defaultrange db_table glblub)

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:

    (filecon "path" file_type context_id)

Where:

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 <<none>>

fsuse

Label filesystems that support SELinux security contexts.

Statement definition:

    (fsuse fstype fsname context_id)

Where:

Examples:

The context identifiers are declared in the file namespace and the 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 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:

    (genfscon fsname path context_id)

Where:

Examples:

The context identifiers are declared in the file namespace and the genfscon statements are then inserted using the 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)
    )

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:

    (sensitivity sensitivity_id)

Where:

Example:

This example declares three sensitivity identifiers:

    (sensitivity s0)
    (sensitivity s1)
    (sensitivity s2)

sensitivityalias

Declares a sensitivity alias identifier in the current namespace. See the sensitivityaliasactual statement for an example that associates the sensitivityalias identifier.

Statement definition:

    (sensitivityalias sensitivityalias_id)

Where:

Example:

See the sensitivityaliasactual statement.

sensitivityaliasactual

Associates a previously declared sensitivityalias identifier to a previously declared sensitivity identifier.

Statement definition:

    (sensitivityaliasactual sensitivityalias_id sensitivity_id)

Where:

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 statements in the policy will form an ordered list.

Statement definition:

    (sensitivityorder (sensitivity_id ...))

Where:

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.

    (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:

Example:

This example declares a three category identifiers:

    (category c0)
    (category c1)
    (category c2)

categoryalias

Declares a category alias identifier in the current namespace. See the categoryaliasactual statement for an example that associates the categoryalias identifier.

Statement definition:

    (categoryalias categoryalias_id)

Where:

categoryaliasactual

Associates a previously declared categoryalias identifier to a previously declared category identifier.

Statement definition:

    (categoryaliasactual categoryalias_id category_id)

Where:

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 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:

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, sensitivitycategory, level, and levelrange statements.

• Category sets are not allowed in categoryorder statements.

Statement definition:

    (categoryset categoryset_id (category_id ... | expr ...))

Where:

Examples:

These examples show a selection of 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 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:

    (sensitivitycategory sensitivity_id categoryset_id)

Where:

Examples:

These sensitivitycategory examples use a selection of category, categoryalias and 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 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:

    (level level_id (sensitivity_id [categoryset_id]))

Where:

Examples:

These level examples use a selection of category, categoryalias and 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:

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:

    (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:

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)

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:

    (ipaddr ipaddr_id ip_address)

Where:

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:

Examples:

These examples show named and anonymous 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:

Examples:

These examples show named and anonymous 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.255)
    (ipaddr ipv4_1 192.0.2.64)

    (nodecon ipv4_1 netmask_1 context_2)
    (nodecon (192.0.2.64) (255.255.255.255) context_1)
    (nodecon (192.0.2.64) netmask_1 (unconfined.user object_r unconfined.object ((s0) (s0 (c0)))))

    (context context_3 (sys.id sys.role my48prefix.node ((s0)(s0))))

    (ipaddr netmask_2 ffff:ffff:ffff:0:0:0:0:0)
    (ipaddr ipv6_2  2001:db8:1:0:0:0:0:0)

    (nodecon ipv6_2 netmask_2 context_3)
    (nodecon (2001:db8:1:0:0:0:0:0) (ffff:ffff:ffff:0:0:0:0:0) context_3)
    (nodecon (2001:db8:1:0:0:0:0:0) netmask_2 (sys.id sys.role my48prefix.node ((s0)(s0))))

portcon

Label a udp, tcp, dccp or sctp port.

Statement definition:

    (portcon protocol port|(port_low port_high) context_id)

Where:

Examples:

These examples show named and anonymous 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)))
    (portcon dccp (6840 6880) (unconfined.user object_r unconfined.object ((s0) level_2)))
    (portcon sctp (1024 1035) (unconfined.user object_r unconfined.object ((s0) level_2)))

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:

    (mls boolean)

Where:

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 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:

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:

Example:

These set two valid policy capabilities:

    ; Enable networking controls.
    (policycap network_peer_controls)

    ; Enable open permission check.
    (policycap open_perms)

Role Statements

role

Declares a role identifier in the current namespace.

Statement definition:

    (role role_id)

Where:

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 to access a type identifier.

Statement definition:

    (role role_id type_id)

Where:

Example:

This example will declare role and 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 and roleattribute identifiers associated to it via the roleattributeset statement.

Statement definition:

    (roleattribute roleattribute_id)

Where:

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 identifiers to a roleattribute identifier. Expressions may be used to refine the associations as shown in the examples.

Statement definition:

    (roleattributeset roleattribute_id (role_id ... | expr ...))

Where:

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 rule to ensure transition to the new role.

• This rule is not allowed in booleanif statements.

Statement definition:

    (roleallow current_role_id new_role_id)

Where:

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:

    (roletransition current_role_id target_type_id class_id new_role_id)

Where:

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:

Example:

In this example the role test cannot have greater privileges than unconfined.role:

    (role test)

    (unconfined
        (role role)
        (rolebounds role .test)
    )

SID Statements

sid

Declares a new SID identifier in the current namespace.

Statement definition:

    (sid sid_id)

Where:

Examples:

These examples show three sid declarations:

    (sid kernel)
    (sid security)
    (sid igmp_packet)

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:

    (sidorder (sid_id ...))

Where:

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 to a previously declared sid identifier.

Statement definition:

    (sidcontext sid_id context_id)

Where:

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))))

Type Statements

type

Declares a type identifier in the current namespace.

Statement definition:

    (type type_id)

Where:

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:

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:

    (typealiasactual typealias_id type_id)

Where:

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, typealias and typeattribute identifiers associated to it via the typeattributeset statement.

Statement definition:

    (typeattribute typeattribute_id)

Where:

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, typealias or typeattribute identifiers to a typeattribute identifier. Expressions may be used to refine the associations as shown in the examples.

Statement definition:

    (typeattributeset typeattribute_id (type_id ... | expr ...))

Where:

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))
        )
    )

expandtypeattribute

Overrides the compiler defaults for the expansion of one or more previously declared typeattribute identifiers.

This rule gives more control over type attribute expansion and removal. When the value is true, all rules involving the type attribute will be expanded and the type attribute will be removed from the policy. When the value is false, the type attribute will not be removed from the policy, even if the default expand rules or “-X” option cause the rules involving the type attribute to be expanded.

Statement definition:

    (expandtypeattribute typeattribute_id expand_value)

Where:

Examples:

This example uses the expandtypeattribute statement to forcibly expand a previously declared domain type attribute.

    (expandtypeattribute domain true)

This example uses the expandtypeattribute statement to not expand previously declared file_type and port_type type attributes regardless of compiler defaults.

    (expandtypeattribute (file_type port_type) false)

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:

    (typebounds parent_type_id child_type_id)

Where:

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 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:

    (typechange source_type_id target_type_id class_id change_type_id)

Where:

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)
    )