Not all possible alternate statement permutations are shown, however there should be enough variation to work out any other valid formats. There is also an example policy.cil file shown in the Appendix. The MLS components on contexts and user statements must be declared even if the policy does not support MCS/MLS. The CIL compiler will not build a policy unless it also has as a minimum: one allow rule, one sid, sidorder and sidcontext statement. The role object_r must be explicitly associated to contexts used for labeling objects. The original checkpolicy(8) and checkmodule(8) compilers did this by default - CIL does not. Be aware that CIL allows class statements to be declared in a namespace, however the policy author needs to note that applications (and the kernel) generally reference a class by its well known class identifier (e.g. zygote) however if declared in a namespace (e.g. (block zygote (class zygote (...))) or (block zygote (class class (...)))) it would be prefixed with that namespace (e.g. zygote.zygote or zygote.class). Unless the application / kernel code was updated the class would never be resolved, therefore it is recommended that classes are declared in the global namespace. Where possible use typeattribute's when defining source/target allow rules instead of multiple allow rules with individual type's. This will lead to the generation of much smaller kernel policy files. The site explains the language however some of the statement definitions are dated. Declarations may be named or anonymous and have three different forms: Named declarations - These create new objects that introduce a name or identifier, for example: (type process) - creates a type with an identifier of process. (typeattribute domain) - creates a typeattribute with an identifier of domain. (class file (read write)) - creates a class with an identifier of file that has read and write permissions associated to it. The list of declaration type statement keywords are: block optional common class classmap classmapping sid user role roleattribute type classpermission classpermissionset typeattribute typealias tunable sensitivity sensitivityalias category categoryalias categoryset level levelrange context ipaddr macro policycap Explicit anonymous declarations - These are currently restricted to IP addesses where they can be declared directly in statements by enclosing them within parentheses e.g. (127.0.0.1) or (::1). See the Network Labeling Statements section for examples. Anonymous declarations - These have been previously declared and the object already exists, therefore they may be referenced by their name or identifier within statements. For example the following declare all the components required to specify a context: now a portcon statement can be defined that uses these individual components to build a context as follows: 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. 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]. Strings are enclosed within double quotes (e.g. "This is a string"), and may contain any character except the double quote ("). Comments start with a semicolon ';' and end when a new line is started. CIL supports namespaces via containers such as the block statement. When a block is resolved to form the parent / child relationship a dot '.' is used, for example the following allow rule: will resolve to the following kernel policy language statement: CIL has a global namespace that is always present. Any symbol that is declared outside a container is in the global namespace. To reference a symbol in global namespace, the symbol should be prefixed with a dot '.' as shown in the following example: Should the symbol not be prefixed with a dot, the current namespace would be searched first and then the global namespace (provided there is not a symbol of that name in the current namespace). Expressions may occur in the following CIL statements: booleanif tunableif classpermissionset typeattributeset roleattributeset categoryset constrain mlsconstrain validatetrans validatetrans CIL expressions use the prefix or Polish notation and may be nested (note that the kernel policy language uses postfix or reverse Polish notation). The syntax is as follows, where the parenthesis are part of the syntax: The number of expr_set's in an expr is dependent on the statement type (there are four different classes as defined below) that also influence the valid expr_key entries (e.g. dom, domby, incomp are only allowed in constraint statements). expr_key classpermissionset roleattributeset typeattributeset categoryset booleanif tunableif constrain mlsconstrain validatetrans mlsvalidatetrans dom X domby X incomp X eq X X ne X X and X X X X or X X X X not X X X X xor X X X all X X range X The classpermissionset, roleattributeset and typeattributeset statements allow expr_set to mix names and exprs with expr_key values of: and, or, xor, not, all as shown in the examples: This example includes all fs_type type entries except file.usermodehelper and file.proc_security in the associated typeattribute identifier all_fs_type_except_usermodehelper_and_proc_security: The cps_1 classpermissionset identifier includes all permissions except load_policy and setenforce: This example includes all permissions in the associated classpermissionset identifer security_all_perms: The categoryset statement allows expr_set to mix names and expr_key values of: and, or, not, xor, all, range as shown in the examples. Category expressions are also allowed in sensitivitycategory, level, and levelrange statements. The booleanif and tunableif statements only allow an expr_set to have one name or expr with expr_key values of and, or, xor, not, eq, neq as shown in the examples: The constrain, mlsconstrain, validatetrans and mlsvalidatetrans statements only allow an expr_set to have one name or expr with expr_key values of and, or, not, all, eq, neq, dom, domby, incomp. When expr_key is dom, domby or incomp, it must be followed by a string (e.g. h1, l2) and another string or a set of names. The following examples show CIL constraint statements and their policy language equivalents: Used to define macro statement parameter string types: Alternatively: The self keyword may be used as the target in AVC rule statements, and means that the target is the same as the source as shown in the following example:. &policy_config_statements; &container_statements; &call_macro_statements; &default_object_statements; &user_statements; &role_statements; &type_statements; &class_and_permission_statements; &access_vector_rules; &conditional_statements; &constraint_statements; &mls_labeling_statements; &context_statement; &sid_statements; &file_labeling_statements; &network_labeling_statements; &xen_statements; This is the example policy.cil file taken from the CIL compiler source code. &policy_cil;