http://selinuxproject.org/w/api.php?action=feedcontributions&user=RichardHaines&feedformat=atomSELinux Wiki - User contributions [en]2024-03-19T13:11:04ZUser contributionsMediaWiki 1.23.13http://selinuxproject.org/page/NB_SQL_9.3NB SQL 9.32020-05-17T10:36:09Z<p>RichardHaines: /* sepgsql Overview */</p>
<hr />
<div>= SE-PostgreSQL =<br />
This section gives an overview of PostgreSQL version 9.3 with the <tt>sepgsql</tt> extension to support SELinux labeling. It assumes some basic knowledge of PostgreSQL that can be found at: [http://wiki.postgresql.org/wiki/Main_Page http://wiki.postgresql.org/wiki/Main_Page]<br />
<br />
It is important to note that PostgreSQL from version 9.3 has the necessary infrastructure to support labeling of database objects via external 'providers'. An <tt>sepgsql</tt> extension has been added that provides SELinux labeling. This is not installed by default but as an option as outlined in the sections that follow. Because of these changes the original version 9.0 patches are no longer supported (i.e. the SE-PostgreSQL database engine is replaced by PostgreSQL database engine 9.3 plus the <tt>sepgsql</tt> extension). A consequence of this change is that row level labeling is no longer supported.<br />
<br />
The features of sepgsql 9.3 and its setup are covered in the following document:<br />
: [http://www.postgresql.org/docs/9.3/static/sepgsql.html http://www.postgresql.org/docs/9.3/static/sepgsql.html]<br />
<br />
== sepgsql Overview ==<br />
The <tt>sepgsql</tt> extension adds SELinux mandatory access controls (MAC) to database objects such as tables, columns, views, functions, schemas and sequences. Figure 1 shows a simple database with one table, two columns and three rows, each with their object class and associated security context (the [[#Internal Tables | Internal Tables]] section shows these entries from the <tt>testdb</tt> database in the Notebook tarball example). The database object classes and permissions are described in the [[NB_ObjectClassesPermissions | Object Classes and Permissions]] section.<br />
<br />
<center>'''Figure 1: Database Security Context Information - '''''Showing the security contexts that can be associated to a schema, table and columns.''</center><br />
{| border="1"<br />
| <br />
| colspan="3" | <center>'''database''' </center><br />
<br />
<center>context = 'unconfined_u:object_r:postgresql_db_t:s0'</center><br />
<br />
<center>This context is inherited from the database directory label - <tt>ls -Z /var/lib/pgsql/data</tt></center><br />
| <br />
<br />
|-<br />
| colspan="3" | <center>'''schema''' (db_schema)</center><br />
<br />
<center>security_label = 'unconfined_u:object_r:sepgsql_schema_t:s0:c10'</center><br />
<br />
|-<br />
| colspan="3" | <center>'''table''' (db_table)</center><br />
<br />
<center>security_label = 'unconfined_u:object_r:sepgsql_table_t:s0:c20'</center><br />
<br />
|-<br />
| <br />
| <center>'''column 1''' (db_column)</center><br />
<br />
<center>security_label = 'unconfined_u:object_r:sepgsql_table_t:s0:c30'</center><br />
| <center>'''column 2''' (db_column)</center><br />
<br />
<center>security_label = 'unconfined_u:object_r:sepgsql_table_t:s0:c40'</center><br />
<br />
|}<br />
<br />
{| border="1"<br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
<br />
To use SE-PostgreSQL each GNU / Linux user must have a valid PostgreSQL database role (not to be confused with an SELinux role). The default installation automatically adds a user called <tt>pgsql</tt> with a suitable database role.<br />
<br />
If a client is connecting remotely and labeled networking is required, then it is possible to use IPSec or NetLabel as discussed in the [[NB_Networking | SELinux Networking Support]] section (the "[http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Security-Enhanced PostgreSQL Security Wiki]" also covers these methods of connectivity with examples). <br />
<br />
Using the [http://selinuxproject.org/~rhaines/NB4-diagrams/24-sepostgresql.png SE-PostgreSQL Services] diagram, the database client application (that could be provided by an API for Perl/PHP or some other programming language) connects to a database and executes SQL commands. As the SQL commands are processed by PostgreSQL, each operation performed on an object is checked by the object manager (OM) to see if the opration is allowed by the security policy or not.<br />
<br />
SE-PostgreSQL supports SELinux services via the <tt>libselinux</tt> library with AVC audits being logged into the standard PostgreSQL file as described in the [[#Logging Security Events|outline Logging Security Events]] section.<br />
<br />
== Installing SE-PostgreSQL ==<br />
The [http://www.postgresql.org/docs/devel/static/sepgsql.html http://www.postgresql.org/docs/devel/static/sepgsql.html] page contains all the information required to install PostgreSQL and the <tt>sepgsql</tt> extension, however the Notebook tarball <tt>sepgsql-9.3/README</tt> file also explains this and adds a simple test database.<br />
<br />
== SECURITY LABEL SQL Command ==<br />
The '<tt>SECURITY LABEL</tt>' SQL command has been added to PostgreSQL to allow security providers to label or change a label on database objects. The command format is:<br />
<pre><br />
SECURITY LABEL [ FOR provider ] ON<br />
{<br />
TABLE object_name |<br />
COLUMN table_name.column_name |<br />
AGGREGATE agg_name (agg_type [, ...] ) |<br />
DATABASE object_name |<br />
DOMAIN object_name |<br />
EVENT TRIGGER object_name |<br />
FOREIGN TABLE object_name<br />
FUNCTION function_name ( [ [ argmode ] [ argname ] argtype [, ...] ] ) |<br />
LARGE OBJECT large_object_oid |<br />
[ PROCEDURAL ] LANGUAGE object_name |<br />
ROLE object_name |<br />
SCHEMA object_name |<br />
SEQUENCE object_name |<br />
TABLESPACE object_name |<br />
TYPE object_name |<br />
VIEW object_name<br />
} IS 'label'<br />
</pre><br />
<br />
The full syntax is defined at [http://www.postgresql.org/docs/9.3/static/sql-security-label.html http://www.postgresql.org/docs/9.3/static/sql-security-label.html] and also in the <tt>'''security_label'''(7)</tt> man page. Some examples taken from the Notebook tarball are:<br />
<pre><br />
--- These set the security label on objects (default provider is SELinux):<br />
SECURITY LABEL ON SCHEMA test_ns IS 'unconfined_u:object_r:sepgsql_schema_t:s0:c10';<br />
SECURITY LABEL ON TABLE test_ns.info IS 'unconfined_u:object_r:sepgsql_table_t:s0:c20';<br />
SECURITY LABEL ON COLUMN test_ns.info.user_name IS 'unconfined_u:object_r:sepgsql_table_t:s0:c30';<br />
SECURITY LABEL ON COLUMN test_ns.info.email_addr IS 'unconfined_u:object_r:sepgsql_table_t:s0:c40';<br />
</pre><br />
<br />
== Additional SQL Functions ==<br />
The following functions have been added:<br />
<br />
{| border="1"<br />
| sepgsql_getcon()<br />
| Returns the client security context.<br />
<br />
|-<br />
| sepgsql_mcstrans_in(text con)<br />
| Translates the readable <tt>range</tt> of the context into raw format provided the <tt>mcstransd</tt> daemon is running.<br />
<br />
|-<br />
| sepgsql_mcstrans_out(text con)<br />
| Translates the raw <tt>range</tt> of the context into readable format provided the <tt>mcstransd</tt> daemon is running.<br />
<br />
|-<br />
| sepgsql_restorecon(text specfile)<br />
| Sets security contexts on all database objects (must be superuser) according to the <tt>specfile</tt>. This is normally used for initialisation of the database by the <tt>sepgsql.sql</tt> script. If the parameter is NULL, then the default <tt>sepgsql_contexts</tt> file is used. See <tt>'''selabel_db'''(5)</tt> details.<br />
<br />
|}<br />
<br />
<br />
== Additional postgresql.conf Entries ==<br />
The <tt>postgresql.conf</tt> file supports the following additional entries to enable and manage SE-PostgreSQL: <br />
* This entry is mandatory to enable the sepgsql extention to be loaded:<br />
<pre><br />
shared_preload_libraries = 'sepgsql'<br />
</pre><br />
* These entries are optional and default to 'off'. The '<tt>custom_variable_classes</tt>' entry must contain '<tt>sepgsql</tt>' to enable these to be configured.<br />
<pre><br />
# This entry allows sepgsql customised entries:<br />
custom_variable_classes = 'sepgsql'<br />
<br />
# These are the possible entries:<br />
# This enables sepgsql to always run in permissive mode:<br />
sepgsql.permissive = on<br />
<br />
# This enables printing of audit messages regardless of the policy setting:<br />
sepgsql.debug_audit = on<br />
</pre><br />
: To view these settings the <tt>SHOW</tt> SQL statement can be used (<tt>psql</tt> output shown):<br />
<pre><br />
SHOW sepgsql.permissive;<br />
sepgsql.permissive<br />
---------------<br />
on<br />
(1 row)<br />
</pre><br />
<pre><br />
SHOW sepgsql.debug_audit;<br />
sepgsql.debug_audit<br />
---------------<br />
on<br />
(1 row)<br />
</pre><br />
<br />
== Logging Security Events ==<br />
SE-PostgreSQL manages its own AVC audit entries in the standard PostgreSQL log normally located within the <tt>/var/lib/pgsql/data/pg_log</tt> directory and by default only errors are logged (Note that there are no SE-PostgreSQL AVC entries added to the standard <tt>audit.log</tt>). The '<tt>sepgsql.debug_audit = on</tt>' can be set to log all audit events.<br />
<br />
== Internal Tables ==<br />
To support the overall database operation PostgreSQL has internal tables in the system catalog that hold information relating to databases, tables etc. This section will only highlight the <tt>pg_seclabel</tt> table that holds the security label and other references. The <tt>pg_seclabel</tt> is described in Table 1 that has been taken from [http://www.postgresql.org/docs/9.3/static/catalog-pg-seclabel.html http://www.postgresql.org/docs/9.3/static/catalog-pg-seclabel.html]. <br />
<br />
<center>'''Table 1: <tt>pg_seclabel</tt> Table Columns'''</center><br />
{| border="1"<br />
! <center>Name</center><br />
! <center>Type</center><br />
! <center>References</center><br />
! Comment<br />
<br />
|-<br />
| objoid<br />
| <center>oid</center><br />
| any OID column<br />
| The OID of the object this security label pertains to.<br />
<br />
|-<br />
| classoid<br />
| <center>oid</center><br />
| [http://www.postgresql.org/docs/9.3/static/catalog-pg-class.html pg_class].oid<br />
| The OID of the system catalog this object appears in.<br />
<br />
|-<br />
| objsubid<br />
| <center>int4</center><br />
| <br />
| For a security label on a table column, this is the column number (the <tt>objoid</tt> and <tt>classoid</tt> refer to the table itself). For all other objects this column is zero.<br />
<br />
|-<br />
| provider<br />
| <center>text</center><br />
| <br />
| The label provider associated with this label. Currently only SELinux is supported.<br />
<br />
|-<br />
| label<br />
| <center>text</center><br />
| <br />
| The security label applied to this object.<br />
<br />
|}<br />
<br />
<br />
These are entries taken from a '<tt>SELECT * FROM pg_seclabel;</tt>' command that refer to the example <tt>testdb</tt> database built using the Notebook tarball samples:<br />
<pre><br />
objoid | classoid | objsubid | provider | label <br />
-------+----------+----------+----------+----------------------------------------------<br />
16390 | 2615 | 0 | selinux | unconfined_u:object_r:sepgsql_schema_t:s0:c10<br />
16391 | 1259 | 0 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c20<br />
16391 | 1259 | 1 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c30<br />
16391 | 1259 | 2 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c40<br />
</pre><br />
<br />
The first entry is the schema, the second entry is the table itself, and the third and fourth entries are columns 1 and 2.<br />
<br />
There is also a built-in 'view' to show additional detail regarding security labels called '<tt>pg_seclabels</tt>'. Using '<tt>SELECT * FROM pg_seclabels;</tt>' command, the entries shown above become:<br />
<pre><br />
objoid | classoid | objsubid | objtype | objnamespace | objname | provider | label <br />
-------+----------+----------+-----------+------------+------------------------+----------+----------------------------------------------<br />
16390 | 2615 | 0 | schema | 16390 | test_ns | selinux | unconfined_u:object_r:sepgsql_schema_t:s0:c10<br />
16391 | 1259 | 0 | table | 16390 | test_ns.info | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c20<br />
16391 | 1259 | 1 | column | 16390 | test_ns.info.user_name | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c30<br />
16391 | 1259 | 2 | column | 16390 | test_ns.info.email_addr| selinux | unconfined_u:object_r:sepgsql_table_t:s0:c40<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_XWIN | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_Apache | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_RefPolicyNB RefPolicy2015-09-25T14:37:09Z<p>RichardHaines: </p>
<hr />
<div>= The Reference Policy =<br />
== Introduction ==<br />
The Reference Policy is now the standard policy source used to build GNU/Linux SELinux policies. This provides a single source tree with supporting documentation that can be used to build policies for different purposes such as: confining important daemons, supporting MLS / MCS type policies and locking down systems so that all processes are under SELinux control. <br />
<br />
This section details how the Reference Policy is:<br />
# Constructed and types of policy builds supported.<br />
# Adding new modules to the build.<br />
# Installation as a full Reference Policy source or as Header files.<br />
# Impact of the migration process being used to convert compiled module files (<tt><nowiki>*.pp</nowiki></tt>) to CIL.<br />
# Modifying the configuration files to build new policies.<br />
# Explain the support macros.<br />
<br />
== Reference Policy Overview ==<br />
Strictly speaking the 'Reference Policy' should refer to the policy taken from the master repository or the latest released version (see [https://github.com/TresysTechnology/refpolicy/wiki https://github.com/TresysTechnology/refpolicy/wiki]). This is because most Linux distributors take a released version and then tailor it to their specific requirements, for example the Fedora distribution is built from the standard Reference Policy but modified and distributed by Red Hat as a source RPM, for example:<br />
: '''selinux-policy-3.12.1-179.fc20.src.rpm'''<ref name="ftn48"><sup>These RPMs can be obtained from [http://koji.fedoraproject.org/ http://koji.fedoraproject.org].</sup></ref><br />
<br />
The master Reference Policy repository can be checked out using the following:<br />
<pre><br />
# Check out the core policy:<br />
git clone https://github.com/TresysTechnology/refpolicy.git<br />
cd refpolicy<br />
# Add the contibuted modules (policy/modules/contrib)<br />
git submodule init<br />
git submodule update<br />
</pre><br />
<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/26-ref-policy.png Reference Policy Source tree] diagram shows the layout that once installed would be located at:<br />
<pre><br />
/etc/selinux/<NAME>/src/policy<br />
</pre><br />
<br />
Where the <tt><nowiki><NAME></nowiki></tt> entry is taken from the <tt>build.conf</tt> file as discussed in the [[#Reference Policy Build Options - build.conf | Reference Policy Build Options - build.conf]] section. The [[#Installing and Building the Reference Policy Source | Installing and Building the Reference Policy Source]] section explains a simple build plus information on building the Fedora source.<br />
<br />
The Reference Policy can be used to build two different formats of policy infrastructure:<br />
# Loadable Module Policy - A policy that has a base module for core services and has the ability to load / unload modules to support applications as required<ref name="ftn49">These can be installed by system administrators as required. The dynamic loading / unloading of policies as applications are loaded is not yet supported.</ref>. This is now the standard used by GNU / Linux distributions.<br />
# Monolithic Policy - A policy that has all the required policy information in a single base policy and does not require the services of the module infrastructure (<tt>'''semanage'''(8)</tt> or <tt>'''semodule'''(8)</tt>). These are more suitable for embedded or minimal systems.<br />
<br />
Each of the policy types are built using module files that define the specific rules required by the policy as detailed in the [[#Reference_Policy_Module_Files | Reference Policy Module Files]] section. Note that the monolithic policy is built using the the same module files by forming a single 'base' source file.<br />
<br />
The Reference Policy relies heavily on the <tt>'''m4'''(1)</tt> macro processor as the majority of supporting services are m4 macros.<br />
<br />
There are tools such as SLIDE (SELinux integrated development environment) that can be used to make the task of policy development and testing easier when using the Reference Policy source or headers. SLIDE is an [http://eclipse.org/ Eclipse] plugin and details can be found at:<br />
<br />
[http://oss.tresys.com/projects/slide http://oss.tresys.com/projects/slide]<br />
<br />
<br />
=== Distributing Policies ===<br />
It is possible to distribute the Reference Policy in two forms:<br />
# As source code that is then used to build policies. This is not the general way policies are distributed as it contains the complete source that most administrators do not need. The [[#Reference Policy Source | Reference Policy Source]] section describes the source and the [[#Installing and Building the Reference Policy Source |Installing and Building the Reference Policy Source]] section describes how to install the source and build a policy.<br />
# As 'Policy Headers'. This is the most common way to distribute the Reference Policy. Basically, the modules that make up 'the distribution' are pre-built and then linked to form a base and optional modules. The 'headers' that make-up the policy are then distributed along with makefiles and documentation. A policy writer can then build policy using the core modules supported by the distribution, and using development tools they can add their own policy modules. The [[#Reference Policy Headers | Reference Policy Headers]] section describes how these are installed and used to build modules.<br />
<br />
The policy header files for F-20 are distributed in a number of rpms as follows:<br />
: '''selinux-policy-3.12.1-179.fc20.noarch.rpm''' - Contains the SELinux /etc/selinux/config file, man pages and the 'Policy Header' development environment that is located at /usr/share/selinux/devel<br />
: '''selinux-policy-doc-3.12.1-179.fc20.noarch.rpm''' - Contains the html policy documentation that is located at /usr/share/doc/selinux-policy/html<br />
: '''selinux-policy-minimum-3.12.1-179.fc20.noarch.rpm'''<br />
: '''selinux-policy-mls-3.12.1-179.fc20.noarch.rpm'''<br />
: '''selinux-policy-targeted-3.12.1-179.fc20.noarch.rpm'''<br />
:: These three rpms contain policy configuration files and the packaged policy modules (<nowiki>*.pp</nowiki>). They will be used to form the particular policy type in <nowiki>/usr/share/selinux/<NAME></nowiki>, the install process will then install the policy in the appropriate <nowiki>/etc/selinux/<NAME></nowiki> directory. Normally only one policy would be installed and active, however for development purposes all can be installed.<br />
: '''selinux-policy-sandbox-3.12.1-179.fc20.noarch.rpm'''<br />
:: Contains the sandbox module for use by the <tt>policycoreutils-sandbox</tt> package. This will be installed as a module for one of the three main policies described above.<br />
<br />
=== Policy Functionality ===<br />
As can be seen from the policies distributed with F-20 above, they can be classified by the name of the functionality they support (taken from the <tt>NAME</tt> entry of the <tt>build.conf</tt>), for example the Fedora policies support:<br />
: minimum - MCS policy that supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space.<br />
: targeted - MCS policy that supports a greater number of confined daemons and can also confine other areas and users (this also supports the older 'strict' policy). <br />
: mls - MLS policy for server based systems.<br />
<br />
=== Reference Policy Module Files ===<br />
The reference policy modules are constructed using a mixture of [[PolicyLanguage#Kernel_Policy_Language | Kernel Policy Language]], [[#Reference Policy Support Macros | support macros]] and Interface macros using three principle types of source file:<br />
* A private policy file that contains statements required to enforce policy on the specific GNU / Linux service being defined within the module. These files are named <nowiki><module_name>.te</nowiki>. For example the ada.te file shown below has two statements:<br />
** one to state that the ada_t process has permission to write to the stack and memory allocated to a file.<br />
** one that states that if the unconfined module is loaded, then allow the ada_t domain unconfined access. Note that if the flow of this statement is followed it will be seen that many more interfaces and macros are called to build the final raw SELinux language statements. An expanded module source is shown in the [[#Module Expansion Process | Module Expansion Process]] section.<br />
* An external interface file that defines the services available to other modules. These files are named <nowiki><module_name>.if</nowiki>.<br />
:: For example the ada.if file shown below has two interfaces defined for other modules to call (see also the [http://selinuxproject.org/~rhaines/NB4-diagrams/27-ref-doc.png Documentation Screenshot] that shows the documentation that can be automatically generated): <br />
** ada_domtrans - that allows another module (running in domain $1) to run the ada application in the ada_t domain.<br />
** ada_run - that allows another module to run the ada application in the ada_t domain (via the ada_domtrans interface), then associate the ada_t domain to the caller defined role ($2) and terminal ($3).<br />
: Provided of course the caller domain has permission. <br />
: It should be noted there are two types of interface specification:<br />
:: '''Access Interfaces''' - These are the most common and define interfaces that <tt>.te</tt> modules can call as described in the ada examples. They are generated by the <tt>interface</tt> macro as detailed in the the [[#interface Macro | interface Macro]] section.<br />
:: '''Template Interfaces''' - These are required whenever a module is required in different domains and allows the type(s) to be redefined by adding a prefix supplied by the calling module. The basic idea is to set up an application in a domain that is suitable for the defined SELinux user and role to access but not others. These are generated by the <tt>template</tt> macro as detailed in the [[#template Macro | template Macro]] section that also explains the <tt>openoffice.if</tt> template.<br />
* A file labeling file that defines the labels to be added to files for the specified module. These files are named <nowiki><module_name>.fc</nowiki>. The build process will amalgamate all the .fc files and finally form the file_contexts file that will be used to label the filesystem.<br />
: For example the ada.fc file shown below requires that the specified files are all labeled system_u:object_r:ada_exec_t:s0. <br />
<br />
The <nowiki><module_name></nowiki> must be unique within the reference policy source tree and should reflect the specific GNU / Linux service being enforced by the policy.<br />
<br />
The module files are constructed using a mixture of:<br />
# Policy language statements as defined in the [[PolicyLanguage#Kernel_Policy_Language | Kernel Policy Language]] section.<br />
# Reference Policy macros that are defined in the [[#Reference_Policy_Macros | Reference Policy Macros]] section.<br />
# External interface calls defined within other modules (.te and .if only).<br />
<br />
An example of each file taken from the ada module is as follows:<br />
<br />
'''ada.te file contents:'''<br />
<pre><br />
policy_module(ada, 1.4.1)<br />
<br />
########################################<br />
#<br />
# Declarations<br />
#<br />
<br />
attribute_role ada_roles;<br />
roleattribute system_r ada_roles;<br />
<br />
type ada_t;<br />
type ada_exec_t;<br />
application_domain(ada_t, ada_exec_t)<br />
role ada_roles types ada_t;<br />
<br />
########################################<br />
#<br />
# Local policy<br />
#<br />
<br />
allow ada_t self:process { execstack execmem };<br />
<br />
userdom_use_inherited_user_terminals(ada_t)<br />
<br />
optional_policy(`<br />
unconfined_domain(ada_t)<br />
')<br />
</pre><br />
<br />
'''ada.if file contents:'''<br />
<pre><br />
## <summary>GNAT Ada95 compiler.</summary><br />
<br />
########################################<br />
## <summary><br />
##Execute the ada program in the ada domain.<br />
## </summary><br />
## <param name="domain"><br />
##<summary><br />
##Domain allowed to transition.<br />
##</summary><br />
## </param><br />
#<br />
interface(`ada_domtrans',`<br />
gen_require(`<br />
type ada_t, ada_exec_t;<br />
')<br />
<br />
corecmd_search_bin($1)<br />
domtrans_pattern($1, ada_exec_t, ada_t)<br />
')<br />
<br />
########################################<br />
## <summary><br />
##Execute ada in the ada domain, and<br />
##allow the specified role the ada domain.<br />
## </summary><br />
## <param name="domain"><br />
##<summary><br />
##Domain allowed to transition.<br />
##</summary><br />
## </param><br />
## <param name="role"><br />
##<summary><br />
##Role allowed access.<br />
##</summary><br />
## </param><br />
#<br />
interface(`ada_run',`<br />
gen_require(`<br />
attribute_role ada_roles;<br />
')<br />
<br />
ada_domtrans($1)<br />
roleattribute $2 ada_roles;<br />
<br />
')<br />
</pre><br />
<br />
'''ada.fc file contents:'''<br />
<pre><br />
/usr/bin/gnatbind--gen_context(system_u:object_r:ada_exec_t,s0)<br />
/usr/bin/gnatls--gen_context(system_u:object_r:ada_exec_t,s0)<br />
/usr/bin/gnatmake--gen_context(system_u:object_r:ada_exec_t,s0)<br />
<br />
/usr/libexec/gcc(/.*)?/gnat1--gen_context(system_u:object_r:ada_exec_t,s0)<br />
</pre><br />
<br />
=== Reference Policy Documentation ===<br />
One of the advantages of the reference policy is that it is possible to automatically generate documentation as a part of the build process. This documentation is defined in XML and generated as HTML files suitable for viewing via a browser. <br />
<br />
The documentation for Fedora can be viewed in a browser by [file:///usr/share/doc/selinux-policy/html/index.html] once the <tt>selinux-policy-doc</tt> rpm has been installed.<br />
<br />
The documentation for the Reference Policy source will be available at <nowiki><location>/src/policy/doc/html</nowiki> once <tt>make html</tt> has been executed (the <nowiki><location></nowiki> is the location of the installed source after make install-src has been executed as described in the [[#Installing and Building the Reference Policy Source | Installing and Building the Reference Policy Source]] section). The Reference Policy documentation may also be available at a default location of <tt>/usr/share/doc/refpolicy-VERSION/html</tt> if <tt>make install-doc</tt> has been executed (where <tt>VERSION</tt> is the entry from the source <tt>VERSION</tt> file.<br />
<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/27-ref-doc.png Documentation Screenshot] shows an example produced for the ada module interfaces. <br />
<br />
== Reference Policy Source ==<br />
This section explains the source layout and configuration files, with the actual installation and building covered in the [[#Installing and Building the Reference Policy Source | Installing and Building the Reference Policy Source]] section. <br />
<br />
The source has a README file containing information on the configuration and installation processes that has been used within this section (and updated with the authors comments as necessary). There is also a VERSION file that contains the Reference Policy release date which can be used to obtain the original source from the repository located at:<br />
: [https://github.com/TresysTechnology/refpolicy/wiki https://github.com/TresysTechnology/refpolicy/wiki]<br />
<br />
=== Source Layout ===<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/26-ref-policy.png Reference Policy Source tree] diagram shows the layout of the reference policy source tree, that once installed would be located at:<br />
<pre><br />
/etc/selinux/<NAME>/src/policy<br />
</pre><br />
<br />
The following sections detail the source contents:<br />
* [[#Reference_Policy_Files_and Director | Reference Policy Files and Directories]] - Describes the files and their location.<br />
* [[#Source_Configuration_Files | Source Configuration Files]] - Details the contents of the build.conf and modules.conf configuration files.<br />
* [[#Source Installation and Build Make Options | Source Installation and Build Make Options]] - Describes the <tt>make</tt> targets.<br />
* [[#Modular_Policy_Build_Stucture | Modular Policy Build Structure]] - Describes how the various source files are linked together to form a base policy module (<tt>base.conf</tt>) during the build process.<br />
<br />
The [[#Installing and Building the Reference Policy Source | Installing and Building the Reference Policy Source]] section then describes how the initial source is installed and configured to allow a policy to be built. <br />
<br />
=== Reference Policy Files and Directories ===<br />
Table 1 shows the major files and their directories with a description of each taken from the README file. All directories are relative to the root of the Reference Policy source directory ./policy.<br />
<br />
Two of these configuration files (build.conf and modules.conf) are further detailed in the [[#Source_Configuration_Files | Source Configuration Files]] section as they define how the policy will be built.<br />
<br />
During the build process, a file is generated in the ./policy directory called either policy.conf or base.conf depending whether a monolithic or modular policy is being built. This file is explained in the [[#Modular_Policy_Build_Stucture | Modular Policy Build Structure]] section.<br />
<br />
<center>'''Table 1: The Reference Policy Files and Directories'''</center><br />
<br />
{| border="1"<br />
! File / Directory Name<br />
! Comments<br />
<br />
|-<br />
| '''Makefile'''<br />
| General rules for building the policy.<br />
<br />
|-<br />
| '''Rules.modular'''<br />
| Makefile rules specific to building loadable module policies.<br />
<br />
|-<br />
| '''Rules.monolithic'''<br />
| Makefile rules specific to building monolithic policies.<br />
<br />
|-<br />
| '''build.conf'''<br />
| Options which influence the building of the policy, such as the policy type and distribution. This file is described in the [[#Reference_Policy_Build_Options - build.conf | Reference Policy Build Options - build.conf]] section.<br />
<br />
|-<br />
| '''<nowiki>config/appconfig-<type></nowiki>'''<br />
| <nowiki>Application configuration files for all configurations of the Reference Policy where <type> is taken from the </nowiki><tt>build.conf</tt> <tt>TYPE</tt> entry that are currently: standard, MLS and MCS). These files are used by SELinux-aware programs and described in the [[ConfigurationFiles | SELinux Configuration Files]] section.<br />
<br />
|-<br />
| '''config/file_contexts.subs_dist'''<br />
| Used to configure file context aliases (see the [#4.4.26.contexts/files/file_contexts.subs and file_contexts.subs_dist File|outline contexts/files/file_contexts.subs and file_contexts.subs_dist File] section).<br />
<br />
|-<br />
| '''config/local.users'''<br />
| The file read by load policy for adding SELinux users to the policy on the fly. <br />
<br />
Note that this file is not used in the modular policy build.<br />
<br />
|-<br />
| '''doc/html/*'''<br />
| When <tt>make html</tt> has been executed, contains the in-policy XML documentation, presented in web page form .<br />
<br />
|-<br />
| '''doc/policy.dtd'''<br />
| The doc/policy.xml file is validated against this DTD.<br />
<br />
|-<br />
| '''doc/policy.xml'''<br />
| This file is generated/updated by the conf and html make targets. It contains the complete XML documentation included in the policy.<br />
<br />
|-<br />
| '''doc/templates/*'''<br />
| Templates used for documentation web pages.<br />
<br />
|-<br />
| '''man/*'''<br />
| Various man pages for modules (ftp, http etc.)<br />
<br />
|-<br />
| '''support/*'''<br />
| Tools used in the build process.<br />
<br />
|-<br />
| '''policy/flask/initial_sids'''<br />
| This file has declarations for each initial SID.<br />
<br />
The file usage in policy generation is described in the [[#Modular Policy Build Structure | Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''policy/flask/security_classes'''<br />
| This file has declarations for each security class.<br />
<br />
The file usage in policy generation is described in the [[#Modular Policy Build Structure | Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''policy/flask/access_vectors'''<br />
| This file defines the common permissions and class specific permissions. The file is described in the [[#Modular Policy Build Structure | Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''policy/modules/*'''<br />
| Each directory represents a layer in Reference Policy. All of the modules are contained in one of these layers. The <tt>contrib</tt> modules are supplied externally to the Reference Policy, then linked into the build.<br />
<br />
The files present in each directory are:<br />
<br />
metadata.xml - describes the layer.<br />
<br />
<nowiki><module_name>.te</nowiki>, .if & .fc - contains policy source as described in the [[#Reference Policy Module Files | Reference Policy Module Files]] section.<br />
<br />
The file usage in policy generation is described in the [[#Modular Policy Build Structure| Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''policy/support/*'''<br />
| Reference Policy support macros. These are described in the [[#Reference Policy Macros | Reference Policy Macros]] section.<br />
<br />
|-<br />
| '''policy/booleans.conf'''<br />
| This file is generated/updated by the conf make target. It contains the booleans in the policy, and their default values. If tunables are implemented as booleans, tunables will also be included. This file will be installed as the /etc/selinux/NAME/booleans file (note that this is not true for any system that implements the modular policy - see the [[#Booleans, Global Booleans and Tunable Booleans | Booleans, Global Booleans and Tunable Booleans]] section).<br />
<br />
|-<br />
| '''policy/constraints'''<br />
| This file defines constraints on permissions in the form of boolean expressions that must be satisfied in order for specified permissions to be granted. These constraints are used to further refine the type enforcement rules and the role allow rules. Typically, these constraints are used to restrict changes in user identity or role to certain domains.<br />
<br />
(Note that this file does not contain the MLS / MCS constraints as they are in the <tt>mls</tt> and <tt>mcs</tt> files described below).<br />
<br />
The file usage in policy generation is described in the [[#Modular Policy Build Structure | Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''policy/context_defaults'''<br />
| This would contain any specific <tt>default_user</tt>, <tt>default_role</tt>, <tt>default_type</tt> and/or <tt>default_range</tt> rules required by the policy.<br />
<br />
|-<br />
| '''policy/global_booleans'''<br />
| This file defines all booleans that have a global scope, their default value, and documentation. See the [[#Booleans, Global Booleans and Tunable Booleans |Booleans, Global Booleans and Tunable Booleans]] section.<br />
<br />
|-<br />
| '''policy/global_tunables'''<br />
| This file defines all tunables that have a global scope, their default value, and documentation. See the [[#Booleans, Global Booleans and Tunable Booleans | Booleans, Global Booleans and Tunable Booleans]] section.<br />
<br />
|-<br />
| '''policy/mcs'''<br />
| This contains information used to generate the <tt>sensitivity</tt>, <tt>category</tt>, <tt>level</tt> and <tt>mlsconstraint</tt> statements used to define the MCS configuration.<br />
<br />
The file usage in policy generation is described in the [[#Modular Policy Build Structure | Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''policy/mls'''<br />
| This contains information used to generate the <tt>sensitivity</tt>, <tt>category</tt>, <tt>level</tt> and <tt>mlsconstraint</tt> statements used to define the MLS configuration.<br />
<br />
The file usage in policy generation is described in the [[#Modular Policy Build Structure | Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''policy/modules.conf'''<br />
| This file contains a listing of available modules, and how they will be used when building Reference Policy.<br />
<br />
To prevent a module from being used, set the module to "off". For monolithic policies, modules set to "base" and "module" will be included in the policy. For modular policies, modules set to "base" will be included in the base module; those set to "module" will be compiled as individual loadable modules.<br />
<br />
This file is described in the [[#Reference_Policy_Build_Options - modules.conf | Reference Policy Build Options - modules.conf]] section.<br />
<br />
|-<br />
| '''policy/policy_capabilities'''<br />
| This file defines the policy capabilities that can be enabled in the policy.<br />
<br />
The file usage in policy generation is described in the [[#Modular Policy Build Structure | Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''policy/users'''<br />
| This file defines the users included in the policy.<br />
<br />
The file usage in policy generation is described in the [[#Modular Policy Build Structure | Modular Policy Build Structure]] section.<br />
<br />
|-<br />
| '''securetty_types'''<br />
| These files are not part of the standard Reference Policy distribution but are added by Fedora source updates.<br />
<br />
|-<br />
| '''setrans.conf'''<br />
<br />
|}<br />
<br />
<br />
=== Source Configuration Files ===<br />
There are two major configuration files (build.conf and modules.conf) that define the policy to be built and are detailed in this section.<br />
<br />
==== Reference Policy Build Options - build.conf ====<br />
This file defines the policy type to be built that will influence its name and where the source will be located once it is finally installed. An example file content is shown in the [[#Installing_and_Building_the Reference Policy Source | Installing and Building the Reference Policy Source]] section where it is used to install and then build the policy.<br />
<br />
Table 2 explains the fields that can be defined within this file, however there are a number of <tt>m4</tt> macro parameters that are set up when this file is read by the build process makefiles. These macro definitions are shown in Table 20 and are also used within the module source files to control how the policy is built with examples shown in the [[#ifdef / ifndef Parameters | ifdef / ifndef Parameters]] section.<br />
<br />
<center>'''Table 2: build.conf Entries'''</center><br />
{| border="1"<br />
! Option<br />
! Type<br />
! Comments<br />
<br />
|-<br />
| '''OUTPUT_POLICY'''<br />
| Integer<br />
| Set the version of the policy created when building a monolithic policy. This option has no effect on modular policy.<br />
<br />
|-<br />
| '''TYPE'''<br />
| String<br />
| Available options are standard (uses RBAC/TE), mcs (uses RBAC/TE/MCS) and mls (uses RBAC/TE/MLS).<br />
<br />
The <tt>mls</tt> and <tt>mcs</tt> options control the enable_mls, and enable_mcs policy blocks.<br />
<br />
|-<br />
| '''NAME'''<br />
| String<br />
| Sets the name of the policy; the NAME is used when installing files to e.g., /etc/selinux/NAME and /usr/share/selinux/NAME. If not set, the policy type field (TYPE) is used.<br />
<br />
|-<br />
| '''DISTRO'''<br />
| String (optional)<br />
| Enable distribution-specific policy. Available options are redhat, rhel4, gentoo, debian, and suse. This option controls distro_redhat, distro_rhel4, distro_suse policy blocks.<br />
<br />
|-<br />
| '''UNK_PERMS'''<br />
| String<br />
| Set the kernel behaviour for handling of permissions defined in the kernel but missing from the policy. The permissions can either be allowed, denied, or the policy loading can be rejected. See the [[NB_LSM#SELinux_Filesystem | SELinux Filesystem]] section for more details. If not set, then it will be taken from the <tt>semanage.conf</tt> file.<br />
<br />
|-<br />
| '''DIRECT_INITRC'''<br />
| Boolean (<tt>y|n</tt>)<br />
| If '<tt>y</tt>' sysadm will be allowed to directly run init scripts, instead of requiring the run_init tool. This is a build option instead of a tunable since role transitions do not work in conditional policy. This option controls direct_sysadm_daemon policy blocks.<br />
<br />
|-<br />
| '''MONOLITHIC'''<br />
| Boolean (<tt>y|n</tt>)<br />
| If '<tt>y</tt>' a monolithic policy is built, otherwise a modular policy is built.<br />
<br />
|-<br />
| '''UBAC'''<br />
| Boolean (<tt>y|n</tt>)<br />
| If '<tt>y</tt>' User Based Access Control policy is built. The default for Red Hat is '<tt>n</tt>'. These are defined as constraints in the <tt>policy/constraints</tt> file. Note Version 1 of the Reference Policy did not have this entry and defaulted to Role Based Access Control.<br />
<br />
The UBAC option is described at [http://blog.siphos.be/2011/05/selinux-user-based-access-control/ http://blog.siphos.be/2011/05/selinux-user-based-access-control/].<br />
<br />
|-<br />
| '''CUSTOM_BUILDOPT'''<br />
| String<br />
| Space separated list of custom build options.<br />
<br />
|-<br />
| '''MLS_SENS'''<br />
| Integer<br />
| Set the number of sensitivities in the MLS policy. Ignored on standard and MCS policies.<br />
<br />
|-<br />
| '''MLS_CATS'''<br />
| Integer<br />
| Set the number of categories in the MLS policy. Ignored on standard and MCS policies.<br />
<br />
|-<br />
| '''MCS_CATS'''<br />
| Integer<br />
| Set the number of categories in the MCS policy. Ignored on standard and MLS policies.<br />
<br />
|-<br />
| '''QUIET'''<br />
| Boolean (<tt>y|n</tt>)<br />
| If '<tt>y</tt>' the build system will only display status messages and error messages. This option has no effect on policy.<br />
<br />
|}<br />
<br />
<br />
<center>'''Table 3: <tt>m4</tt> parameters set at build time - '''''These have been extracted from the Reference Policy <tt>Makefile</tt> file.''</center><br />
<br />
{| border="1"<br />
! m4 Parameter Name in Makefile<br />
! From build.conf entry<br />
! Comments<br />
<br />
|-<br />
| enable_mls<br />
| '''TYPE'''<br />
| Set if MLS policy build enabled.<br />
<br />
|-<br />
| enable_mcs<br />
| '''TYPE'''<br />
| Set if MCS policy build enabled.<br />
<br />
|-<br />
| enable_ubac<br />
| '''UBAC'''<br />
| Set if UBAC set to '<tt>y</tt>'.<br />
<br />
|-<br />
| mls_num_sens<br />
| '''MLS_SENS'''<br />
| The number of MLS sensitivities configured.<br />
<br />
|-<br />
| mls_num_cats<br />
| '''MLS_CATS'''<br />
| The number of MLS categories configured.<br />
<br />
|-<br />
| mcs_num_cats<br />
| '''MCS_CATS'''<br />
| The number of MCS categories configured.<br />
<br />
|-<br />
| distro_$(DISTRO)<br />
| '''DISTRO'''<br />
| The distro name or blank.<br />
<br />
|-<br />
| direct_sysadm_daemon<br />
| '''DIRECT_INITRC'''<br />
| If <tt>DIRECT_INITRC</tt> entry set to '<tt>y</tt>'.<br />
<br />
|-<br />
| hide_broken_symtoms<br />
| <br />
| This is set up in the <tt>Makefile</tt> and can be used in modules to hide errors with <tt>dontaudit</tt> rules (or even <tt>allow</tt> rules).<br />
<br />
|}<br />
<br />
<br />
==== Reference Policy Build Options - policy/modules.conf ====<br />
This file controls what modules are built within the policy with example entries as follows:<br />
<pre><br />
# Layer: kernel<br />
# Module: kernel<br />
# Required in base<br />
#<br />
# Policy for kernel threads, proc filesystem,and unlabeled processes and<br />
# objects.<br />
# <br />
kernel = base<br />
<br />
# Module: amanda<br />
#<br />
# Automated backup program.<br />
# <br />
amanda = module<br />
<br />
# Layer: admin<br />
# Module: ddcprobe<br />
#<br />
# ddcprobe retrieves monitor and graphics card information<br />
# <br />
ddcprobe = off<br />
</pre><br />
<br />
As can be seen the only active line (those without comments<ref name="ftn50">The comments are also important as they form part of the documentation when it is generated by the <tt>make html</tt> target.</ref>) is:<br />
<pre><br />
<module_name> = base | module | off<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| module_name<br />
| The name of the module to be included within the build.<br />
<br />
|-<br />
| base<br />
| The module will be in the base module for a modular policy build (build.conf entry MONOLITHIC <nowiki>=</nowiki> n).<br />
<br />
|-<br />
| module<br />
| The module will be built as a loadable module for a modular policy build. If a monolithic policy is being built (build.conf entry MONOLITHIC <nowiki>=</nowiki> y), then this module will be built into the base module.<br />
<br />
|-<br />
| off<br />
| The module will not be included in any build.<br />
<br />
|}<br />
<br />
Generally it is up to the policy distributor to decide which modules are in the base and those that are loadable, however there are some modules that MUST be in the base module. To highlight this there is a special entry at the start of the modules interface file (.if) that has the entry <nowiki><required val="true"></nowiki> as shown below (taken from the kernel.if file): <br />
<pre><br />
## <summary><br />
##Policy for kernel threads, proc filesystem, <br />
##and unlabeled processes and objects.<br />
## </summary><br />
## <required val="true"><br />
##This module has initial SIDs.<br />
## </required><br />
</pre><br />
<br />
The <tt>modules.conf</tt> file will also reflect that a module is required in the base by adding a comment 'Required in base' when the make conf target is executed (as all the <tt>.if</tt> files are checked during this process and the <tt>modules.conf</tt> file updated).<br />
<pre><br />
# Layer: kernel<br />
# Module: kernel<br />
# Required in base<br />
#<br />
# Policy for kernel threads, proc filesystem,and unlabeled processes and objects.<br />
# <br />
kernel = base<br />
</pre><br />
<br />
Those marked as required in base are shown in Table 4 (note that F-20 and the standard Reference Policy are different)<br />
<br />
<center>'''Table 4: Mandatory modules.conf Entries'''</center><br />
<br />
{| border="1"<br />
! Layer<br />
! Module Name<br />
! Comments<br />
<br />
|-<br />
| kernel<br />
| corecommands<br />
| Core policy for shells, and generic programs in:<br />
<br />
/bin, /sbin, /usr/bin, and /usr/sbin. <br />
<br />
The .fc file sets up the labels for these items. <br />
<br />
All the interface calls start with 'corecmd_'.<br />
<br />
|-<br />
| kernel<br />
| corenetwork<br />
| Policy controlling access to network objects and also contains the initial SIDs for these.<br />
<br />
The <tt>.if</tt> file is large and automatically generated. All the interface calls start with '<tt>corenet_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| devices<br />
| This module creates the device node concept and provides the policy for many of the device files. Notable exceptions are the mass storage and terminal devices that are covered by other modules (that is a char or block device file, usually in /dev). All types that are used to label device nodes should use the dev_node macro.<br />
<br />
Additionally this module controls access to three things:<br />
<br />
# the device directories containing device nodes.<br />
# device nodes as a group<br />
# individual access to specific device nodes covered by this module.<br />
<br />
All the interface calls start with '<tt>dev_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| domain<br />
| Contains the core policy for forming and managing domains.<br />
<br />
All the interface calls start with '<tt>domain_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| files<br />
| This module contains basic filesystem types and interfaces and includes:<br />
<br />
# The concept of different file types including basic files, mount points, tmp files, etc.<br />
# Access to groups of files and all files.<br />
# Types and interfaces for the basic filesystem layout (/, /etc, /tmp, /usr, etc.).<br />
# Contains the file initial SID.<br />
<br />
All the interface calls start with '<tt>files_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| filesystem<br />
| Contains the policy for filesystems and the initial SID.<br />
<br />
All the interface calls start with '<tt>fs_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| kernel<br />
| Contains the policy for kernel threads, proc filesystem, and unlabeled processes and objects. This module has initial SIDs.<br />
<br />
All the interface calls start with '<tt>kernel_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| mcs<br />
| Policy for Multicategory security. The .te file only contains attributes used in MCS policy.<br />
<br />
All the interface calls start with '<tt>mcs_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| mls<br />
| Policy for Multilevel security. The .te file only contains attributes used in MLS policy.<br />
<br />
All the interface calls start with '<tt>mls_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| selinux<br />
| Contains the policy for the kernel SELinux security interface (selinuxfs).<br />
<br />
All the interface calls start with '<tt>selinux_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| terminal<br />
| Contains the policy for terminals.<br />
<br />
All the interface calls start with '<tt>term_</tt>'.<br />
<br />
|-<br />
| kernel<br />
| ubac<br />
| Disabled by Fedora but enabled on standard Ref Policy.<br />
<br />
Support user-based access control.<br />
<br />
|-<br />
| system<br />
| application<br />
| Enabled by Fedora but not standard Ref Policy.<br />
<br />
Defines attributes and interfaces for all user apps.<br />
<br />
|-<br />
| system<br />
| setrans<br />
| Enabled by Fedora but not standard Ref Policy.<br />
<br />
Support for <tt>'''mcstransd'''(8)</tt>.<br />
<br />
|}<br />
<br />
<br />
===== Building the modules.conf File =====<br />
The file can be created by an editor, however it is generally built initially by make conf that will add any additional modules to the file. The file can then be edited to configure the required modules as base, module or off.<br />
<br />
As will be seen in the [[#Installing_and_Builing_the Reference Policy Source | Installing and Building the Reference Policy Source]] section, the Red Hat reference policy source comes with a number of pre-configured files that are used to produce the required policy including multiple versions of the modules.conf file.<br />
<br />
=== Source Installation and Build Make Options ===<br />
This section explains the various make options available that have been taken from the <tt>README</tt> file. Table 5 describes the general make targets, Table 6 describes the modular policy make targets and Table 7 describes the monolithic policy make targets.<br />
<br />
<center>'''Table 5: General Build Make Targets'''</center><br />
{| border="1"<br />
! Make Target<br />
! Comments<br />
<br />
|-<br />
| '''install-src'''<br />
| Install the policy sources into /etc/selinux/NAME/src/policy, where NAME is defined in the build.conf file. If it is not defined, then TYPE is used instead. If a build.conf does not have the information, then the Makefile will default to the current entry in the /etc/selinux/config file or default to refpolicy. A pre-existing source policy will be moved to /etc/selinux/NAME/src/policy.bak.<br />
<br />
|-<br />
| '''conf'''<br />
| Regenerate policy.xml, and update/create modules.conf and booleans.conf. This should be done after adding or removing modules, or after running the bare target. If the configuration files exist, their settings will be preserved. This must be run on policy sources that are checked out from the CVS repository before they can be used.<br />
<br />
Note that if <tt>make bare</tt> has been executed before this make target, or it is a first build, then the <tt>modules/kernel/corenetwork.??.in</tt> files will be used to generate the <tt>corenetwork.te</tt> and <tt>corenetwork.if</tt> module files. These <tt><nowiki>*.in</nowiki></tt> files may be edited to configure network ports etc. (see the <tt><nowiki># network_node examples</nowiki></tt> entries).<br />
<br />
|-<br />
| '''clean'''<br />
| Delete all temporary files, compiled policies, and file_contexts. Configuration files are left intact.<br />
<br />
|-<br />
| '''bare'''<br />
| Do the clean make target and also delete configuration files, web page documentation, and policy.xml.<br />
<br />
|-<br />
| '''html'''<br />
| Regenerate policy.xml and create web page documentation in the doc/html directory.<br />
<br />
|-<br />
| '''install-appconfig'''<br />
| Installs the appropriate SELinux-aware configuration files.<br />
<br />
|}<br />
<br />
<br />
<center>'''Table 6: Modular Policy Build Make Targets'''</center><br />
{| border="1"<br />
! Make Target<br />
! Comments<br />
<br />
|-<br />
| '''base'''<br />
| Compile and package the base module. This is the default target for modular policies.<br />
<br />
|-<br />
| '''modules'''<br />
| Compile and package all Reference Policy modules configured to be built as loadable modules.<br />
<br />
|-<br />
| '''MODULENAME.pp'''<br />
| Compile and package the <tt>MODULENAME</tt> Reference Policy module.<br />
<br />
|-<br />
| '''all'''<br />
| Compile and package the base module and all Reference Policy modules configured to be built as loadable modules.<br />
<br />
|-<br />
| '''install'''<br />
| Compile, package, and install the base module and Reference Policy modules configured to be built as loadable modules.<br />
<br />
|-<br />
| '''load'''<br />
| Compile, package, and install the base module and Reference Policy modules configured to be built as loadable modules, then insert them into the module store.<br />
<br />
|-<br />
| '''validate'''<br />
| Validate if the configured modules can successfully link and expand.<br />
<br />
|-<br />
| '''install-headers'''<br />
| Install the policy headers into /usr/share/selinux/NAME. The headers are sufficient for building a policy module locally, without requiring the complete Reference Policy sources. The build.conf settings for this policy configuration should be set before using this target.<br />
<br />
|-<br />
| '''install-docs'''<br />
| Build and install the documentation and example module source with Makefile. The default location is <tt>/usr/share/doc/refpolicy-VERSION</tt>, where the version is the value in the <tt>VERSION</tt> file.<br />
<br />
|}<br />
<br />
<br />
<center>'''Table 7: Monolithic Policy Build Make Targets'''</center><br />
{| border="1"<br />
! Make Target<br />
! Comments<br />
<br />
|-<br />
| '''policy'''<br />
| Compile a policy locally for development and testing. This is the default target for monolithic policies.<br />
<br />
|-<br />
| '''install'''<br />
| Compile and install the policy and file contexts.<br />
<br />
|-<br />
| '''load'''<br />
| Compile and install the policy and file contexts, then load the policy.<br />
<br />
|-<br />
| '''enableaudit'''<br />
| Remove all dontaudit rules from policy.conf.<br />
<br />
|-<br />
| '''relabel'''<br />
| Relabel the filesystem.<br />
<br />
|-<br />
| '''checklabels'''<br />
| Check the labels on the filesystem, and report when a file would be relabeled, but do not change its label.<br />
<br />
|-<br />
| '''restorelabels'''<br />
| Relabel the filesystem and report each file that is relabeled.<br />
<br />
|}<br />
<br />
<br />
=== Booleans, Global Booleans and Tunable Booleans ===<br />
The three files <tt>booleans.conf</tt>, <tt>global_booleans</tt> and <tt>global_tunables</tt> are built and used as follows:<br />
<br />
{| border="1"<br />
| booleans.conf<br />
| This file is generated / updated by <tt>make conf</tt>, and contains all the booleans in the policy with their default values. If tunable and global booleans are implemented then these are also included. <br />
<br />
This file can also be delivered as a part of the Fedora reference policy source as shown in the [[#Installing and Building the Reference Policy Source | Installing and Building the Reference Policy Source]] section. This is generally because other default values are used for booleans and not those defined within the modules themselves (i.e. distribution specific booleans). When the make install is executed, this file will be used to set the default values. <br />
<br />
Note that if booleans are updated locally the policy store will contain a [[PolicyStoreConfigurationFiles#modules_active_booleans.local_File | booleans.local]] file.<br />
<br />
In SELinux enabled systems that support the policy store features (modular policies) this file is not installed as <tt>/etc/selinux/NAME/booleans</tt>.<br />
<br />
|-<br />
| global_booleans<br />
| These are booleans that have been defined in the <tt>global_tunables</tt> file using the [[#gen_bool Macro | gen_bool]] macro. They are normally booleans for managing the overall policy and currently consist of the following (where the default values are <tt>false</tt>):<br />
<br />
secure_mode<br />
<br />
|-<br />
| global_tunables<br />
| These are booleans that have been defined in module files using the [[#gen_tunable Macro | gen_tunable]] macro and added to the <tt>global_tunables</tt> file by <tt>make conf</tt>. The [[#tunable_policy Macro | tunable_policy]] macros are defined in each module where policy statements or interface calls are required. They are booleans for managing specific areas of policy that are global in scope. An example is <tt>allow_execstack</tt> that will allow all processes running in <tt>unconfined_t</tt> to make their stacks executable.<br />
<br />
|}<br />
<br />
<br />
=== Modular Policy Build Structure ===<br />
This section explains the way a modular policy is constructed, this does not really need to be known but is used to show the files used that can then be investigated if required. <br />
<br />
When make all or make load or make install are executed the build.conf and modules.conf files are used to define the policy name and what modules will be built in the base and those as individual loadable modules.<br />
<br />
Basically the source modules (<tt>.te</tt>, <tt>.if</tt> and <tt>.fc</tt>) and core flask files are rebuilt in the tmp directory where the reference policy macros<ref name="ftn51"><sup>These are explained in the [[#Reference Policy Support Macros | Reference Policy Macros]] section.</sup></ref> in the source modules will be expanded to form actual policy language statements as described in the [[PolicyLanguage#Kernel_Policy_Language | SELinux Policy Language Policy Language]] section. '''Layout 1''' shows these temporary files that are used to form the base.conf<ref name="ftn52"><sup>The base.conf gets built for modular policies and a policy.conf file gets built for a monolithic policy.</sup></ref> file during policy generation. <br />
<br />
The <tt>base.conf</tt> file will consist of language statements taken from the module defined as <tt>base</tt> in the <tt>modules.conf</tt> file along with the constraints, users etc. that are required to build a complete policy.<br />
<br />
The individual loadable modules are built in much the same way as shown in '''Layout 2'''.<br />
<br />
<center>'''Layout 1: Base Module Build - '''''This shows the temporary build files used to build the base module '<tt>base.conf</tt>' as a part of the 'make' process. Note that the modules marked as <tt>base</tt> in <tt>modules.conf</tt> are built here. ''</center><br />
{| border="1"<br />
! Base Policy Component Description<br />
! Policy Source File Name (relative to ./policy/policy)<br />
! ./policy/tmp <br />
<br />
File Name<br />
<br />
|-<br />
| The object classes supported by the kernel.<br />
| flask/security_classes<br />
| pre_te_files.conf<br />
<br />
|-<br />
| The initial SIDs supported by the kernel.<br />
| flask/initial_sids<br />
<br />
|-<br />
| The object class permissions supported by the kernel.<br />
| flask/access_vectors<br />
<br />
|-<br />
| This is either the expanded mls or mcs file depending on the type of policy being built.<br />
| mls or mcs<br />
<br />
|-<br />
| These are the policy capabilities that can be configured / enabled to support the policy.<br />
| policy_capabilities<br />
<br />
|-<br />
| This area contains all the attribute, bool, type and typealias statements extracted from the <nowiki>*.te</nowiki> and <nowiki>*.if</nowiki> files that form the base module.<br />
| modules/*/*.te<br />
<br />
modules/*/*.if<br />
<br />
<br />
<br />
| all_attrs_types.conf<br />
<br />
|-<br />
| Contains the global and tunable bools extracted from the conf files. <br />
| global_bools.conf<br />
<br />
global_tunables.conf<br />
| global_bools.conf<br />
<br />
|-<br />
| Contains the rules extracted from each of the modules .te and .if files defined in the modules.conf file as 'base'.<br />
| base modules<br />
| only_te_rules.conf<br />
<br />
|-<br />
| Contains the expanded users from the users file.<br />
| users<br />
| all_post.conf<br />
<br />
|-<br />
| Contains the expanded constraints from the constraints file.<br />
| constraints<br />
<br />
|-<br />
| Contains the default SID labeling extracted from the <nowiki>*.te</nowiki> files.<br />
| modules/*/*.te<br />
<br />
|-<br />
| Contains the fs_use_xattr, fs_use_task, fs_use_trans and genfscon statements extracted from each of the modules .te and .if files defined in the modules.conf file as 'base'.<br />
| modules/*/*.te<br />
<br />
modules/*/*.if<br />
<br />
<br />
<br />
<br />
|-<br />
| Contains the netifcon, nodecon and portcon statements extracted from each of the modules .te and .if files defined in the modules.conf file as 'base'.<br />
| modules/*/*.te<br />
<br />
modules/*/*.if<br />
<br />
<br />
<br />
| <br />
<br />
|-<br />
| Contains the expanded file context file entries extracted from the <nowiki>*.fc</nowiki> files defined in the modules.conf file as 'base'.<br />
| modules/*/*.fc<br />
| base.fc.tmp<br />
<br />
|-<br />
| Expanded seusers file.<br />
| seusers<br />
| seusers<br />
<br />
|-<br />
| colspan="3" | These are the commands used to compile, link and load the base policy module:<br />
<pre><br />
checkmodule base.conf -o tmp/base.mod<br />
semodule_package -o base.conf -m base_mod -f base_fc -u users_extra -s tmp/seusers<br />
semodule -s $(NAME) -b base.pp) -i and each module .pp file<br />
</pre><br />
The 'NAME' is that defined in the build.conf file.<br />
<br />
|}<br />
<br />
<br />
<center>'''Layout 2: Module Build - '''''This shows the module files and the temporary build files used to build each module as a part of the 'make' process (i.e. those modules marked as <tt>module</tt> in <tt>modules.conf</tt>).''</center><br />
{| border="1"<br />
| '''Base Policy Component Description'''<br />
| '''Policy Source File Name '''(relative to ./policy/policy)<br />
| '''./policy/tmp '''<br />
<br />
'''File Name'''<br />
<br />
|-<br />
| For each module defined as 'module' in the modules.conf configuration file, a source module is produced that has been extracted from the <nowiki>*.te</nowiki> and <nowiki>*.if</nowiki> file for that module.<br />
| <nowiki>modules/*/<module_name>.te</nowiki><br />
<br />
<nowiki>modules/*/<module_name>.if</nowiki><br />
<br />
<br />
<br />
| <nowiki><module_name>.tmp</nowiki><br />
<br />
<br />
<br />
<br />
|-<br />
| For each module defined as 'module' in the modules.conf configuration file, an object module is produced from executing the checkmodule command shown below.<br />
| <nowiki>tmp/<module_name>.tmp</nowiki><br />
| <nowiki><module_name>.mod</nowiki><br />
<br />
|-<br />
| For each module defined as 'module' in the modules.conf<nowiki> configuration file, an expanded file context file is built from the <module_name></nowiki>.fc file.<br />
| <nowiki>modules/*/<module_name>.fc</nowiki><br />
| base.fc.tmp<br />
<br />
|-<br />
| colspan="3" | This command is used to compile each module:<br />
<br />
<nowiki>checkmodule tmp/<module_name>.tmp -o tmp/<module_name>.mod</nowiki><br />
<br />
<br />
Each module is packaged and loaded with the base module using the following commands:<br />
<pre><br />
semodule_package -o base.conf -m base_mod -f base_fc -u users_extra -s tmp/seusers<br />
semodule -s $(NAME) -b base.pp) -i and each module .pp file<br />
</pre><br />
The 'NAME' is that defined in the build.conf file.<br />
<br />
|}<br />
<br />
=== Creating Additional Layers ===<br />
One objective of the reference policy is to separate the modules into different layers reflecting their 'service' (e.g. kernel, system, app etc.). While it can sometimes be difficult to determine where a particular module should reside, it does help separation, however because the way the build process works, each module must have a unique name.<br />
<br />
If a new layer is required, then the following will need to be completed:<br />
<br />
# Create a new layer directory ./policy/modules/LAYERNAME that reflects the layer's purpose.<br />
# In the ./policy/modules/LAYERNAME directory create a metadata.xml file. This is an XML file with a summary tag and optional desc (long description) tag that should describe the purpose of the layer and will be used as a part of the documentation. An example is as follows:<br />
<pre><br />
<summary>ABC modules for the XYZ components.</summary><br />
</pre><br />
<br />
== Installing and Building the Reference Policy Source ==<br />
This section will give a brief overview of how to build the Reference Policy for an MCS modular build that is similar (but not the same) as the Fedora targeted policy. The Fedora F-20 version of the targeted policy build is discussed but building without using the rpm spec file is more complex. <br />
<br />
=== Building Standard Reference Policy ===<br />
This will run through a simple configuration process and build of a reference policy similar to the Fedora targeted policy. By convention the source is installed in a central location and then for each type of policy a copy of the source is installed at <tt><nowiki>/etc/selinux/<NAME>/src/policy</nowiki></tt>.<br />
<br />
The basic steps are:<br />
* Install master Reference Policy Source and add the contributed modules:<br />
<pre><br />
# Check out the core policy:<br />
git clone https://github.com/TresysTechnology/refpolicy.git<br />
cd refpolicy<br />
<br />
# Add the contibuted modules (policy/modules/contrib)<br />
git submodule init<br />
git submodule update<br />
</pre><br />
<br />
* Edit the <tt>build.conf</tt> file to reflect the policy to be built, the minimum required is setting the <tt>NAME =</tt> entry. An example file with <tt>NAME = refpolicy-test</tt> is as follows:<br />
<pre><br />
############################################<br />
# Policy build options<br />
#<br />
<br />
# Policy version<br />
# By default, checkpolicy will create the highest version policy it supports. <br />
# Setting this will override the version. This only has an effect for<br />
# monolithic policies.<br />
#OUTPUT_POLICY = 18<br />
<br />
# Policy Type<br />
# standard, mls, mcs. ** Note Red Hat always build the MCS Policy Type<br />
# for their 'targeted' version. **<br />
TYPE = mcs<br />
<br />
# Policy Name<br />
# If set, this will be used as the policy name. Otherwise the policy type <br />
# will be used for the name. ** This entry is also used by the<br />
#'make install-src' process to copy the source to the:<br />
# /etc/selinux/<NAME>/src/policy directory. **<br />
NAME = refpolicy-test<br />
<br />
# Distribution<br />
# Some distributions have portions of policy for programs or configurations <br />
# specific to the distribution. Setting this will enable options for the<br />
# distribution. redhat, gentoo, debian, suse, and rhel4 are current options.<br />
# ** Fedora users should enable redhat.**<br />
DISTRO = redhat<br />
<br />
# Unknown Permissions Handling<br />
# The behaviour for handling permissions defined in the kernel but missing<br />
# from the policy. The permissions can either be allowed, denied, or<br />
# the policy loading can be rejected.<br />
# allow, deny, and reject are current options. ** Fedora use allow for all<br />
# policies except MLS that uses 'deny'.**<br />
UNK_PERMS = allow<br />
<br />
# Direct admin init<br />
# Setting this will allow sysadm to directly run init scripts, instead of <br />
# requiring run_init. This is a build option, as role transitions do not<br />
# work in conditional policy.<br />
DIRECT_INITRC = n<br />
<br />
# Build monolithic policy. Putting y here will build a monolithic policy.<br />
MONOLITHIC = n<br />
<br />
# User-based access control (UBAC)<br />
# Enable UBAC for role separations. ** Note Fedora disables UBAC.**<br />
UBAC = n<br />
<br />
# Custom build options. This field enables custom build options. Putting<br />
# foo here will enable build option blocks foo. Options should be separated<br />
# by spaces.<br />
CUSTOM_BUILDOPT =<br />
<br />
# Number of MLS Sensitivities<br />
# The sensitivities will be s0 to s(MLS_SENS-1). Dominance will be in<br />
# increasing numerical order with s0 being lowest.<br />
MLS_SENS = 16<br />
<br />
# Number of MLS Categories.<br />
# The categories will be c0 to c(MLS_CATS-1).<br />
MLS_CATS = 1024<br />
<br />
# Number of MCS Categories<br />
# The categories will be c0 to c(MLC_CATS-1).<br />
MCS_CATS = 1024<br />
<br />
# Set this to y to only display status messages during build.<br />
QUIET = n<br />
</pre><br />
<br />
* Run <tt>make install-src</tt> to install source at policy build location.<br />
* Change to the <tt><nowiki>/etc/selinux/<NAME>/src/policy</nowiki></tt> directory where an unconfigured basic policy has been installed.<br />
* Run <tt>make conf</tt> to build an initial <tt>policy/booleans.conf</tt> and <tt>policy/modules.conf</tt> files. For this simple configuration these files will not be edited.<br />
: This process will also build the <tt>policy/modules/kernel/corenetwork.te</tt> / <tt>corenetwork.if</tt> files if not already present. These would be based on the contents of <tt>corenetwork.te.in</tt> and <tt>corenetwork.if.in</tt> configuration files (for this simple configuration these files will not be edited).<br />
: Run <tt>make load</tt> to build the policy, add the modules to the store and install the binary kernel policy plus its supporting configuration files.<br />
: Note that if policy stores have been migrated, the store will default to <tt>/var/lib/selinux/refpolicy-test</tt>, with the modules in <tt><nowiki>active/modules/400/<module_name></nowiki></tt>, there will also be a CIL version of the module (see [#4.1.1.Policy Store Migration|outline Policy Store Migration] for details).<br />
* The policy should now be built and can be checked using tools such as <tt>'''apol'''(8)</tt> or loaded by editing the <tt>/etc/selinux/config</tt> file, running '<tt>touch /.autorelabel</tt>' and rebooting the system.<br />
<br />
=== Building the Fedora Policy ===<br />
Building Fedora policies by hand is complex as they use the <tt>rpmbuild/SPECS/selinux-policy.spec</tt> file, therefore this section will give an overview of how this can be achieved, the reader can then experiment (the spec file gives an insight). The build process assumes that an equivelent '<tt>targeted</tt>' policy will be built named '<tt>targeted-179</tt>'.<br />
<br />
Install the source as follows:<br />
<pre><br />
rpm -Uvh selinux-policy-3.12.1-179.fc20.src.rpm<br />
</pre><br />
<br />
The <tt>rpmbuild/SOURCES</tt> directory contents should be as follows with comments on how the files should be installed:<br />
<br />
{| border="1"<br />
| <center>'''File Name'''</center><br />
| <center>'''Comments'''</center><br />
<br />
|-<br />
| serefpolicy-3.12.1.tgz<br />
| The Reference Policy version 2.20120725<br />
<br />
This should be unpacked into:<br />
<pre><br />
rpmbuild/SOURCES/serefpolicy-3.12.1<br />
</pre><br />
|-<br />
| policy-f20-base.patch<br />
| Fedora changes to Reference Policy version 2.20120725.<br />
<br />
These patches should be used to update the above<br />
<pre><br />
patch -p1 < policy-f20-base.patch<br />
</pre><br />
|-<br />
| serefpolicy-contrib-3.12.1.tgz<br />
| The Reference Policy contribution modules from version 2.20120725<br />
<br />
Unpack the files, apply the <tt>policy-f20-contrib.patch</tt> and then installed into:<br />
<pre><br />
./serefpolicy-3.12.1/policy/modules/contrib<br />
</pre><br />
|-<br />
| policy-f20-contrib.patch<br />
| Fedora changes to Reference Policy contribution modules.<br />
<br />
|-<br />
| colspan="2" | Once the above has been completed, run <tt>make conf</tt> from <tt>./serefpolicy-3.12.1 </tt>to initialise the build (it creates two important files in <tt>./serefpolicy-3.12.1/policy/modules/kernel</tt> called <tt>corenetwork.te</tt> and <tt>corenetwork.if</tt>).<br />
<br />
|-<br />
| config.tgz<br />
| Fedora changes to Reference Policy version 2.20120725 application config files.<br />
<br />
These should be unpacked to update the <tt>./serefpolicy-3.12.1/config</tt> versions (some will be added and others updated).<br />
<br />
|-<br />
| permissivedomains.pp<br />
| Contains Fedora domains currently sets to permissive. In <tt>selinux-policy-3.12.1-179.fc20</tt> there are 31 permissive domains. Copy this to <tt>./serefpolicy-3.12.1</tt> as it will then be built into the policy.<br />
<br />
|-<br />
| selinux-policy.conf<br />
| Allows the build process to determine network information.<br />
<br />
Not required for this exercise as the <tt>corenetwork.te</tt> and <tt>corenetwork.if</tt> files have been built.<br />
<br />
|-<br />
| Makefile.devel<br />
| Fedora makefile when using headers. This can replace the <tt>./serefpolicy-3.12.1/support/Makefile.devel</tt><br />
<br />
|-<br />
| booleans.subs_dist<br />
| Common files installed for each policy type. Not required for this exercise.<br />
<br />
|-<br />
| customizable_types<br />
<br />
|-<br />
| file_contexts.subs_dist<br />
<br />
|-<br />
| colspan="2" | <center>'''Used to build "targeted" policy'''</center><br />
<br />
|-<br />
| booleans-targeted.conf<br />
| Replace the <tt>./serefpolicy-3.12.1/policy/booleans.conf</tt> file with this version. <br />
<br />
|-<br />
| modules-targeted-base.conf<br />
| Concatenate both files and copy this to become:<br />
<br />
<tt>./serefpolicy-3.12.1/policy/modules.conf</tt><br />
<br />
|-<br />
| modules-targeted-contrib.conf<br />
<br />
|-<br />
| securetty_types-targeted<br />
| Replace the <tt>./serefpolicy-3.12.1/config/appconfig-mcs/securetty_types</tt> file with this version.<br />
<br />
|-<br />
| setrans-targeted.conf<br />
| Not required for this exercise.<br />
<br />
|-<br />
| users-targeted<br />
| Replace the <tt>./serefpolicy-3.12.1/policy/users</tt> file with this version.<br />
<br />
|-<br />
| colspan="2" | <center>'''Used to build "<tt>minimum</tt>" policy'''</center><br />
<br />
|-<br />
| booleans-minimum.conf<br />
| <br />
<br />
|-<br />
| modules-targeted-base.conf<br />
| Uses the targeted <tt>modules.conf</tt>.<br />
<br />
|-<br />
| modules-targeted-contrib.conf<br />
<br />
|-<br />
| securetty_types-minimum<br />
| <br />
<br />
|-<br />
| setrans-minimum.conf<br />
| <br />
<br />
|-<br />
| users-minimum<br />
| <br />
<br />
|-<br />
| colspan="2" | <center>'''Used to build "<tt>mls</tt>" policy'''</center><br />
<br />
|-<br />
| booleans-mls.conf<br />
| <br />
<br />
|-<br />
| modules-mls-base.conf<br />
| <br />
<br />
|-<br />
| modules-mls-contrib.conf<br />
| <br />
<br />
|-<br />
| securetty_types-mls<br />
| <br />
<br />
|-<br />
| setrans-mls.conf<br />
| <br />
<br />
|-<br />
| users-mls<br />
| <br />
<br />
|}<br />
<br />
<br />
The basic steps are:<br />
* Edit the <tt>build.conf</tt> file to reflect the policy to be built:<br />
<pre><br />
############################################<br />
# Policy build options<br />
#<br />
<br />
# Policy version<br />
# By default, checkpolicy will create the highest version policy it supports. <br />
# Setting this will override the version. This only has an effect for<br />
# monolithic policies.<br />
#OUTPUT_POLICY = 18<br />
<br />
# Policy Type<br />
# standard, mls, mcs. ** Note Red Hat always build the MCS Policy Type<br />
# for their 'targeted' version. **<br />
TYPE = mcs<br />
<br />
# Policy Name<br />
# If set, this will be used as the policy name. Otherwise the policy type <br />
# will be used for the name. ** This entry is also used by the<br />
# 'make install-src' process to copy the source to the:<br />
# /etc/selinux/<NAME>/src/policy directory.**<br />
NAME = targeted-179<br />
<br />
# Distribution<br />
# Some distributions have portions of policy for programs or configurations <br />
# specific to the distribution. Setting this will enable options for the<br />
# distribution. redhat, gentoo, debian, suse, and rhel4 are current options.<br />
# Fedora users should enable ** redhat. **<br />
DISTRO = redhat<br />
<br />
# Unknown Permissions Handling<br />
# The behaviour for handling permissions defined in the kernel but missing<br />
# from the policy. The permissions can either be allowed, denied, or<br />
# the policy loading can be rejected.<br />
# allow, deny, and reject are current options. ** Fedora use allow for all<br />
# policies except MLS that uses 'deny'.**<br />
UNK_PERMS = allow<br />
<br />
# Direct admin init<br />
# Setting this will allow sysadm to directly run init scripts, instead of <br />
# requiring run_init. This is a build option, as role transitions do not<br />
# work in conditional policy.<br />
DIRECT_INITRC = n<br />
<br />
# Build monolithic policy. Putting y here will build a monolithic policy.<br />
MONOLITHIC = n<br />
<br />
# User-based access control (UBAC)<br />
# Enable UBAC for role separations. ** Note Fedora disables UBAC **<br />
UBAC = n<br />
<br />
# Custom build options. This field enables custom build options. Putting<br />
# foo here will enable build option blocks foo. Options should be separated<br />
# by spaces.<br />
CUSTOM_BUILDOPT =<br />
<br />
# Number of MLS Sensitivities<br />
# The sensitivities will be s0 to s(MLS_SENS-1). Dominance will be in<br />
# increasing numerical order with s0 being lowest.<br />
MLS_SENS = 16<br />
<br />
# Number of MLS Categories.<br />
# The categories will be c0 to c(MLS_CATS-1).<br />
MLS_CATS = 1024<br />
<br />
# Number of MCS Categories<br />
# The categories will be c0 to c(MLC_CATS-1).<br />
MCS_CATS = 1024<br />
<br />
# Set this to y to only display status messages during build.<br />
QUIET = n<br />
</pre><br />
<br />
* From <tt>rpmbuild/SOURCES/serefpolicy-3.12.1</tt> run <tt>make install-src</tt> to install source at policy build location.<br />
* Change to the <tt>/etc/selinux/targeted-179/src/policy</tt> directory where the policy has been installed.<br />
* Run <tt>make load</tt> to build the policy, add the modules to the store and install the binary kernel policy plus its supporting configuration files.<br />
: Note that if policy stores have been migrated, the store will default to <tt>/var/lib/selinux/targeted-179</tt>, with the modules in <tt><nowiki>active/modules/400/<module_name></nowiki></tt>, there will also be a CIL version of the module (see [#4.1.1.Policy Store Migration|outline Policy Store Migration] for details).<br />
* Install the <tt>permissivedomains.pp</tt> module as follows (this will set 31 permissive domains that are in the F-20 version of the policy):<br />
<pre><br />
semodule -s targeted-179 -i permissivedomains.pp<br />
</pre><br />
<br />
* The policy should now be built and can be checked using tools such as <tt>'''apol'''(8)</tt> or loaded by editing the <tt>/etc/selinux/config</tt> file, running '<tt>touch /.autorelabel</tt>' and rebooting the system.<br />
<br />
== Reference Policy Headers ==<br />
This method of building policy and adding new modules is used for distributions that do not require access to the source code. <br />
<br />
Note that the Reference Policy header and the Fedora policy header installations are slightly different as described below.<br />
<br />
=== Building and Installing the Header Files ===<br />
To be able to fully build the policy headers from the reference policy source two steps are required:<br />
* Ensure the source is installed and configured as described in the [[#8.4.Installing and Building the Reference Policy Source | Installing and Building the Reference Policy Source]] section. This is because the <tt>make load</tt> (or <tt>make install</tt>) command will package all the modules as defined in the <tt>modules.conf</tt> file, producing a <tt>base.pp</tt> and the relevant <tt>.pp</tt> packages. The build process will then install these in the <tt><nowiki>/usr/share/selinux/<NAME></nowiki></tt> directory.<br />
* Execute the <tt>make install-headers</tt> that will:<br />
** Produce a <tt>build.conf</tt> file that represents the contents of the master <tt>build.conf</tt> file and place it in the <tt><nowiki>/usr/share/selinux/<NAME>/include</nowiki></tt> directory.<br />
** Produce the XML documentation set that reflects the source and place it in the <tt><nowiki>/usr/share/selinux/<NAME>/include</nowiki></tt> directory.<br />
** Copy a development <tt>Makefile</tt> for building from policy headers to the <tt><nowiki>/usr/share/selinux/<NAME>/include</nowiki></tt> directory.<br />
** Copy the support macros <tt>.spt</tt> files to the <tt><nowiki>/usr/share/selinux/<NAME>/include/support</nowiki></tt> directory. This will also include an <tt>all_perms.spt</tt> file that will contain macros to allow all classes and permissions to be resolved.<br />
** Copy the module interface files (<tt>.if</tt>) to the relevant module directories at:<br />
<pre><br />
/usr/share/selinux/<NAME>/include/modules<br />
</pre><br />
<br />
=== Using the Reference Policy Headers ===<br />
Note that this section describes the standard Reference Policy headers, the F-20 installation is slightly different and described in the [[#Using Fedora Supplied Headers | Using Fedora Supplied Headers]] section. <br />
<br />
Once the headers are installed as defined above, new modules can be built in any local directory. An example set of module files are located in the reference policy source at <nowiki>/etc/selinux/<NAME>/src/policy/</nowiki><tt>doc</tt> and are called <tt>example.te</tt>, <tt>example.if</tt>, and <tt>example.fc</tt>.<br />
<br />
During the header build process a <tt>Makefile</tt> was included in the headers directory. This <tt>Makefile</tt> can be used to build the example modules by using makes <tt>-f</tt> option as follows (assuming that the example module files are in the local directory):<br />
<pre><br />
make -f /usr/share/selinux/<NAME>/include/Makefile<br />
</pre><br />
<br />
However there is another <tt>Makefile</tt> that can be installed in the users home directory (<tt>$HOME</tt>) that will call the master <tt>Makefile</tt>. This is located at <nowiki>/etc/selinux/<NAME>/src/policy/</nowiki><tt>doc</tt> in the reference policy source and is called <tt>Makefile.example</tt>. This is shown below (note that it extracts the <tt><nowiki><policy_n</nowiki></tt>NAME <tt>/etc/selinux/config</tt> file):<br />
<pre><br />
AWK ?= gawk<br />
<br />
NAME ?= $(shell $(AWK) -F= '/^SELINUXTYPE/{ print $$2 }' /etc/selinux/config)<br />
SHAREDIR ?= /usr/share/selinux<br />
HEADERDIR := $(SHAREDIR)/$(NAME)/include<br />
<br />
include $(HEADERDIR)/Makefile<br />
</pre><br />
<br />
Table 8 shows the make targets for modules built from headers.<br />
<br />
<center>'''Table 8: Header Policy Build Make Targets'''</center><br />
<br />
{| border="1"<br />
! Make Target<br />
! Comments<br />
<br />
|-<br />
| '''MODULENAME.pp'''<br />
| Compile and package the MODULENAME local module.<br />
<br />
|-<br />
| '''all'''<br />
| Compile and package the modules in the current directory.<br />
<br />
|-<br />
| '''load'''<br />
| Compile and package the modules in the current directory, then insert them into the module store.<br />
<br />
|-<br />
| '''refresh'''<br />
| Attempts to reinsert all modules that are currently in the module store from the local and system module packages.<br />
<br />
|-<br />
| '''xml'''<br />
| Build a policy.xml from the XML included with the base policy headers and any XML in the modules in the current directory.<br />
<br />
|}<br />
<br />
<br />
=== Using Fedora Supplied Headers ===<br />
The F-20 distribution installs the headers in a slightly different manner as Fedora installs:<br />
<br />
* A <tt>modules-base.lst</tt> and <tt>modules-contrib.lst</tt> containing a list of installed modules under <tt><nowiki>/usr/share/selinux/<</nowiki></tt>NAME<tt>></tt>. <br />
* The development header files are installed in the /usr/share/selinux/devel directory. The example modules are also in this directory and the <tt>Makefile</tt> is also slightly different to that used by the Reference Policy source.<br />
* The documentation is installed in the /usr/share/doc/selinux-policy/html directory.<br />
<br />
== Migrating Compiled Modules to CIL ==<br />
As explained in the [[ConfigurationFiles#Policy_Store_Migration | Policy Store Migration]] section, when <tt>libsepol</tt> etc. are upgraded to version 2.4, the policy stores will be migrated to the new location that will contain also contain CIL versions of the policy modules. <br />
<br />
== Reference Policy Support Macros ==<br />
This section explains some of the support macros used to build reference policy source modules (see Table 9 for the list). These macros are located at:<br />
<br />
* <tt>./policy/support</tt> for the reference policy source.<br />
* <tt><nowiki>/usr/share/selinux/<</nowiki></tt>NAME<tt>>/include/support</tt> for Reference Policy installed header files.<br />
* /usr/share/selinux/devel/support for Fedora installed header files.<br />
<br />
The following support macro file contents are explained:<br />
: <tt>loadable_module.spt</tt> - Loadable module support.<br />
: <tt>misc_macros.spt</tt> - Generate users, bools and security contexts.<br />
: <tt>mls_mcs_macros.spt</tt> - MLS / MCS support.<br />
: <tt>file_patterns.spt</tt> - Sets up allow rules via parameters for files and directories.<br />
: <tt>ipc_patterns.spt</tt> - Sets up allow rules via parameters for Unix domain sockets.<br />
: <tt>misc_patterns.spt</tt> - Domain and process transitions.<br />
: <tt>obj_perm_sets.spt</tt> - Object classes and permissions.<br />
<br />
When the header files are installed the <tt>all_perms.spt</tt> support macro file is also installed that describes all classes and permissions configured in the original source policy.<br />
<br />
<center>'''Table 9: Support Macros described in this section'''</center><br />
{| border="1"<br />
| '''Macro Name'''<br />
| '''Function'''<br />
| '''Macro file name'''<br />
<br />
|-<br />
| policy_module<br />
| For adding the module statement and mandatory <tt>require</tt> block entries.<br />
| loadable_module.spt<br />
<br />
|-<br />
| gen_require<br />
| For use in interfaces to optionally insert a <tt>require</tt> block<br />
<br />
|-<br />
| template<br />
| Generate <tt>template</tt> interface block<br />
<br />
|-<br />
| interface<br />
| Generate the access <tt>interface</tt> block<br />
<br />
|-<br />
| optional_policy<br />
| Optional policy handling <br />
<br />
|-<br />
| gen_tunable<br />
| Tunable declaration<br />
<br />
|-<br />
| tunable_policy<br />
| Tunable policy handling<br />
<br />
|-<br />
| gen_user<br />
| Generate an SELinux user<br />
| misc_macros.spt<br />
<br />
<br />
<br />
<br />
|-<br />
| gen_context<br />
| Generate a security context<br />
<br />
|-<br />
| gen_bool<br />
| Generate a boolean<br />
<br />
|-<br />
| gen_cats<br />
| Declares categories <tt>c0</tt> to <tt>c(N-1)</tt><br />
| mls_mcs_macros.spt<br />
<br />
<br />
<br />
<br />
|-<br />
| gen_sens<br />
| Declares sensitivities <tt>s0</tt> to <tt>s(N-1)</tt> with dominance in increasing numeric order with <tt>s0</tt> lowest, <tt>s(N-1)</tt> highest.<br />
<br />
|-<br />
| gen_levels<br />
| Generate levels from <tt>s0</tt> to <tt>(N-1)</tt> with categories <tt>c0</tt> to <tt>(M-1)</tt><br />
<br />
|-<br />
| mls_systemlow<br />
| Basic level names for system low and high<br />
<br />
|-<br />
| mls_systemhigh<br />
<br />
|-<br />
| mcs_systemlow<br />
<br />
|-<br />
| mcs_systemhigh<br />
<br />
|-<br />
| mcs_allcats<br />
| Allocates all categories<br />
<br />
|}<br />
<br />
<br />
Notes:<br />
* The macro calls can be in any configuration file read by the build process and can be found in (for example) the <tt>users</tt>, <tt>mls</tt>, <tt>mcs</tt> and <tt>constraints</tt> files.<br />
* There are four main m4 <tt>ifdef</tt> parameters used within modules:<br />
** <tt>enable_mcs</tt> - this is used to test if the MCS policy is being built.<br />
** <tt>enable_mls</tt> - this is used to test if the MLS policy is being built.<br />
** <tt>enable_ubac</tt> - this enables the user based access control within the <tt>constraints</tt> file.<br />
** <tt>hide_broken_symptoms</tt> - this is used to hide errors in modules with <tt>dontaudit</tt> rules. <br />
:: These are also mentioned in Table 20 as they are set by the initial build process with examples shown in the [[#ifdef / ifndef Parameters | ifdef / ifndef Parameters]] section.<br />
* The macro examples in this section have been taken from the reference policy module files and shown in each relevant "'''Example Macro'''" section. The macros are then expanded by the build process to form modules containing the policy language statements and rules in the <tt>tmp</tt> directory. These files have been extracted and modified for readability, then shown in each relevant "'''Expanded Macro'''" section. <br />
* An example policy that has had macros expanded is shown in the [[#Module Expansion Process | Module Expansion Process]] section.<br />
* Be aware that spaces between macro names and their parameters are not allowed:<br />
** Correct:<br />
<pre><br />
policy_module(ftp, 1.7.0)<br />
</pre><br />
** Incorrect:<br />
<pre><br />
policy_module (ftp, 1.7.0)<br />
</pre><br />
<br />
=== Loadable Policy Macros ===<br />
The loadable policy module support macros are located in the <tt>loadable_module.spt</tt> file.<br />
<br />
==== policy_module Macro ====<br />
This macro will add the [[PolicyStatements#module | module]] statement to a loadable module, and automatically add a [[PolicyStatements#require | require]] statement with pre-defined information for all loadable modules such as the system_r role, kernel classes and permissions, and optionally MCS / MLS information (<tt>sensitivity</tt> and <tt>category</tt> statements).<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
policy_module(module_name,version)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| policy_module<br />
| The policy_module macro keyword.<br />
<br />
|-<br />
| module_name<br />
| The module identifier that must be unique in the module layers.<br />
<br />
|-<br />
| version_number<br />
| The module version number in M.m.m format (where M = major version number and m = minor version numbers).<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the modules/services/ftp.te module:<br />
#<br />
policy_module(ftp, 1.7.0)<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This is the expanded macro from the tmp/ftp.tmp file:<br />
#<br />
module ftp 1.7.0;<br />
require {<br />
role system_r;<br />
class security {compute_av compute_create .... };<br />
....<br />
class capability2 (mac_override mac_admin };<br />
<br />
# If MLS or MCS configured then the:<br />
sensitivity s0;<br />
....<br />
category c0;<br />
....<br />
}<br />
</pre><br />
<br />
==== gen_require Macro ====<br />
For use within module files to insert a <tt>require</tt> block.<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
gen_require(`require_statements`)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| gen_require<br />
| The gen_require macro keyword.<br />
<br />
|-<br />
| require_statements<br />
| These statements consist of those allowed in the policy language [[PolicyStatements#require | require]] statement.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the modules/services/ftp.te module:<br />
#<br />
gen_require(`type ftp_script_exec_t;')<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This is the expanded macro from the tmp/ftp.tmp file:<br />
#<br />
require {<br />
type ftp_script_exec_t; <br />
}<br />
</pre><br />
<br />
==== optional_policy Macro ====<br />
For use within module files to insert an <tt>optional</tt> block that will be expanded by the build process only if the modules containing the access or template interface calls that follow are present. If one module is present and the other is not, then the optional statements are not included (need to check).<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
optional_policy(`optional_statements`)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| optional_policy<br />
| The optional_policy macro keyword.<br />
<br />
|-<br />
| optional_statements<br />
| These statements consist of those allowed in the policy language [[PolicyStatements#optional | optional]] statement. However they can also be [[#interface Macro | interface template]], or support macro calls.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the modules/services/ftp.te module and <br />
# shows the optional_policy macro with two levels.<br />
#<br />
optional_policy(`<br />
corecmd_exec_shell(ftpd_t)<br />
files_read_usr_files(ftpd_t)<br />
cron_system_entry(ftpd_t, ftpd_exec_t)<br />
<br />
optional_policy(`<br />
logrotate_exec(ftpd_t)<br />
')<br />
')<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This is the expanded macro from the tmp/ftp.tmp file showing<br />
# the policy language statements with both optional levels expanded.<br />
#<br />
##### Start optional_policy - Level 1 ###########<br />
optional {<br />
##### begin corecmd_exec_shell(ftpd_t)<br />
require {<br />
type bin_t, shell_exec_t;<br />
} # end require<br />
allow ftpd_t bin_t:dir { getattr search };<br />
allow ftpd_t bin_t:dir { getattr search read lock ioctl };<br />
allow ftpd_t bin_t:dir { getattr search };<br />
allow ftpd_t bin_t:lnk_file { getattr read };<br />
allow ftpd_t shell_exec_t:file { { getattr read execute ioctl } ioctl lock execute_no_trans };<br />
##### end corecmd_exec_shell(ftpd_t)<br />
<br />
##### begin files_read_usr_files(ftpd_t)<br />
require {<br />
type usr_t;<br />
} # end require<br />
allow ftpd_t usr_t:dir { getattr search read lock ioctl };<br />
allow ftpd_t usr_t:dir { getattr search };<br />
allow ftpd_t usr_t:file { getattr read lock ioctl };<br />
allow ftpd_t usr_t:dir { getattr search };<br />
allow ftpd_t usr_t:lnk_file { getattr read };<br />
##### end files_read_usr_files(ftpd_t)<br />
<br />
##### begin cron_system_entry(ftpd_t,ftpd_exec_t)<br />
require {<br />
type crond_t, system_crond_t;<br />
} # end require<br />
allow system_crond_t ftpd_exec_t:file { getattr read execute };<br />
allow system_crond_t ftpd_t:process transition;<br />
dontaudit system_crond_t ftpd_t:process { noatsecure siginh rlimitinh };<br />
type_transition system_crond_t ftpd_exec_t:process ftpd_t;<br />
# cjp: perhaps these four rules from the old<br />
# domain_auto_trans are not needed?<br />
allow ftpd_t system_crond_t:fd use;<br />
allow ftpd_t system_crond_t:fifo_file { getattr read write append ioctl lock };<br />
allow ftpd_t system_crond_t:process sigchld;<br />
allow ftpd_t crond_t:fifo_file { getattr read write append ioctl lock };<br />
allow ftpd_t crond_t:fd use;<br />
allow ftpd_t crond_t:process sigchld;<br />
role system_r types ftpd_t;<br />
##### end cron_system_entry(ftpd_t,ftpd_exec_t)<br />
<br />
##### Start optional_policy - Level 2 ##########<br />
optional {<br />
##### begin logrotate_exec(ftpd_t)<br />
require {<br />
type logrotate_exec_t;<br />
} # end require<br />
allow ftpd_t logrotate_exec_t:file { { getattr read execute ioctl } ioctl lock execute_no_trans };<br />
##### end logrotate_exec(ftpd_t)<br />
} # end optional 2nd level<br />
<br />
} # end optional 1st level<br />
</pre><br />
<br />
==== gen_tunable Macro ====<br />
This macro defines booleans that are global in scope. The corresponding [[#tunable_policy Macro | tunable_policy]] macro contains the supporting statements allowed or not depending on the value of the boolean. These entries are extracted as a part of the build process (by the <tt>make conf</tt> target) and added to the <tt>global_tunables</tt> file where they can then be used to alter the default values for the <tt>make load</tt> or <tt>make install</tt> targets.<br />
<br />
Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[#Reference Policy Documentation | documentation]].<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
gen_tunable(boolean_name,boolean_value)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| gen_tunable<br />
| The gen_tunable macro keyword.<br />
<br />
|-<br />
| boolean_name<br />
| The <tt>boolean</tt> identifier.<br />
<br />
|-<br />
| boolean_value<br />
| The <tt>boolean</tt> value that can be either <tt>true</tt> or <tt>false</tt>.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the modules/services/ftp.te module:<br />
#<br />
<br />
## <desc><br />
## <p><br />
## Allow ftp servers to use nfs<br />
## for public file transfer services.<br />
## </p><br />
## </desc><br />
gen_tunable(allow_ftpd_use_nfs, false)<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This is the expanded macro from the tmp/ftp.tmp file:<br />
#<br />
bool allow_ftpd_use_nfs false;<br />
</pre><br />
<br />
==== tunable_policy Macro ====<br />
This macro contains the statements allowed or not depending on the value of the boolean defined by the [[#gen_tunable Macro | gen_tunable]] macro. <br />
<br />
'''The macro definition is:'''<br />
<pre><br />
tunable_policy(`gen_tunable_id',`tunable_policy_rules`)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| tunable_policy<br />
| The tunable_policy macro keyword.<br />
<br />
|-<br />
| gen_tunable_id<br />
| This is the boolean identifier defined by the <tt>gen_tunable</tt> macro. It is possible to have multiple entries separated by <tt>&&</tt> or <tt>||</tt> as shown in the example.<br />
<br />
|-<br />
| tunable_policy_rules<br />
| These are the policy rules and statements as defined in the [[ConditionalStatements | if]] statement policy language section.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the modules/services/ftp.te module<br />
# showing the use of the boolean with the && operator.<br />
#<br />
tunable_policy(`allow_ftpd_use_nfs && allow_ftpd_anon_write',`<br />
fs_manage_nfs_files(ftpd_t)<br />
')<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This is the expanded macro from the tmp/ftp.tmp file.<br />
#<br />
if (allow_ftpd_use_nfs && allow_ftpd_anon_write) {<br />
<br />
##### begin fs_manage_nfs_files(ftpd_t)<br />
require {<br />
type nfs_t;<br />
} # end require<br />
<br />
allow ftpd_t nfs_t:dir { read getattr lock search ioctl add_name remove_name write };<br />
allow ftpd_t nfs_t:file { create open getattr setattr read write append rename link unlink ioctl lock };<br />
##### end fs_manage_nfs_files(ftpd_t)<br />
<br />
} # end if<br />
</pre><br />
<br />
==== interface Macro ====<br />
Access interface macros are defined in the interface module file (<tt>.if</tt>) and form the interface through which other modules can call on the modules services (as described in the [[#Module Expansion | Module Expansion]] section.<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
interface(`name`,`interface_rules`)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| interface<br />
| The <tt>interface</tt> macro keyword.<br />
<br />
|-<br />
| name<br />
| The <tt>interface</tt> identifier that should be named to reflect the module identifier and its purpose.<br />
<br />
|-<br />
| interface_rules<br />
| This can consist of the support macros, policy language statements or other <tt>interface</tt> calls as required to provide the service.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Interface Definition:'''<br />
<br />
Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[#Reference Policy Documentation | documentation]].<br />
<br />
<pre><br />
# This example is from the modules/services/ftp.if module<br />
# showing the 'ftp_read_config' interface.<br />
#<br />
<br />
########################################<br />
## <summary><br />
## Read ftpd etc files<br />
## </summary><br />
## <param name="domain"><br />
##<summary><br />
## Domain allowed access.<br />
##</summary><br />
## </param><br />
#<br />
interface(`ftp_read_config',`<br />
gen_require(`<br />
type ftpd_etc_t;<br />
')<br />
<br />
files_search_etc($1)<br />
allow $1 ftpd_etc_t:file { getattr read };<br />
')<br />
</pre><br />
<br />
'''Expanded Macro: (taken from the <tt>base.conf</tt> file):'''<br />
<pre><br />
# Access Interfaces are only expanded at policy compile time <br />
# if they are called by a module that requires their services.<br />
#<br />
# In this example the ftp_read_config interface is called from<br />
# the init.te module via the optional_policy macro as shown<br />
# below with the expanded code shown afterwards.<br />
#<br />
######## From ./policy/policy/modules/system/init.te ########<br />
#<br />
# optional_policy(`<br />
# ftp_read_config(initrc_t)<br />
# ')<br />
#<br />
#<br />
############# Expanded policy statements taken ##############<br />
############# from the base.conf file that ##################<br />
############# forms the base policy. ########################<br />
#<br />
optional { # Start optional_policy segment for ftp interface<br />
#<br />
# This is the resulting output contained the base.conf file<br />
# where init calls the ftp_read_config ($1) interface from<br />
# init.te with the parameter initrc_t:<br />
#<br />
require {<br />
type ftpd_etc_t;<br />
} <br />
<br />
#<br />
# Call the files_search_etc ($1) interface contained in the <br />
# ftp.if file with the parameter initrc_t:<br />
#<br />
require {<br />
type etc_t;<br />
} <br />
allow initrc_t etc_t:dir { getattr search };<br />
#<br />
# end files_search_etc(initrc_t)<br />
#<br />
# This is the allow $1 ftpd_etc_t:file { getattr read };<br />
# statement with the initrc_t parameter resolved: <br />
#<br />
allow initrc_t ftpd_etc_t:file { getattr read };<br />
#<br />
# end ftp_read_config(initrc_t)<br />
} # End optional_policy segment for this ftp interface<br />
</pre><br />
<br />
==== template Macro ====<br />
A template interface is used to help create a domain and set up the appropriate rules and statements to run an application / process. The basic idea is to set up an application in a domain that is suitable for the defined SELinux user and role to access but not others. Should a different user / role need to access the same application, another domain would be allocated (these are known as 'derived domains' as the domain name is derived from caller information). <br />
<br />
The application template shown in the example below is for <tt>openoffice.org</tt> where the domain being set up to run the application is based on the SELinux user <tt>xguest</tt> (parameter <tt>$1</tt>) therefore a domain type is initialised called <tt>xguest_openoffice_t</tt>, this is then added to the user domain attribute xguest_usertype (parameter <tt>$2</tt>). Finally the role <tt>xguest_r</tt> (parameter <tt>$3</tt>) is allowed access to the domain type <tt>xguest_openoffice_t</tt>. If a different user / role required access to openoffice.org, then by passing different parameters (i.e. <tt>user_u</tt>), a different domain would be set up.<br />
<br />
The main differences between an application interface and a template interface are:<br />
<br />
* An access interface is called by other modules to perform a service.<br />
* A template interface allows an application to be run in a domain based on user / role information to isolate different instances.<br />
<br />
Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[#Reference Policy Documentation | documentation]].<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
template(`name`,`template_rules`)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| template<br />
| The <tt>template</tt> macro keyword.<br />
<br />
|-<br />
| name<br />
| The <tt>template</tt> identifier that should be named to reflect the module identifier and its purpose. By convention the last component is <tt>_template</tt> (e.g. <tt>ftp_per_role_template</tt>).<br />
<br />
|-<br />
| <tt>template</tt>_rules<br />
| This can consist of the support macros, policy language statements or <tt>interface</tt> calls as required to provide the service.<br />
<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the modules/apps/openoffice.if module<br />
# showing the 'openoffice_per_role_template' template interface.<br />
#<br />
#######################################<br />
## <summary><br />
##The per role template for the openoffice module.<br />
## </summary><br />
## <desc><br />
##<p><br />
##This template creates a derived domains which are used<br />
##for openoffice applications.<br />
##</p><br />
## </desc><br />
## <param name="userdomain_prefix"><br />
##<summary><br />
##The prefix of the user domain (e.g., user<br />
##is the prefix for user_t).<br />
##</summary><br />
## </param><br />
## <param name="user_domain"><br />
##<summary><br />
##The type of the user domain.<br />
##</summary><br />
## </param><br />
## <param name="user_role"><br />
##<summary><br />
##The role associated with the user domain.<br />
##</summary><br />
## </param><br />
#<br />
template(`openoffice_per_role_template',`<br />
gen_require(`<br />
type openoffice_exec_t;<br />
')<br />
<br />
type $1_openoffice_t;<br />
domain_type($1_openoffice_t)<br />
domain_entry_file($1_openoffice_t, openoffice_exec_t)<br />
role $3 types $1_openoffice_t;<br />
<br />
domain_interactive_fd($1_openoffice_t)<br />
<br />
userdom_unpriv_usertype($1, $1_openoffice_t)<br />
userdom_exec_user_home_content_files($1, $1_openoffice_t)<br />
<br />
allow $1_openoffice_t self:process { getsched sigkill execheap execmem execstack };<br />
<br />
allow $2 $1_openoffice_t:process { getattr ptrace signal_perms noatsecure siginh rlimitinh };<br />
allow $1_openoffice_t $2:tcp_socket { read write };<br />
<br />
domtrans_pattern($2, openoffice_exec_t, $1_openoffice_t)<br />
<br />
dev_read_urand($1_openoffice_t)<br />
dev_read_rand($1_openoffice_t)<br />
<br />
fs_dontaudit_rw_tmpfs_files($1_openoffice_t)<br />
<br />
allow $2 $1_openoffice_t:process { signal sigkill };<br />
allow $1_openoffice_t $2:unix_stream_socket connectto;<br />
<br />
')<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# Template Interfaces are only expanded at policy compile time <br />
# if they are called by a module that requires their services.<br />
# This has been expanded as a part of the roles/xguest.te<br />
# module and extracted from tmp/xguest.tmp.<br />
#<br />
################# '''START Expanded code segment''' ###########<br />
#<br />
optional {<br />
##### begin openoffice_per_role_template(xguest,xguest_usertype,xguest_r)<br />
require {<br />
type openoffice_exec_t;<br />
} # end require<br />
type xguest_openoffice_t; # Paremeter $1<br />
<br />
......<br />
# This is a long set of rules, therefore has been cut down.<br />
......<br />
....<br />
typeattribute xguest_openoffice_t xguest_usertype; # Paremeter $2<br />
..<br />
type_transition xguest_usertype openoffice_exec_t:process xguest_openoffice_t; <br />
..<br />
role xguest_r types xguest_openoffice_t; # Paremeter $3<br />
....<br />
allow xguest_usertype xguest_openoffice_t:process { signal sigkill };<br />
allow xguest_openoffice_t xguest_usertype:unix_stream_socket connectto;<br />
##### end openoffice_per_role_template(xguest,xguest_usertype,xguest_r)<br />
} # end optional<br />
</pre><br />
<br />
=== Miscellaneous Macros ===<br />
These macros are in the <tt>misc_macros.spt</tt> file.<br />
<br />
==== gen_context Macro ====<br />
This macro is used to generate a valid security context and can be used in any of the module files. Its most general use is in the <tt>.fc</tt> file where it is used to set the files security context.<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
gen_context(context[,mls | mcs]) <br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| gen_context<br />
| The <tt>gen_context</tt> macro keyword.<br />
<br />
|-<br />
| context<br />
| The security context to be generated. This can include macros that are relevant to a context as shown in the example below.<br />
<br />
|-<br />
| mls | mcs<br />
| MLS or MCS labels if enabled in the policy.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example shows gen_context being used to generate a<br />
# security context for the security initial sid in the <br />
# selinux.te module:<br />
<br />
sid security gen_context(system_u:object_r:security_t:mls_systemhigh)<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This is the expanded entry built into the base.conf source<br />
# file for an MLS policy:<br />
<br />
sid security system_u:object_r:security_t:s15:c0.c255 <br />
</pre><br />
<br />
'''Example File Context <tt>.fc</tt> file:'''<br />
<pre><br />
# This is from the modules/apps/gnome.fc file. Note that the<br />
# HOME_DIR and USER parameters will be entered during<br />
# the contexts/file_contexts.homedirs file.<br />
#<br />
<br />
HOME_DIR/.gnome2(/.*)?gen_context(system_u:object_r:gnome_home_t,s0)<br />
HOME_DIR/\.config/gtk-.*gen_context(system_u:object_r:gnome_home_t,s0)<br />
HOME_DIR/\.gconf(d)?(/.*)?gen_context(system_u:object_r:gconf_home_t,s0)<br />
HOME_DIR/\.local.*gen_context(system_u:object_r:gconf_home_t,s0)<br />
<br />
/tmp/gconfd-USER/.*--gen_context(system_u:object_r:gconf_tmp_t,s0)<br />
<br />
HOME_DIR/.pulse(/.*)?gen_context(system_u:object_r:gnome_home_t,s0)<br />
</pre><br />
<br />
'''Expanded File Context <tt>.fc</tt> file:'''<br />
<pre><br />
# The resulting expanded tmp/gnome.mod.fc file. This will be<br />
# concatenated with the main file_contexts file during the<br />
# policy build process.<br />
#<br />
<br />
HOME_DIR/.gnome2(/.*)?system_u:object_r:gnome_home_t:s0<br />
HOME_DIR/\.config/gtk-.*system_u:object_r:gnome_home_t:s0<br />
HOME_DIR/\.gconf(d)?(/.*)?system_u:object_r:gconf_home_t:s0<br />
HOME_DIR/\.local.*system_u:object_r:gconf_home_t:s0<br />
<br />
/tmp/gconfd-USER/.*--system_u:object_r:gconf_tmp_t:s0<br />
<br />
HOME_DIR/.pulse(/.*)?system_u:object_r:gnome_home_t:s0<br />
</pre><br />
<br />
==== gen_user Macro ====<br />
This macro is used to generate a valid [[User Statements | user]] statement and add an entry in the [[PolicyStoreConfigurationFiles#modules_active_users_extra._users_extra.local_and_users.local_Files | users_extra]] configuration file if it exists.<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
gen_user(username, prefix, role_set, mls_defaultlevel, mls_range, [mcs_categories])<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| gen_user<br />
| The <tt>gen_user</tt> macro keyword.<br />
<br />
|-<br />
| username<br />
| The SELinux user id.<br />
<br />
|-<br />
| prefix<br />
| SELinux users without the prefix will not be in the <tt>users_extra</tt> file. This is added to user directories by the <tt>genhomedircon</tt> as discussed in the [[PolicyStoreConfigurationFiles#modules_active_file_contexts.template_File | modules/active/file_contexts.template]] file section.<br />
<br />
|-<br />
| role_set<br />
| The user roles.<br />
<br />
|-<br />
| mls_defaultlevel<br />
| The default level if MLS / MCS policy.<br />
<br />
|-<br />
| mls_range<br />
| The range if MLS / MCS policy.<br />
<br />
|-<br />
| mcs_categories<br />
| The categories if MLS / MCS policy.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example has been taken from the policy/policy/users file:<br />
#<br />
<br />
gen_user(root, user, unconfined_r sysadm_r staff_r ifdef(`enable_mls',`secadm_r auditadm_r') system_r, s0, s0 - mls_systemhigh, mcs_allcats) <br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# The expanded gen_user macro from the base.conf for an MLS<br />
# build. Note that the prefix is not present. This is added to<br />
# the users_extra file as shown below.<br />
#<br />
user root roles { unconfined_r sysadm_r staff_r secadm_r auditadm_r system_r } level s0 range s0 - s15:c0.c1023; <br />
<br />
# users_extra file entry:<br />
#<br />
user root prefix user; <br />
</pre><br />
<br />
==== gen_bool Macro ====<br />
This macro defines a boolean and requires the following steps:<br />
# Declare the [[ConditionalStatements | boolean]] in the [[#Booleans, Global Booleans and Tunable Booleans | global_booleans]] file.<br />
# Use the boolean in the module files with an if / else statement as shown in the example.<br />
<br />
Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[#Reference Policy Documentation | documentation]].<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
gen_bool(name,default_value) <br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| gen_bool<br />
| The <tt>gen_bool</tt> macro keyword.<br />
<br />
|-<br />
| name<br />
| The boolean identifier.<br />
<br />
|-<br />
| default_value<br />
| The value <tt>true</tt> or <tt>false</tt>.<br />
<br />
|}<br />
<br />
<br />
The macro is only valid in the'''global_booleans'''file but the boolean declared can be used in the following module types:<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro (in global_booleans):'''<br />
<pre><br />
# This example is from the global_booleans file where the bool<br />
# is declared. The comments must be present as it is used to<br />
# generate the documentation.<br />
#<br />
<br />
## <desc><br />
## <p><br />
## Disable transitions to insmod.<br />
## </p><br />
## </desc><br />
gen_bool(secure_mode_insmod,false)<br />
</pre><br />
<pre><br />
# Example usage from the system/modutils.te module:<br />
#<br />
if( ! secure_mode_insmod ) {<br />
kernel_domtrans_to(insmod_t,insmod_exec_t)<br />
}<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This has been taken from the base.conf source file after<br />
# expansion by the build process of the modutils.te module.<br />
#<br />
<br />
if( ! secure_mode_insmod ) {<br />
##### begin kernel_domtrans_to(insmod_t,insmod_exec_t)<br />
allow kernel_t insmod_exec_t:file { getattr read execute };<br />
allow kernel_t insmod_t:process transition;<br />
dontaudit kernel_t insmod_t:process { noatsecure siginh rlimitinh };<br />
type_transition kernel_t insmod_exec_t:process insmod_t;<br />
allow insmod_t kernel_t:fd use;<br />
allow insmod_t kernel_t:fifo_file { getattr read write append ioctl lock };<br />
allow insmod_t kernel_t:process sigchld;<br />
##### end kernel_domtrans_to(insmod_t,insmod_exec_t)<br />
}<br />
</pre><br />
<br />
=== MLS and MCS Macros ===<br />
These macros are in the <tt>mls_mcs_macros.spt</tt> file.<br />
<br />
==== gen_cats Macro ====<br />
This macro will generate a [[MLSStatements#category | category]] statement for each category defined. These are then used in the <tt>base.conf</tt> / <tt>policy.conf</tt> source file and also inserted into each module by the [[#policy_module Macro | policy_module]] Macro. The <tt>policy/policy/mcs</tt> and <tt>mls</tt> configuration files are the only files that contain this macro in the current reference policy.<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
gen_cats(mcs_num_cats | mls_num_cats)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| gen_cats<br />
| The <tt>gen_cats</tt> macro keyword.<br />
<br />
|-<br />
| mcs_num_cats<br />
<br />
mls_num_cats<br />
| These are the maximum number of categories that have been extracted from the <tt>build.conf</tt> file <tt>MCS_CATS</tt> or <tt>MLS_CATS</tt> entries and set as m4 parameters.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''na'''</center><br />
| <center>'''na'''</center><br />
| <center>'''na'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the policy/policy/mls configuration file.<br />
#<br />
<br />
gen_cats(mls_num_cats)<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This example has been extracted from the base.conf source file.<br />
<br />
category c0;<br />
category c1;<br />
...<br />
category c1023;<br />
</pre><br />
<br />
==== gen_sens Macro ====<br />
This macro will generate a [[MLSStatements#sensitivity | sensitivity]] statement for each sensitivity defined. These are then used in the <tt>base.conf</tt> / <tt>policy.conf</tt> source file and also inserted into each module by the [[#policy_module Macro | policy_module]] Macro. The <tt>policy/policy/mcs</tt> and <tt>mls</tt> configuration files are the only files that contain this macro in the current reference policy (note that the <tt>mcs</tt> file has <tt>gen_sens(1)</tt> as only one sensitivity is required).<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
gen_sens(mls_num_sens)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| gen_sens<br />
| The <tt>gen_sens</tt> macro keyword.<br />
<br />
|-<br />
| mls_num_sens<br />
| These are the maximum number of sensitivities that have been extracted from the <tt>build.conf</tt> file <tt>MLS_SENS</tt> entries and set as an m4 parameter.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''na'''</center><br />
| <center>'''na'''</center><br />
| <center>'''na'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the policy/policy/mls configuration file.<br />
#<br />
<br />
gen_cats(mls_num_sens)<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This example has been extracted from the base.conf source file.<br />
<br />
sensitivity s0;<br />
sensitivity s1;<br />
...<br />
sensitivity s15;<br />
</pre><br />
<br />
==== gen_levels Macro ====<br />
This macro will generate a [[MLSStatements#level | level]] statement for each level defined. These are then used in the <tt>base.conf</tt> / <tt>policy.conf</tt> source file. The <tt>policy/policy/mcs</tt> and <tt>mls</tt> configuration files are the only files that contain this macro in the current reference policy.<br />
<br />
'''The macro definition is:'''<br />
<pre><br />
gen_levels(mls_num_sens,mls_num_cats)<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| gen_levels<br />
| The <tt>gen_levels</tt> macro keyword.<br />
<br />
|-<br />
| mls_num_sens<br />
| This is the parameter that defines the number of sensitivities to generate. The MCS policy is set to '<tt>1</tt>'.<br />
<br />
|-<br />
| mls_num_cats<br />
<br />
mcs_num_cats<br />
| This is the parameter that defines the number of categories to generate.<br />
<br />
|}<br />
<br />
<br />
'''The macro is valid in:'''<br />
<br />
{| border="1"<br />
| <center>Private Policy File (.te)</center><br />
| <center>External Interface File (.if)</center><br />
| <center>File Labeling Policy File (.fc)</center><br />
<br />
|-<br />
| <center>'''na'''</center><br />
| <center>'''na'''</center><br />
| <center>'''na'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the policy/policy/mls configuration file.<br />
#<br />
gen_levels(mls_num_sens,mls_num_cats)<br />
</pre><br />
<br />
'''Expanded Macro:'''<br />
<pre><br />
# This example has been extracted from the base.conf source<br />
# file. Note that the all categories are allocated to each<br />
# sensitivity.<br />
<br />
level s0:c0.c1023; <br />
level s1:c0.c1023; <br />
...<br />
level s15:c0.c1023; <br />
</pre><br />
<br />
==== System High/Low Parameters ====<br />
These macros define system high etc. as shown.<br />
<pre><br />
mls_systemlow<br />
# gives:<br />
s0<br />
<br />
mls_systemhigh<br />
# gives:<br />
s15:c0.c1023 <br />
<br />
mcs_systemlow<br />
# gives:<br />
s0<br />
<br />
mcs_systemhigh<br />
# gives:<br />
s0:c0.c1023<br />
<br />
mcs_allcats<br />
# gives:<br />
c0.c1023<br />
</pre><br />
<br />
=== ifdef / ifndef Parameters ===<br />
This section contains examples of the common <tt>ifdef</tt> / <tt>ifndef</tt> parameters that can be used in module source files. <br />
<br />
==== hide_broken_symptoms ====<br />
This is used within modules as shown in the example. The parameter is set up by the <tt>Makefile</tt> at the start of the build process.<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the modules/kernel/domain.te module.<br />
#<br />
ifdef(`hide_broken_symptoms',`<br />
cron_dontaudit_rw_tcp_sockets(domain)<br />
allow domain domain:key { link search };<br />
')<br />
</pre><br />
<br />
==== enable_mls and enable_mcs ====<br />
These are used within modules as shown in the example. The parameters are set up by the <tt>Makefile</tt> with information taken from the <tt>build.conf</tt> file at the start of the build process.<br />
<br />
'''Example Macros:'''<br />
<pre><br />
# This example is from the modules/kernel/kernel.te module.<br />
#<br />
ifdef(`enable_mls',`<br />
role secadm_r;<br />
role auditadm_r;<br />
')<br />
</pre><br />
<pre><br />
# This example is from the modules/kernel/kernel.if module.<br />
#<br />
ifdef(`enable_mcs',`<br />
range_transition kernel_t $2:process $3;<br />
')<br />
<br />
ifdef(`enable_mls',`<br />
range_transition kernel_t $2:process $3;<br />
mls_rangetrans_target($1)<br />
')<br />
</pre><br />
<br />
==== enable_ubac ====<br />
This is used within the <tt>./policy/constraints</tt> configuration file to set up various attributes to support user based access control (UBAC). These attributes are then used within the various modules that want to support UBAC. This support was added in version 2 of the Reference Policy. <br />
<br />
The parameter is set up by the <tt>Makefile</tt> with information taken from the <tt>build.conf</tt> file at the start of the build process (<tt>ubac = y | ubac = n</tt>).<br />
<br />
'''Example Macro:'''<br />
<pre><br />
# This example is from the ./policy/constraints file.<br />
# Note that the ubac_constrained_type attribute is defined in<br />
# modules/kernel/ubac.te module.<br />
<br />
define(`basic_ubac_conditions',`<br />
ifdef(`enable_ubac',`<br />
u1 == u2<br />
or u1 == system_u<br />
or u2 == system_u<br />
or t1 != ubac_constrained_type<br />
or t2 != ubac_constrained_type<br />
')<br />
')<br />
</pre><br />
<br />
==== direct_sysadm_daemon ====<br />
This is used within modules as shown in the example. The parameter is set up by the <tt>Makefile</tt> with information taken from the <tt>build.conf</tt> file at the start of the build process (if <tt>DIRECT_INITRC = y</tt>).<br />
<br />
'''Example Macros:'''<br />
<pre><br />
# This example is from the modules/system/selinuxutil.te module.<br />
#<br />
ifndef(`direct_sysadm_daemon',`<br />
ifdef(`distro_gentoo',`<br />
# Gentoo integrated run_init:<br />
init_script_file_entry_type(run_init_t)<br />
')<br />
')<br />
</pre><br />
<pre><br />
# This example is from the modules/system/userdomain.te module.<br />
#<br />
ifdef(`direct_sysadm_daemon',`<br />
domain_system_change_exemption($1_t)<br />
')<br />
</pre><br />
<br />
== Module Expansion Process ==<br />
The objective of this section is to show how the modules are expanded by the reference policy build process to form files that can then be compiled and then loaded into the policy store by using the <tt>make MODULENAME.pp</tt> target.<br />
<br />
The files shown are those produced by the build process using the ada policy modules from the Reference Policy source tree (<tt>ada.te</tt>, <tt>ada.if</tt> and <tt>ada.fc</tt>) that are shown in the [[#Reference Policy Module Files | Reference Policy Module Files]] section.<br />
<br />
The initial build process will build the source text files in the <tt>policy/tmp</tt> directory as <tt>ada.tmp</tt> and <tt>ada.mod.fc</tt> (that are basically build equivalent <tt>ada.conf</tt> and <tt>ada.fc</tt> formatted files). The basic steps are shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/28-mod-expand-1.png The <tt>make ada</tt> sequence of events] diagram, and the resulting expanded code shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/29-mod-expand-2.png The expansion process] diagram.<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[XENStatements | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_Imp_SELinux-aware_Apps | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XpermRulesXpermRules2015-09-25T14:34:48Z<p>RichardHaines: </p>
<hr />
<div>= Extended Permission Access Vector Rules =<br />
There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments: <tt>allowxperm</tt>, <tt>dontauditxperm</tt>, <tt>auditallowxperm</tt> and <tt>neverallowxperm</tt>.<br />
<br />
The rules for extended permissions are subject to the <tt>operation</tt> they perform with Policy version 30 supporting ioctl whitelisting.<br />
<br />
'''The common format for Extended Access Vector Rules are:'''<br />
<pre><br />
rule_name source_type target_type : class operation xperm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable <tt>allowxperm</tt>, <tt>dontauditxperm</tt> <tt>auditallowxperm</tt> or <tt>neverallowxperm</tt> rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| operation<br />
| A key word defining the operation to be implemented by the rule. Currently only the ioctl operation is supported by the language and kernel as described in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|-<br />
| xperm_set<br />
| One or more extended permissions represented by numeric values (i.e. 0x8900 or 35072). The usage is dependant on the specified operation.<br />
<br />
Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed.<br />
<br />
The range operator (-) is used to specify all permissions within the low – high range.<br />
<br />
An example is shown in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
== ioctl Operation Rules ==<br />
Use cases and implementation details for ioctl command whitelisting are described in detail at [http://marc.info/?l=selinux&m=143336061925628&w=2 http://marc.info/?l=selinux&m=143336061925628&w=2], with the final policy format changes shown in the example below with a brief overview (also see [http://marc.info/?l=selinux&m=143412575302369&w=2 http://marc.info/?l=selinux&m=143412575302369&w=2]) that is the final upstream kernel patch).<br />
Ioctl calls are generally used to get or set device options. Policy versions < 30 only controls whether an ioctl permission is allowed or not, for example this rule allows the object class tcp_socket the ioctl permission:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
</pre><br />
<br />
<br />
From Policy version 30 it is possible to control <tt>'''ioctl'''(2)</tt> 'request' parameters provided the ioctl permission is also allowed, for example:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
<br />
allowxperm src_t tgt_t : tcp_socket ioctl ~0x8927;<br />
</pre><br />
<br />
The allowxperm rule states that all ioctl request parameters are allowed for the source/target/class with the exception of the value 0x8927 that (using <tt>include/linux/sockios.h</tt>) is <tt>SIOCGIFHWADDR</tt>, or 'get hardware address'.<br />
<br />
<br />
An example audit log entry denying an ioctl request to add a routing table entry (<tt>SIOCADDRT - ioctlcmd=890b</tt>) for goldfish_setup on a udp_socket is:<br />
<pre><br />
type=1400 audit(1437408413.860:6): avc: denied { ioctl } for pid=81 comm="route" path="socket:[1954]" dev="sockfs" ino=1954 ioctlcmd=890b<br />
scontext=u:r:goldfish_setup:s0 tcontext=u:r:goldfish_setup:s0 tclass=udp_socket permissive=0<br />
</pre><br />
<br />
<br />
Notes:<br />
** Important: The ioctl operation is not 'deny all' ioctl requests (hence whitelisting). It is targeted at the specific source/target/class set of ioctl commands. As no other allowxperm rules have been defined in the example, all other ioctl calls may continue to use any valid request parameters (provided there are allow rules for the ioctl permission).<br />
** As the <tt>'''ioctl'''(2)</tt> function requires a file descriptor, its context must match the process context otherwise the <tt>fd { use }</tt> class/permission is required.<br />
** To deny all ioctl requests for a specific source/target/class the xperm_set can be set to '0' or '0x0'.<br />
** This feature is implemented in Android kernels (e.g. android-goldfish-3.4) and is available in Linux kernels > 4.2-rc2.<br />
Note that Android M is built with an earlier version (see thread [http://marc.info/?l=seandroid-list&m=143436044512043&w=2 http://marc.info/?l=seandroid-list&m=143436044512043&w=2]) that uses the following rule format:<br />
<pre><br />
# Allow SIOCGIFNAME (get iface name) ioctl requests on udp_socket for untrusted_app<br />
allow untrusted_app self:udp_socket 0x8910;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[AVCRules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/PolicyStoreConfigurationFilesPolicyStoreConfigurationFiles2015-09-25T14:28:40Z<p>RichardHaines: /* modules/active/disable_dontaudit File */</p>
<hr />
<div>= Policy Store Configuration Files =<br />
Depending on the release being used policy stores will be located at:<br />
* <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt><nowiki> - This is the default for systems that support versions < 2.4 of </nowiki><tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>.<br />
* <tt><nowiki>/var/lib/selinux/<policy_name>/modules</nowiki></tt> - This is the default for systems that support versions >= 2.4 of <tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>. The base (<tt>/var/lib/selinux</tt>) may be overridden by the <tt>store-root</tt> parameter defined in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The migration process from previous releases is described at [https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration]. Note that once the policy store migration is complete, these files will no longer exist<br />
<br />
Note: There can be multiple policy stores on a system at <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt>.<br />
<br />
The Policy Store files are either installed, updated or built by the '''semodule'''(8) and '''semanage'''(8) commands as a part of the build process. The resulting files will either be copied over to the [[PolicyConfigurationFiles | Policy Configuration Files]] area, or used to rebuild the kernel binary policy located at <nowiki>/etc/selinux/<policy_name>/policy</nowiki>.<br />
<br />
All files may have comments inserted where each line must have the '#' symbol to indicate the start of a comment.<br />
<br />
The command options and outputs shown in the text are based on the current F-20 build.<br />
<br />
== modules/ Files ==<br />
The policy store has two lock files that are used by libsemanage for managing the store. Their format is not relevant to policy construction:<br />
<pre><br />
semanage.read.LOCK<br />
semanage.trans.LOCK<br />
</pre><br />
<br />
== modules/active/base.pp File ==<br />
This is the packaged base policy that contains the mandatory modules and policy components such as object classes, permission declarations and initial SIDs.<br />
<br />
== modules/active/base.linked File ==<br />
This is only present if the save-linked is set to <tt>TRUE</tt> as described in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | /etc/selinux/semanage.conf]] section. It contains the modules that have been linked using the <tt>'''semodule_link'''(8)</tt> command.<br />
<br />
== modules/active/commit_num File ==<br />
This is a binary file used by libsemanage for managing updates to the store. The format is not relevant to policy construction.<br />
<br />
== modules/active/file_contexts.template File ==<br />
This contains a copy all the modules 'Labeling Policy File' entries (e.g. the <nowiki><module_name>.fc</nowiki> files) that have been extracted from the [[#modules/active/base.pp | base.pp]] and the loadable modules in the [[#modules/active/modules_Directory_Contents | modules/active/modules]] directory. <br />
<br />
The entries in the file_contexts.template file are then used to build the following files as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram:<br />
# [[#modules/active/homedir_template | homedir_template]] file that will be used to produce the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file which will then become the policies ./contexts/files/file_contexts.homedirs file. <br />
# [[#modules/active/file_contexts | file_contexts]] file that will become the policies file_contexts file.<br />
<br />
Note that as a part of the <tt>semanage</tt> build process, these two files will also have <tt>file_contexts.bin</tt> and <tt>file_contexts.homedirs.bin</tt> files present in the [[PolicyConfigurationFiles#contexts/files/file_contexts File | Policy Configuration Files]] <tt>contexts/files</tt> directory. This is because <tt>semanage</tt> requires these in the Perl compatible regular expression (PCRE) internal format. They are generated by the <tt>'''sefcontext_compile'''(8)</tt> utility.<br />
<br />
The homedir_template and file_contexts files are built is as follows:<br />
: '''homedir_template''' - Any line in the file_contexts.template file that has the keywords HOME_ROOT, HOME_DIR and/or USER are extracted and added to the homedir_template file. This is because these keywords are used to identify entries that are associated to a users home directory area. These lines may also have the ROLE keyword declared.<br />
: The homedir_template file will then be processed by '''genhomedircon'''(8)<ref name="ftn34"><sup>The genhomedircon command has now been built into the libsemanage library as a function to build the file_contexts.homedirs file via '''semanage'''(8).</sup></ref> to generate individual SELinux user entries in the file_contexts.homedirs file as discussed in the [[#modules/active/file_contexts.homedirs | modules/active/file_contexts.homedirs]] section.<br />
<br />
These are examples of one line being processed as described above, taken from the F-20 targeted policy:<br />
<br />
The master file_contexts.template entry:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The <tt>homedir_</tt>template entry is created as:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The file_contexts.homedirs entries are created by <tt>genhomedircon</tt> for the SELinux users extracted from the [[#modules/active/seusers.final and seusers Files | seusers]] file as follows:<br />
<pre><br />
# Home Context for any Linux user that is assigned<br />
# the SELinux user unconfined_u<br />
/home/[^/]*/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
<br />
# Home Context for user root<br />
/root/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
'''file_contexts''' - All other lines are extracted and added to the file_contexts file as they are files not associated to a users home directory. <br />
<br />
'''The format of the file_contexts.template file is as follows:'''<br />
<br />
Each line within the file consists of the following:<br />
<pre><br />
pathname_regexp [file_type] opt_security_context<br />
</pre><br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pathname_regexp<br />
| An entry that defines the pathname that may be in the form of a regular expression.<br />
<br />
The metacharacters '^' (match beginning of line) and '$' (match end of line) are automatically added to the expression by the routines that process this file, however they can be over-ridden by using '.*' at either the beginning or end of the expression (see the example file_contexts files below). <br />
<br />
There are also keywords of HOME_ROOT, HOME_DIR, ROLE and USER that are used by file labeling commands (see the keyword definitions below and the [[#modules/active/homedir_template | modules/active/homedir_template]] file section for their usage).<br />
<br />
|-<br />
| file_type<br />
| One of the following optional file_type entries (note if blank means "all file types"):<br />
<br />
'<tt>-b</tt>' - Block Device '<tt>-c</tt>' - Character Device<br />
<br />
'<tt>-d</tt>' - Directory '<tt>-p</tt>' - Named Pipe (FIFO)<br />
<br />
'<tt>-l</tt>' - Symbolic Link '<tt>-s</tt>' - Socket File<br />
<br />
'<tt>--</tt>' - Ordinary file<br />
<br />
By convention this entry is known as 'file type', however it really represents the 'file object class'.<br />
<br />
|-<br />
| opt_security_context<br />
| This entry can be either:<br />
# The security context, including the MLS / MCS level or range if applicable that will be assigned to the file.<br />
# A value of <nowiki><<none>></nowiki> can be used to indicate that matching files should not be re-labeled. <br />
<br />
|}<br />
<br />
<br />
'''Keywords that can be in the file_contexts.template file are:'''<br />
<br />
{| border="1"<br />
| HOME_ROOT<br />
| This keyword is replaced by the GNU / Linux users root home directory, normally '/home' is the default.<br />
<br />
|-<br />
| HOME_DIR<br />
| This keyword is replaced by the GNU / Linux users home directory, normally '/home/' is the default.<br />
<br />
|-<br />
| USER<br />
| This keyword will be replaced by the users GNU / Linux user id.<br />
<br />
|-<br />
| ROLE<br />
| This keyword is replaced by the 'prefix' entry from the users_extra configuration file that corresponds to the SELinux users user id. Example users_extra configuration file entries are:<br />
<pre><br />
user user_u prefix user;<br />
user staff_u prefix staff;<br />
</pre><br />
<br />
It is used for files and directories within the users home directory area. <br />
<br />
The prefix can be added by the semanage <tt>login</tt> command as follows (although note that the <tt>-P</tt> option is suppressed when help is displayed as it is generally it is not used (defaults to <tt>user</tt>) - see [http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701 http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701] for further information):<br />
<pre><br />
# Add a Linux user:<br />
adduser rch<br />
<br />
# Modify staff_u SELinux user and prefix:<br />
semanage user -m -R staff_r -P staff staff_u<br />
<br />
# Associate the SELinux user to the Linux user:<br />
semanage login -a -s staff_u rch<br />
</pre><br />
<br />
<br />
<br />
|}<br />
<br />
<br />
'''Example file_contexts.template''' '''contents from targeted policy:'''<br />
<pre><br />
# modules/active/file_contexts.template - These sample entries<br />
# have been taken from the targeted policy and show the<br />
# HOME_DIR, HOME_ROOT and USER keywords whose lines will be<br />
# extracted and added to the homedir_template file that is<br />
# used to manage user home directory entries.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
...<br />
/etc/ntop.* system_u:object_r:ntop_etc_t:s0<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/dev/dri/.+ -c system_u:object_r:dri_device_t:s0<br />
...<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
...<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
...<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts | contexts/files/file_contexts]] file and is built from entries in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file as explained above and shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that files and directories are labeled according to the policy.<br />
<br />
The format of the file_contexts file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
The USER keyword is replaced by the users GNU / Linux user id when the file labeling utilities are run.<br />
<br />
'''Example file_contexts contents:'''<br />
<pre><br />
# modules/active/file_contexts - These sample entries have<br />
# been taken from the targeted policy.<br />
# The keywords HOME_DIR, HOME_ROOT, USER and ROLE have been<br />
# removed and put in the homedir_template file.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
/xen(/.*)? system_u:object_r:xen_image_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt(/[^/]*)? -d system_u:object_r:mnt_t:s0<br />
/bin/.* system_u:object_r:bin_t:s0<br />
/dev/.* system_u:object_r:device_t:s0<br />
/usr/.* system_u:object_r:usr_t:s0<br />
/var/.* system_u:object_r:var_t:s0<br />
/run/.* system_u:object_r:var_run_t:s0<br />
/srv/.* system_u:object_r:var_t:s0<br />
/tmp/.* <<none>><br />
</pre><br />
<br />
<pre><br />
# contexts/files/file_contexts - Sample entries from the MLS reference policy. <br />
# Notes:<br />
# 1) The fixed_disk_device_t is labeled SystemHigh (s15:c0.c255)<br />
# as it needs to be trusted. Also some logs and configuration<br />
# files are labeled SystemHigh as they contain sensitive<br />
# information used by trusted applications.<br />
#<br />
# 2) Some directories (e.g. ''/tmp'') are labeled <br />
# SystemLow-SystemHigh (s0-s15:c0.c255) as they will<br />
# support polyinstantiated directories.<br />
<br />
/.*system_u:object_r:default_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt/[^/]*/.* <<none>><br />
/dev/.*mouse.* -c system_u:object_r:mouse_device_t:s0<br />
/dev/.*tty[^/]* -c system_u:object_r:tty_device_t:s0<br />
/dev/[shmx]d[^/]* -b system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/var/[xgk]dm(/.*)? system_u:object_r:xserver_log_t:s0<br />
/dev/(raw/)?rawctl -c system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/dev/pts -d system_u:object_r:devpts_t:s0-s15:c0.c255<br />
/var/log -d system_u:object_r:var_log_t:s0-s15:c0.c255<br />
/var/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/var/run -d system_u:object_r:var_run_t:s0-s15:c0.c255<br />
/usr/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
<pre><br />
<br />
== modules/active/homedir_template File ==<br />
This file is built from entries in the [[#modules/active/file_contexts.template | file_contexts.template]] file (as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram) and explained in the [[#modules/modules/active/file_contexts.template | modules/active/file_contexts.template]] section. <br />
<br />
The file is used by genhomedircon, semanage login or semanage user to generate individual user entries in the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file.<br />
<br />
The homedir_template file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example file contents:'''<br />
<pre><br />
# modules/active/homedir_template - These sample entries have <br />
# been taken from the targeted policy and show the <br />
# HOME_DIR, HOME_ROOT and USER keywords that are used to manage <br />
# users home directories:<br />
<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts.homedirs File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts.homedirs | contexts/files/file_contexts.homedirs]] file when building policy as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that users home directory areas are labeled according to the policy. <br />
<br />
The file can be built by the genhomedircon command (that just calls /usr/sbin/semodule -Bn) or if using semanage with user or login options to manage users, where it is called automatically as it is now a libsepol library function. <br />
<br />
The file_contexts.homedirs file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file, however the HOME_DIR, ROOT_DIR, <tt>ROLE</tt> and USER keywords will be replaced as explained in the keyword definitions section above.<br />
<br />
'''Example file_contexts.homedirs contents:'''<br />
<pre><br />
# modules/active/file_contexts.homedirs - These sample entries <br />
# have been taken from the targeted policy and show that <br />
# the HOME_DIR, HOME_ROOT and USER keywords have been replaced<br />
# by entries as explained above.<br />
#<br />
# Home Context for the default user (unconfined_u)<br />
/home/[^/]*/.+ unconfined_u:object_r:user_home_t:s0<br />
/home/[^/]*/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-.*/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-.* -d unconfined_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user rch<br />
/home/rch/.+ staff_u:object_r:user_home_t:s0<br />
/home/rch/.maildir(/.*)? staff_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-rch/.* -- staff_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-rch -d staff_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user root<br />
/root/.+ unconfined_u:object_r:user_home_t:s0<br />
/root/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-root/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-root -d unconfined_u:object_r:user_tmp_t:s0<br />
</pre><br />
<br />
== modules/active/netfilter_contexts & netfilter.local File ==<br />
These files are not used at present. There is code to produce a netfilter_contexts file for use by the GNU/Linux iptables service<ref name="ftn35"><sup>This uses SECMARK labeling that has been utilised by SELinux as described in the [[NB_Networking | SELinux Networking Support]] section.</sup></ref> in the Reference Policy that would generate a file similar to the example below, however there seems much debate on how they should be managed (see [https://bugzilla.redhat.com/show_bug.cgi?id=201573 bug 201573 - Secmark iptables integration] for details).<br />
<br />
== modules/active/policy.kern File ==<br />
This is the binary policy file built by either the '''semanage'''(8) or '''semodule'''(8) commands (depending on the configuration action), that then becomes the binary policy to be loaded into the kernel.<br />
<br />
== modules/active/seusers.final and seusers Files ==<br />
The seusers.final file maps GNU / Linux users to SELinux users and becomes the policies seusers<ref name="ftn36"><sup>Many seusers make confusion: The modules/active/seusers file is used to hold initial seusers entries, the modules/active/seusers.final file holds the complete entries that then becomes the policy <tt>seusers</tt> file.</sup></ref> file as discussed in the [[PolicyConfigurationFiles#seusers | seusers]] section. The seusers.final file is built or modified when:<br />
* Building a policy where an optional seusers file has been included in the base package via the '''semodule_package'''(8) command (signified by the -s flag) as follows<ref name="ftn37"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial seusers file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -s seusers ... <br />
</pre><br />
The seusers file would be extracted by the subsequent semodule command when building the policy to produce the seusers.final file.<br />
<br />
* The semanage login command is used to map GNU / Linux users to SELinux users as follows:<br />
<pre><br />
semanage login -a -s staff_u rch <br />
</pre><br />
This action will update the seusers file that would then be used to produce the seusers.final file with both policy and locally defined user mapping.<br />
<br />
It is also possible to associate a GNU / Linux group of users to an SELinux user as follows:<br />
<pre><br />
semanage login -a -s staff_u %staff_group<br />
</pre><br />
<br />
'''The format of the seusers.final & seusers files are as follows:'''<br />
<pre><br />
[%]user_id:seuser_id[:range]<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user_id<br />
| Where <tt>user_id</tt> is the GNU / Linux user identity. If this is a GNU / Linux <tt>group_id</tt> then it will be preceded with the '<tt>%</tt>' sign as shown in the example below.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| range<br />
| The optional <tt>level</tt> or range.<br />
<br />
|}<br />
<br />
<br />
'''Example seusers.final file contents:'''<br />
<pre><br />
# modules/active/seusers.final<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux user mapping:'''<br />
<pre><br />
# This command will add the rch:user_u entry in the seusers file:<br />
<br />
semanage login -a -s user_u rch<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# modules/active/seusers<br />
<br />
rch:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# /modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux group mapping:'''<br />
<pre><br />
# This command will add the %user_group:user_u entry in the seusers file: <br />
<br />
semanage login -a -s user_u %user_group<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# /modules/active/seusers<br />
<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
== modules/active/users_extra, users_extra.local and users.local Files ==<br />
These three files work together to describe SELinux user information as follows:<br />
* The users_extra and users_extra.local files are used to map a prefix to users home directories as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section, where it is used to replace the ROLE keyword. The prefix is linked to an SELinux user id and should reflect the users role. The semanage user command will allow a prefix to be added via the -P flag (although no longer used by policies as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section). <br />
<br />
The users_extra file contains all the policy prefix entries, and the users_extra.local file contains those generated by the semanage user command.<br />
<br />
The users_extra file can optionally be included in the base package via the '''semodule_package'''(8) command (signified by the -u flag) as follows<ref name="ftn38"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial users_extra file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -u users_extra ... <br />
</pre><br />
<br />
The users_extra file would then be extracted by a subsequent semodule command when building the policy.<br />
<br />
* The users.local file is used to add new SELinux users to the policy without editing the policy source itself (with each line in the file following a policy language [[KernelPolicyLanguage#user | user]] statement section). This is useful when only the Reference Policy headers are installed and additional users need to added. The semanage user command will allow a new SELinux user to be added that would generate the user.local file and if a -P flag has been specified, then a users_extra.local file is also updated (note: if this is a new SELinux user and a prefix is not specified a default prefix of user is generated). <br />
<br />
The sections that follow will:<br />
* Define the format and show example users_extra and users_extra.local files.<br />
* Execute an semanage user command that will add a new SELinux user and associated prefix, and show the resulting users_extra, users_extra.local and users.local files. <br />
<br />
Note that each line of the users.local file contains a user statement that is defined in the policy language [[KernelPolicyLanguage#user | user]] statement section, and will be built into the policy via the semanage command.<br />
<br />
'''The format of the users_extra & users_extra.local files are as follows:'''<br />
<pre><br />
user seuser_id prefix prefix_id;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user<br />
| The user keyword.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| prefix<br />
| The prefix keyword.<br />
<br />
|-<br />
| prefix_id<br />
| An identifier that will be used to replace the ROLE keyword within the modules/active/homedir_template file when building the ./modules/active/file_contexts.homedirs file for the relabeling utilities to set the security context on users home directories.<br />
<br />
|}<br />
<br />
<br />
'''Example users_extra file contents:'''<br />
<pre><br />
# modules/active/users_extra entries, note that the <br />
# users_extra.local file contents are similar and generated by <br />
# the semanage user command.<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
</pre><br />
<br />
'''Example semanage user command to add a new SELinux user:'''<br />
<pre><br />
# This command will add the user test_u prefix staff entry in <br />
# the users_extra.local file: <br />
<br />
semanage user -a -R staff_r -P staff test_u<br />
</pre><br />
<br />
'''The resulting users_extra.local file is as follows:'''<br />
<pre><br />
# modules/active/users_extra.local<br />
<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users_extra file is as follows:'''<br />
<pre><br />
# modules/active/users_extra<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users.local file is as follows:'''<br />
<pre><br />
# modules/active/users.local file entry:<br />
<br />
user test_u roles { staff_r } level s0 range s0;<br />
</pre><br />
<br />
== modules/active/booleans.local File ==<br />
This file is created and updated by the <tt>semanage boolean</tt> command and holds boolean value as requested.<br />
<br />
'''Example semanage boolean command to modify a boolean value:'''<br />
<pre><br />
# This command will add an entry in the booleans.local <br />
# file and set the boolean value to 'off': <br />
<br />
semanage boolean -m -0 ext_gateway_audit<br />
</pre><br />
<br />
'''The resulting <tt>booleans.</tt>local file would be:'''<br />
<pre><br />
# modules/active/booleans.local<br />
<br />
ext_gateway_audit=0<br />
</pre><br />
<br />
== modules/active/file_contexts.local File ==<br />
This file is created and updated by the semanage fcontext command. It is used to hold file context information on files and directories that were not delivered by the core policy (i.e. they are not defined in any of the <nowiki>*.fc</nowiki> files delivered in the base and loadable modules).<br />
<br />
The semanage command will add the information to the policy stores file_contexts.local file and then copy this file to the ./contexts/files/file_contexts.local file, where it will be used when the file context utilities are run.<br />
<br />
The format of the file_contexts.local file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example semanage fcontext command to add a new entry:'''<br />
<pre><br />
# This command will add an entry in the file_contexts.local file: <br />
<br />
semanage fcontext -a -t user_t /usr/move_file<br />
<br />
# Note that the type (-t flag) must exist in the policy <br />
# otherwise the command will fail.<br />
</pre><br />
<br />
'''The resulting file_contexts.local file would be:'''<br />
<pre><br />
# modules/active/file_contexts.local<br />
<br />
/usr/move_filesystem_u:object_r:user_t<br />
</pre><br />
<br />
== modules/active/interfaces.local File ==<br />
This file is created and updated by the semanage interface command to hold network interface information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new interface information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a netifcon statement that is defined along with examples in the [[NetworkStatements#netifcon | netifcon]] statement section.<br />
<br />
== modules/active/nodes.local File ==<br />
This file is created and updated by the semanage node command to hold network address information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new node information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a nodecon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#nodecon | nodecon]] statement section.<br />
<br />
== modules/active/ports.local File ==<br />
This file is created and updated by the semanage port command to hold network port information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new port information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a portcon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#portcon | portcon]] statement section.<br />
<br />
== modules/active/preserve_tunables File ==<br />
This file will only exist if the policy build specified that tunables should be preserved, if so they would be converted to booleans by the policy build process.<br />
<br />
== modules/active/disable_dontaudit File ==<br />
This file will only exist if the policy build specified that [[AVCRules#dontaudit | dontaudit]] rules should be disabled.<br />
<br />
== modules/active/modules Directory Contents ==<br />
This directory contains loadable modules (<nowiki><module_name>.pp</nowiki> or when disabled <tt><nowiki><module_name>.pp.disabled</nowiki></tt>) that have been built by the semodule_package command and placed in the store by the semodule or <tt>semanage module -a</tt> commands as shown in the following example:<br />
<pre><br />
# Package the module move_file_c:<br />
<br />
semodule_package -o move_file_c.pp -m move_file_c.mod -f move_file.fc <br />
<br />
# Then to install it in the store (at /etc/selinux/modular-test/<br />
# modules/active/modules/move_file_c.pp) and build the binary <br />
# policy file, run the semodule command:<br />
<br />
semodule -v -s modular-test -i move_file_c.pp<br />
# Or:<br />
semanage module -a -S modular-test move_file_c.pp<br />
</pre><br />
<br />
The modules within the policy store may be compressed or not depending on the value of the <tt>bzip-blocksize</tt> parameter in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The modules and their status can be listed using the <tt>semanage module -l</tt> command as shown below.<br />
<pre><br />
semanage module -l<br />
ext_gateway 1.1.0<br />
int_gateway 1.1.0<br />
move_file 1.1.0<br />
netlabel 1.0.0 Disabled<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[GlobalConfigurationFiles | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[PolicyConfigurationFiles | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/PolicyStoreConfigurationFilesPolicyStoreConfigurationFiles2015-09-25T14:28:02Z<p>RichardHaines: /* modules/active/interfaces.local File */</p>
<hr />
<div>= Policy Store Configuration Files =<br />
Depending on the release being used policy stores will be located at:<br />
* <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt><nowiki> - This is the default for systems that support versions < 2.4 of </nowiki><tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>.<br />
* <tt><nowiki>/var/lib/selinux/<policy_name>/modules</nowiki></tt> - This is the default for systems that support versions >= 2.4 of <tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>. The base (<tt>/var/lib/selinux</tt>) may be overridden by the <tt>store-root</tt> parameter defined in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The migration process from previous releases is described at [https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration]. Note that once the policy store migration is complete, these files will no longer exist<br />
<br />
Note: There can be multiple policy stores on a system at <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt>.<br />
<br />
The Policy Store files are either installed, updated or built by the '''semodule'''(8) and '''semanage'''(8) commands as a part of the build process. The resulting files will either be copied over to the [[PolicyConfigurationFiles | Policy Configuration Files]] area, or used to rebuild the kernel binary policy located at <nowiki>/etc/selinux/<policy_name>/policy</nowiki>.<br />
<br />
All files may have comments inserted where each line must have the '#' symbol to indicate the start of a comment.<br />
<br />
The command options and outputs shown in the text are based on the current F-20 build.<br />
<br />
== modules/ Files ==<br />
The policy store has two lock files that are used by libsemanage for managing the store. Their format is not relevant to policy construction:<br />
<pre><br />
semanage.read.LOCK<br />
semanage.trans.LOCK<br />
</pre><br />
<br />
== modules/active/base.pp File ==<br />
This is the packaged base policy that contains the mandatory modules and policy components such as object classes, permission declarations and initial SIDs.<br />
<br />
== modules/active/base.linked File ==<br />
This is only present if the save-linked is set to <tt>TRUE</tt> as described in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | /etc/selinux/semanage.conf]] section. It contains the modules that have been linked using the <tt>'''semodule_link'''(8)</tt> command.<br />
<br />
== modules/active/commit_num File ==<br />
This is a binary file used by libsemanage for managing updates to the store. The format is not relevant to policy construction.<br />
<br />
== modules/active/file_contexts.template File ==<br />
This contains a copy all the modules 'Labeling Policy File' entries (e.g. the <nowiki><module_name>.fc</nowiki> files) that have been extracted from the [[#modules/active/base.pp | base.pp]] and the loadable modules in the [[#modules/active/modules_Directory_Contents | modules/active/modules]] directory. <br />
<br />
The entries in the file_contexts.template file are then used to build the following files as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram:<br />
# [[#modules/active/homedir_template | homedir_template]] file that will be used to produce the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file which will then become the policies ./contexts/files/file_contexts.homedirs file. <br />
# [[#modules/active/file_contexts | file_contexts]] file that will become the policies file_contexts file.<br />
<br />
Note that as a part of the <tt>semanage</tt> build process, these two files will also have <tt>file_contexts.bin</tt> and <tt>file_contexts.homedirs.bin</tt> files present in the [[PolicyConfigurationFiles#contexts/files/file_contexts File | Policy Configuration Files]] <tt>contexts/files</tt> directory. This is because <tt>semanage</tt> requires these in the Perl compatible regular expression (PCRE) internal format. They are generated by the <tt>'''sefcontext_compile'''(8)</tt> utility.<br />
<br />
The homedir_template and file_contexts files are built is as follows:<br />
: '''homedir_template''' - Any line in the file_contexts.template file that has the keywords HOME_ROOT, HOME_DIR and/or USER are extracted and added to the homedir_template file. This is because these keywords are used to identify entries that are associated to a users home directory area. These lines may also have the ROLE keyword declared.<br />
: The homedir_template file will then be processed by '''genhomedircon'''(8)<ref name="ftn34"><sup>The genhomedircon command has now been built into the libsemanage library as a function to build the file_contexts.homedirs file via '''semanage'''(8).</sup></ref> to generate individual SELinux user entries in the file_contexts.homedirs file as discussed in the [[#modules/active/file_contexts.homedirs | modules/active/file_contexts.homedirs]] section.<br />
<br />
These are examples of one line being processed as described above, taken from the F-20 targeted policy:<br />
<br />
The master file_contexts.template entry:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The <tt>homedir_</tt>template entry is created as:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The file_contexts.homedirs entries are created by <tt>genhomedircon</tt> for the SELinux users extracted from the [[#modules/active/seusers.final and seusers Files | seusers]] file as follows:<br />
<pre><br />
# Home Context for any Linux user that is assigned<br />
# the SELinux user unconfined_u<br />
/home/[^/]*/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
<br />
# Home Context for user root<br />
/root/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
'''file_contexts''' - All other lines are extracted and added to the file_contexts file as they are files not associated to a users home directory. <br />
<br />
'''The format of the file_contexts.template file is as follows:'''<br />
<br />
Each line within the file consists of the following:<br />
<pre><br />
pathname_regexp [file_type] opt_security_context<br />
</pre><br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pathname_regexp<br />
| An entry that defines the pathname that may be in the form of a regular expression.<br />
<br />
The metacharacters '^' (match beginning of line) and '$' (match end of line) are automatically added to the expression by the routines that process this file, however they can be over-ridden by using '.*' at either the beginning or end of the expression (see the example file_contexts files below). <br />
<br />
There are also keywords of HOME_ROOT, HOME_DIR, ROLE and USER that are used by file labeling commands (see the keyword definitions below and the [[#modules/active/homedir_template | modules/active/homedir_template]] file section for their usage).<br />
<br />
|-<br />
| file_type<br />
| One of the following optional file_type entries (note if blank means "all file types"):<br />
<br />
'<tt>-b</tt>' - Block Device '<tt>-c</tt>' - Character Device<br />
<br />
'<tt>-d</tt>' - Directory '<tt>-p</tt>' - Named Pipe (FIFO)<br />
<br />
'<tt>-l</tt>' - Symbolic Link '<tt>-s</tt>' - Socket File<br />
<br />
'<tt>--</tt>' - Ordinary file<br />
<br />
By convention this entry is known as 'file type', however it really represents the 'file object class'.<br />
<br />
|-<br />
| opt_security_context<br />
| This entry can be either:<br />
# The security context, including the MLS / MCS level or range if applicable that will be assigned to the file.<br />
# A value of <nowiki><<none>></nowiki> can be used to indicate that matching files should not be re-labeled. <br />
<br />
|}<br />
<br />
<br />
'''Keywords that can be in the file_contexts.template file are:'''<br />
<br />
{| border="1"<br />
| HOME_ROOT<br />
| This keyword is replaced by the GNU / Linux users root home directory, normally '/home' is the default.<br />
<br />
|-<br />
| HOME_DIR<br />
| This keyword is replaced by the GNU / Linux users home directory, normally '/home/' is the default.<br />
<br />
|-<br />
| USER<br />
| This keyword will be replaced by the users GNU / Linux user id.<br />
<br />
|-<br />
| ROLE<br />
| This keyword is replaced by the 'prefix' entry from the users_extra configuration file that corresponds to the SELinux users user id. Example users_extra configuration file entries are:<br />
<pre><br />
user user_u prefix user;<br />
user staff_u prefix staff;<br />
</pre><br />
<br />
It is used for files and directories within the users home directory area. <br />
<br />
The prefix can be added by the semanage <tt>login</tt> command as follows (although note that the <tt>-P</tt> option is suppressed when help is displayed as it is generally it is not used (defaults to <tt>user</tt>) - see [http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701 http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701] for further information):<br />
<pre><br />
# Add a Linux user:<br />
adduser rch<br />
<br />
# Modify staff_u SELinux user and prefix:<br />
semanage user -m -R staff_r -P staff staff_u<br />
<br />
# Associate the SELinux user to the Linux user:<br />
semanage login -a -s staff_u rch<br />
</pre><br />
<br />
<br />
<br />
|}<br />
<br />
<br />
'''Example file_contexts.template''' '''contents from targeted policy:'''<br />
<pre><br />
# modules/active/file_contexts.template - These sample entries<br />
# have been taken from the targeted policy and show the<br />
# HOME_DIR, HOME_ROOT and USER keywords whose lines will be<br />
# extracted and added to the homedir_template file that is<br />
# used to manage user home directory entries.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
...<br />
/etc/ntop.* system_u:object_r:ntop_etc_t:s0<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/dev/dri/.+ -c system_u:object_r:dri_device_t:s0<br />
...<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
...<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
...<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts | contexts/files/file_contexts]] file and is built from entries in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file as explained above and shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that files and directories are labeled according to the policy.<br />
<br />
The format of the file_contexts file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
The USER keyword is replaced by the users GNU / Linux user id when the file labeling utilities are run.<br />
<br />
'''Example file_contexts contents:'''<br />
<pre><br />
# modules/active/file_contexts - These sample entries have<br />
# been taken from the targeted policy.<br />
# The keywords HOME_DIR, HOME_ROOT, USER and ROLE have been<br />
# removed and put in the homedir_template file.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
/xen(/.*)? system_u:object_r:xen_image_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt(/[^/]*)? -d system_u:object_r:mnt_t:s0<br />
/bin/.* system_u:object_r:bin_t:s0<br />
/dev/.* system_u:object_r:device_t:s0<br />
/usr/.* system_u:object_r:usr_t:s0<br />
/var/.* system_u:object_r:var_t:s0<br />
/run/.* system_u:object_r:var_run_t:s0<br />
/srv/.* system_u:object_r:var_t:s0<br />
/tmp/.* <<none>><br />
</pre><br />
<br />
<pre><br />
# contexts/files/file_contexts - Sample entries from the MLS reference policy. <br />
# Notes:<br />
# 1) The fixed_disk_device_t is labeled SystemHigh (s15:c0.c255)<br />
# as it needs to be trusted. Also some logs and configuration<br />
# files are labeled SystemHigh as they contain sensitive<br />
# information used by trusted applications.<br />
#<br />
# 2) Some directories (e.g. ''/tmp'') are labeled <br />
# SystemLow-SystemHigh (s0-s15:c0.c255) as they will<br />
# support polyinstantiated directories.<br />
<br />
/.*system_u:object_r:default_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt/[^/]*/.* <<none>><br />
/dev/.*mouse.* -c system_u:object_r:mouse_device_t:s0<br />
/dev/.*tty[^/]* -c system_u:object_r:tty_device_t:s0<br />
/dev/[shmx]d[^/]* -b system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/var/[xgk]dm(/.*)? system_u:object_r:xserver_log_t:s0<br />
/dev/(raw/)?rawctl -c system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/dev/pts -d system_u:object_r:devpts_t:s0-s15:c0.c255<br />
/var/log -d system_u:object_r:var_log_t:s0-s15:c0.c255<br />
/var/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/var/run -d system_u:object_r:var_run_t:s0-s15:c0.c255<br />
/usr/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
<pre><br />
<br />
== modules/active/homedir_template File ==<br />
This file is built from entries in the [[#modules/active/file_contexts.template | file_contexts.template]] file (as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram) and explained in the [[#modules/modules/active/file_contexts.template | modules/active/file_contexts.template]] section. <br />
<br />
The file is used by genhomedircon, semanage login or semanage user to generate individual user entries in the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file.<br />
<br />
The homedir_template file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example file contents:'''<br />
<pre><br />
# modules/active/homedir_template - These sample entries have <br />
# been taken from the targeted policy and show the <br />
# HOME_DIR, HOME_ROOT and USER keywords that are used to manage <br />
# users home directories:<br />
<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts.homedirs File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts.homedirs | contexts/files/file_contexts.homedirs]] file when building policy as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that users home directory areas are labeled according to the policy. <br />
<br />
The file can be built by the genhomedircon command (that just calls /usr/sbin/semodule -Bn) or if using semanage with user or login options to manage users, where it is called automatically as it is now a libsepol library function. <br />
<br />
The file_contexts.homedirs file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file, however the HOME_DIR, ROOT_DIR, <tt>ROLE</tt> and USER keywords will be replaced as explained in the keyword definitions section above.<br />
<br />
'''Example file_contexts.homedirs contents:'''<br />
<pre><br />
# modules/active/file_contexts.homedirs - These sample entries <br />
# have been taken from the targeted policy and show that <br />
# the HOME_DIR, HOME_ROOT and USER keywords have been replaced<br />
# by entries as explained above.<br />
#<br />
# Home Context for the default user (unconfined_u)<br />
/home/[^/]*/.+ unconfined_u:object_r:user_home_t:s0<br />
/home/[^/]*/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-.*/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-.* -d unconfined_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user rch<br />
/home/rch/.+ staff_u:object_r:user_home_t:s0<br />
/home/rch/.maildir(/.*)? staff_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-rch/.* -- staff_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-rch -d staff_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user root<br />
/root/.+ unconfined_u:object_r:user_home_t:s0<br />
/root/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-root/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-root -d unconfined_u:object_r:user_tmp_t:s0<br />
</pre><br />
<br />
== modules/active/netfilter_contexts & netfilter.local File ==<br />
These files are not used at present. There is code to produce a netfilter_contexts file for use by the GNU/Linux iptables service<ref name="ftn35"><sup>This uses SECMARK labeling that has been utilised by SELinux as described in the [[NB_Networking | SELinux Networking Support]] section.</sup></ref> in the Reference Policy that would generate a file similar to the example below, however there seems much debate on how they should be managed (see [https://bugzilla.redhat.com/show_bug.cgi?id=201573 bug 201573 - Secmark iptables integration] for details).<br />
<br />
== modules/active/policy.kern File ==<br />
This is the binary policy file built by either the '''semanage'''(8) or '''semodule'''(8) commands (depending on the configuration action), that then becomes the binary policy to be loaded into the kernel.<br />
<br />
== modules/active/seusers.final and seusers Files ==<br />
The seusers.final file maps GNU / Linux users to SELinux users and becomes the policies seusers<ref name="ftn36"><sup>Many seusers make confusion: The modules/active/seusers file is used to hold initial seusers entries, the modules/active/seusers.final file holds the complete entries that then becomes the policy <tt>seusers</tt> file.</sup></ref> file as discussed in the [[PolicyConfigurationFiles#seusers | seusers]] section. The seusers.final file is built or modified when:<br />
* Building a policy where an optional seusers file has been included in the base package via the '''semodule_package'''(8) command (signified by the -s flag) as follows<ref name="ftn37"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial seusers file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -s seusers ... <br />
</pre><br />
The seusers file would be extracted by the subsequent semodule command when building the policy to produce the seusers.final file.<br />
<br />
* The semanage login command is used to map GNU / Linux users to SELinux users as follows:<br />
<pre><br />
semanage login -a -s staff_u rch <br />
</pre><br />
This action will update the seusers file that would then be used to produce the seusers.final file with both policy and locally defined user mapping.<br />
<br />
It is also possible to associate a GNU / Linux group of users to an SELinux user as follows:<br />
<pre><br />
semanage login -a -s staff_u %staff_group<br />
</pre><br />
<br />
'''The format of the seusers.final & seusers files are as follows:'''<br />
<pre><br />
[%]user_id:seuser_id[:range]<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user_id<br />
| Where <tt>user_id</tt> is the GNU / Linux user identity. If this is a GNU / Linux <tt>group_id</tt> then it will be preceded with the '<tt>%</tt>' sign as shown in the example below.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| range<br />
| The optional <tt>level</tt> or range.<br />
<br />
|}<br />
<br />
<br />
'''Example seusers.final file contents:'''<br />
<pre><br />
# modules/active/seusers.final<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux user mapping:'''<br />
<pre><br />
# This command will add the rch:user_u entry in the seusers file:<br />
<br />
semanage login -a -s user_u rch<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# modules/active/seusers<br />
<br />
rch:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# /modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux group mapping:'''<br />
<pre><br />
# This command will add the %user_group:user_u entry in the seusers file: <br />
<br />
semanage login -a -s user_u %user_group<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# /modules/active/seusers<br />
<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
== modules/active/users_extra, users_extra.local and users.local Files ==<br />
These three files work together to describe SELinux user information as follows:<br />
* The users_extra and users_extra.local files are used to map a prefix to users home directories as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section, where it is used to replace the ROLE keyword. The prefix is linked to an SELinux user id and should reflect the users role. The semanage user command will allow a prefix to be added via the -P flag (although no longer used by policies as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section). <br />
<br />
The users_extra file contains all the policy prefix entries, and the users_extra.local file contains those generated by the semanage user command.<br />
<br />
The users_extra file can optionally be included in the base package via the '''semodule_package'''(8) command (signified by the -u flag) as follows<ref name="ftn38"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial users_extra file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -u users_extra ... <br />
</pre><br />
<br />
The users_extra file would then be extracted by a subsequent semodule command when building the policy.<br />
<br />
* The users.local file is used to add new SELinux users to the policy without editing the policy source itself (with each line in the file following a policy language [[KernelPolicyLanguage#user | user]] statement section). This is useful when only the Reference Policy headers are installed and additional users need to added. The semanage user command will allow a new SELinux user to be added that would generate the user.local file and if a -P flag has been specified, then a users_extra.local file is also updated (note: if this is a new SELinux user and a prefix is not specified a default prefix of user is generated). <br />
<br />
The sections that follow will:<br />
* Define the format and show example users_extra and users_extra.local files.<br />
* Execute an semanage user command that will add a new SELinux user and associated prefix, and show the resulting users_extra, users_extra.local and users.local files. <br />
<br />
Note that each line of the users.local file contains a user statement that is defined in the policy language [[KernelPolicyLanguage#user | user]] statement section, and will be built into the policy via the semanage command.<br />
<br />
'''The format of the users_extra & users_extra.local files are as follows:'''<br />
<pre><br />
user seuser_id prefix prefix_id;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user<br />
| The user keyword.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| prefix<br />
| The prefix keyword.<br />
<br />
|-<br />
| prefix_id<br />
| An identifier that will be used to replace the ROLE keyword within the modules/active/homedir_template file when building the ./modules/active/file_contexts.homedirs file for the relabeling utilities to set the security context on users home directories.<br />
<br />
|}<br />
<br />
<br />
'''Example users_extra file contents:'''<br />
<pre><br />
# modules/active/users_extra entries, note that the <br />
# users_extra.local file contents are similar and generated by <br />
# the semanage user command.<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
</pre><br />
<br />
'''Example semanage user command to add a new SELinux user:'''<br />
<pre><br />
# This command will add the user test_u prefix staff entry in <br />
# the users_extra.local file: <br />
<br />
semanage user -a -R staff_r -P staff test_u<br />
</pre><br />
<br />
'''The resulting users_extra.local file is as follows:'''<br />
<pre><br />
# modules/active/users_extra.local<br />
<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users_extra file is as follows:'''<br />
<pre><br />
# modules/active/users_extra<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users.local file is as follows:'''<br />
<pre><br />
# modules/active/users.local file entry:<br />
<br />
user test_u roles { staff_r } level s0 range s0;<br />
</pre><br />
<br />
== modules/active/booleans.local File ==<br />
This file is created and updated by the <tt>semanage boolean</tt> command and holds boolean value as requested.<br />
<br />
'''Example semanage boolean command to modify a boolean value:'''<br />
<pre><br />
# This command will add an entry in the booleans.local <br />
# file and set the boolean value to 'off': <br />
<br />
semanage boolean -m -0 ext_gateway_audit<br />
</pre><br />
<br />
'''The resulting <tt>booleans.</tt>local file would be:'''<br />
<pre><br />
# modules/active/booleans.local<br />
<br />
ext_gateway_audit=0<br />
</pre><br />
<br />
== modules/active/file_contexts.local File ==<br />
This file is created and updated by the semanage fcontext command. It is used to hold file context information on files and directories that were not delivered by the core policy (i.e. they are not defined in any of the <nowiki>*.fc</nowiki> files delivered in the base and loadable modules).<br />
<br />
The semanage command will add the information to the policy stores file_contexts.local file and then copy this file to the ./contexts/files/file_contexts.local file, where it will be used when the file context utilities are run.<br />
<br />
The format of the file_contexts.local file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example semanage fcontext command to add a new entry:'''<br />
<pre><br />
# This command will add an entry in the file_contexts.local file: <br />
<br />
semanage fcontext -a -t user_t /usr/move_file<br />
<br />
# Note that the type (-t flag) must exist in the policy <br />
# otherwise the command will fail.<br />
</pre><br />
<br />
'''The resulting file_contexts.local file would be:'''<br />
<pre><br />
# modules/active/file_contexts.local<br />
<br />
/usr/move_filesystem_u:object_r:user_t<br />
</pre><br />
<br />
== modules/active/interfaces.local File ==<br />
This file is created and updated by the semanage interface command to hold network interface information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new interface information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a netifcon statement that is defined along with examples in the [[NetworkStatements#netifcon | netifcon]] statement section.<br />
<br />
== modules/active/nodes.local File ==<br />
This file is created and updated by the semanage node command to hold network address information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new node information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a nodecon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#nodecon | nodecon]] statement section.<br />
<br />
== modules/active/ports.local File ==<br />
This file is created and updated by the semanage port command to hold network port information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new port information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a portcon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#portcon | portcon]] statement section.<br />
<br />
== modules/active/preserve_tunables File ==<br />
This file will only exist if the policy build specified that tunables should be preserved, if so they would be converted to booleans by the policy build process.<br />
<br />
== modules/active/disable_dontaudit File ==<br />
This file will only exist if the policy build specified that [[KernelPolicyLanguage#dontaudit | dontaudit]] rules should be disabled.<br />
<br />
== modules/active/modules Directory Contents ==<br />
This directory contains loadable modules (<nowiki><module_name>.pp</nowiki> or when disabled <tt><nowiki><module_name>.pp.disabled</nowiki></tt>) that have been built by the semodule_package command and placed in the store by the semodule or <tt>semanage module -a</tt> commands as shown in the following example:<br />
<pre><br />
# Package the module move_file_c:<br />
<br />
semodule_package -o move_file_c.pp -m move_file_c.mod -f move_file.fc <br />
<br />
# Then to install it in the store (at /etc/selinux/modular-test/<br />
# modules/active/modules/move_file_c.pp) and build the binary <br />
# policy file, run the semodule command:<br />
<br />
semodule -v -s modular-test -i move_file_c.pp<br />
# Or:<br />
semanage module -a -S modular-test move_file_c.pp<br />
</pre><br />
<br />
The modules within the policy store may be compressed or not depending on the value of the <tt>bzip-blocksize</tt> parameter in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The modules and their status can be listed using the <tt>semanage module -l</tt> command as shown below.<br />
<pre><br />
semanage module -l<br />
ext_gateway 1.1.0<br />
int_gateway 1.1.0<br />
move_file 1.1.0<br />
netlabel 1.0.0 Disabled<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[GlobalConfigurationFiles | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[PolicyConfigurationFiles | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/PolicyStoreConfigurationFilesPolicyStoreConfigurationFiles2015-09-25T14:25:34Z<p>RichardHaines: /* modules/active/file_contexts.homedirs File */</p>
<hr />
<div>= Policy Store Configuration Files =<br />
Depending on the release being used policy stores will be located at:<br />
* <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt><nowiki> - This is the default for systems that support versions < 2.4 of </nowiki><tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>.<br />
* <tt><nowiki>/var/lib/selinux/<policy_name>/modules</nowiki></tt> - This is the default for systems that support versions >= 2.4 of <tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>. The base (<tt>/var/lib/selinux</tt>) may be overridden by the <tt>store-root</tt> parameter defined in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The migration process from previous releases is described at [https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration]. Note that once the policy store migration is complete, these files will no longer exist<br />
<br />
Note: There can be multiple policy stores on a system at <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt>.<br />
<br />
The Policy Store files are either installed, updated or built by the '''semodule'''(8) and '''semanage'''(8) commands as a part of the build process. The resulting files will either be copied over to the [[PolicyConfigurationFiles | Policy Configuration Files]] area, or used to rebuild the kernel binary policy located at <nowiki>/etc/selinux/<policy_name>/policy</nowiki>.<br />
<br />
All files may have comments inserted where each line must have the '#' symbol to indicate the start of a comment.<br />
<br />
The command options and outputs shown in the text are based on the current F-20 build.<br />
<br />
== modules/ Files ==<br />
The policy store has two lock files that are used by libsemanage for managing the store. Their format is not relevant to policy construction:<br />
<pre><br />
semanage.read.LOCK<br />
semanage.trans.LOCK<br />
</pre><br />
<br />
== modules/active/base.pp File ==<br />
This is the packaged base policy that contains the mandatory modules and policy components such as object classes, permission declarations and initial SIDs.<br />
<br />
== modules/active/base.linked File ==<br />
This is only present if the save-linked is set to <tt>TRUE</tt> as described in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | /etc/selinux/semanage.conf]] section. It contains the modules that have been linked using the <tt>'''semodule_link'''(8)</tt> command.<br />
<br />
== modules/active/commit_num File ==<br />
This is a binary file used by libsemanage for managing updates to the store. The format is not relevant to policy construction.<br />
<br />
== modules/active/file_contexts.template File ==<br />
This contains a copy all the modules 'Labeling Policy File' entries (e.g. the <nowiki><module_name>.fc</nowiki> files) that have been extracted from the [[#modules/active/base.pp | base.pp]] and the loadable modules in the [[#modules/active/modules_Directory_Contents | modules/active/modules]] directory. <br />
<br />
The entries in the file_contexts.template file are then used to build the following files as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram:<br />
# [[#modules/active/homedir_template | homedir_template]] file that will be used to produce the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file which will then become the policies ./contexts/files/file_contexts.homedirs file. <br />
# [[#modules/active/file_contexts | file_contexts]] file that will become the policies file_contexts file.<br />
<br />
Note that as a part of the <tt>semanage</tt> build process, these two files will also have <tt>file_contexts.bin</tt> and <tt>file_contexts.homedirs.bin</tt> files present in the [[PolicyConfigurationFiles#contexts/files/file_contexts File | Policy Configuration Files]] <tt>contexts/files</tt> directory. This is because <tt>semanage</tt> requires these in the Perl compatible regular expression (PCRE) internal format. They are generated by the <tt>'''sefcontext_compile'''(8)</tt> utility.<br />
<br />
The homedir_template and file_contexts files are built is as follows:<br />
: '''homedir_template''' - Any line in the file_contexts.template file that has the keywords HOME_ROOT, HOME_DIR and/or USER are extracted and added to the homedir_template file. This is because these keywords are used to identify entries that are associated to a users home directory area. These lines may also have the ROLE keyword declared.<br />
: The homedir_template file will then be processed by '''genhomedircon'''(8)<ref name="ftn34"><sup>The genhomedircon command has now been built into the libsemanage library as a function to build the file_contexts.homedirs file via '''semanage'''(8).</sup></ref> to generate individual SELinux user entries in the file_contexts.homedirs file as discussed in the [[#modules/active/file_contexts.homedirs | modules/active/file_contexts.homedirs]] section.<br />
<br />
These are examples of one line being processed as described above, taken from the F-20 targeted policy:<br />
<br />
The master file_contexts.template entry:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The <tt>homedir_</tt>template entry is created as:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The file_contexts.homedirs entries are created by <tt>genhomedircon</tt> for the SELinux users extracted from the [[#modules/active/seusers.final and seusers Files | seusers]] file as follows:<br />
<pre><br />
# Home Context for any Linux user that is assigned<br />
# the SELinux user unconfined_u<br />
/home/[^/]*/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
<br />
# Home Context for user root<br />
/root/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
'''file_contexts''' - All other lines are extracted and added to the file_contexts file as they are files not associated to a users home directory. <br />
<br />
'''The format of the file_contexts.template file is as follows:'''<br />
<br />
Each line within the file consists of the following:<br />
<pre><br />
pathname_regexp [file_type] opt_security_context<br />
</pre><br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pathname_regexp<br />
| An entry that defines the pathname that may be in the form of a regular expression.<br />
<br />
The metacharacters '^' (match beginning of line) and '$' (match end of line) are automatically added to the expression by the routines that process this file, however they can be over-ridden by using '.*' at either the beginning or end of the expression (see the example file_contexts files below). <br />
<br />
There are also keywords of HOME_ROOT, HOME_DIR, ROLE and USER that are used by file labeling commands (see the keyword definitions below and the [[#modules/active/homedir_template | modules/active/homedir_template]] file section for their usage).<br />
<br />
|-<br />
| file_type<br />
| One of the following optional file_type entries (note if blank means "all file types"):<br />
<br />
'<tt>-b</tt>' - Block Device '<tt>-c</tt>' - Character Device<br />
<br />
'<tt>-d</tt>' - Directory '<tt>-p</tt>' - Named Pipe (FIFO)<br />
<br />
'<tt>-l</tt>' - Symbolic Link '<tt>-s</tt>' - Socket File<br />
<br />
'<tt>--</tt>' - Ordinary file<br />
<br />
By convention this entry is known as 'file type', however it really represents the 'file object class'.<br />
<br />
|-<br />
| opt_security_context<br />
| This entry can be either:<br />
# The security context, including the MLS / MCS level or range if applicable that will be assigned to the file.<br />
# A value of <nowiki><<none>></nowiki> can be used to indicate that matching files should not be re-labeled. <br />
<br />
|}<br />
<br />
<br />
'''Keywords that can be in the file_contexts.template file are:'''<br />
<br />
{| border="1"<br />
| HOME_ROOT<br />
| This keyword is replaced by the GNU / Linux users root home directory, normally '/home' is the default.<br />
<br />
|-<br />
| HOME_DIR<br />
| This keyword is replaced by the GNU / Linux users home directory, normally '/home/' is the default.<br />
<br />
|-<br />
| USER<br />
| This keyword will be replaced by the users GNU / Linux user id.<br />
<br />
|-<br />
| ROLE<br />
| This keyword is replaced by the 'prefix' entry from the users_extra configuration file that corresponds to the SELinux users user id. Example users_extra configuration file entries are:<br />
<pre><br />
user user_u prefix user;<br />
user staff_u prefix staff;<br />
</pre><br />
<br />
It is used for files and directories within the users home directory area. <br />
<br />
The prefix can be added by the semanage <tt>login</tt> command as follows (although note that the <tt>-P</tt> option is suppressed when help is displayed as it is generally it is not used (defaults to <tt>user</tt>) - see [http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701 http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701] for further information):<br />
<pre><br />
# Add a Linux user:<br />
adduser rch<br />
<br />
# Modify staff_u SELinux user and prefix:<br />
semanage user -m -R staff_r -P staff staff_u<br />
<br />
# Associate the SELinux user to the Linux user:<br />
semanage login -a -s staff_u rch<br />
</pre><br />
<br />
<br />
<br />
|}<br />
<br />
<br />
'''Example file_contexts.template''' '''contents from targeted policy:'''<br />
<pre><br />
# modules/active/file_contexts.template - These sample entries<br />
# have been taken from the targeted policy and show the<br />
# HOME_DIR, HOME_ROOT and USER keywords whose lines will be<br />
# extracted and added to the homedir_template file that is<br />
# used to manage user home directory entries.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
...<br />
/etc/ntop.* system_u:object_r:ntop_etc_t:s0<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/dev/dri/.+ -c system_u:object_r:dri_device_t:s0<br />
...<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
...<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
...<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts | contexts/files/file_contexts]] file and is built from entries in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file as explained above and shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that files and directories are labeled according to the policy.<br />
<br />
The format of the file_contexts file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
The USER keyword is replaced by the users GNU / Linux user id when the file labeling utilities are run.<br />
<br />
'''Example file_contexts contents:'''<br />
<pre><br />
# modules/active/file_contexts - These sample entries have<br />
# been taken from the targeted policy.<br />
# The keywords HOME_DIR, HOME_ROOT, USER and ROLE have been<br />
# removed and put in the homedir_template file.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
/xen(/.*)? system_u:object_r:xen_image_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt(/[^/]*)? -d system_u:object_r:mnt_t:s0<br />
/bin/.* system_u:object_r:bin_t:s0<br />
/dev/.* system_u:object_r:device_t:s0<br />
/usr/.* system_u:object_r:usr_t:s0<br />
/var/.* system_u:object_r:var_t:s0<br />
/run/.* system_u:object_r:var_run_t:s0<br />
/srv/.* system_u:object_r:var_t:s0<br />
/tmp/.* <<none>><br />
</pre><br />
<br />
<pre><br />
# contexts/files/file_contexts - Sample entries from the MLS reference policy. <br />
# Notes:<br />
# 1) The fixed_disk_device_t is labeled SystemHigh (s15:c0.c255)<br />
# as it needs to be trusted. Also some logs and configuration<br />
# files are labeled SystemHigh as they contain sensitive<br />
# information used by trusted applications.<br />
#<br />
# 2) Some directories (e.g. ''/tmp'') are labeled <br />
# SystemLow-SystemHigh (s0-s15:c0.c255) as they will<br />
# support polyinstantiated directories.<br />
<br />
/.*system_u:object_r:default_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt/[^/]*/.* <<none>><br />
/dev/.*mouse.* -c system_u:object_r:mouse_device_t:s0<br />
/dev/.*tty[^/]* -c system_u:object_r:tty_device_t:s0<br />
/dev/[shmx]d[^/]* -b system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/var/[xgk]dm(/.*)? system_u:object_r:xserver_log_t:s0<br />
/dev/(raw/)?rawctl -c system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/dev/pts -d system_u:object_r:devpts_t:s0-s15:c0.c255<br />
/var/log -d system_u:object_r:var_log_t:s0-s15:c0.c255<br />
/var/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/var/run -d system_u:object_r:var_run_t:s0-s15:c0.c255<br />
/usr/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
<pre><br />
<br />
== modules/active/homedir_template File ==<br />
This file is built from entries in the [[#modules/active/file_contexts.template | file_contexts.template]] file (as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram) and explained in the [[#modules/modules/active/file_contexts.template | modules/active/file_contexts.template]] section. <br />
<br />
The file is used by genhomedircon, semanage login or semanage user to generate individual user entries in the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file.<br />
<br />
The homedir_template file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example file contents:'''<br />
<pre><br />
# modules/active/homedir_template - These sample entries have <br />
# been taken from the targeted policy and show the <br />
# HOME_DIR, HOME_ROOT and USER keywords that are used to manage <br />
# users home directories:<br />
<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts.homedirs File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts.homedirs | contexts/files/file_contexts.homedirs]] file when building policy as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that users home directory areas are labeled according to the policy. <br />
<br />
The file can be built by the genhomedircon command (that just calls /usr/sbin/semodule -Bn) or if using semanage with user or login options to manage users, where it is called automatically as it is now a libsepol library function. <br />
<br />
The file_contexts.homedirs file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file, however the HOME_DIR, ROOT_DIR, <tt>ROLE</tt> and USER keywords will be replaced as explained in the keyword definitions section above.<br />
<br />
'''Example file_contexts.homedirs contents:'''<br />
<pre><br />
# modules/active/file_contexts.homedirs - These sample entries <br />
# have been taken from the targeted policy and show that <br />
# the HOME_DIR, HOME_ROOT and USER keywords have been replaced<br />
# by entries as explained above.<br />
#<br />
# Home Context for the default user (unconfined_u)<br />
/home/[^/]*/.+ unconfined_u:object_r:user_home_t:s0<br />
/home/[^/]*/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-.*/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-.* -d unconfined_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user rch<br />
/home/rch/.+ staff_u:object_r:user_home_t:s0<br />
/home/rch/.maildir(/.*)? staff_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-rch/.* -- staff_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-rch -d staff_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user root<br />
/root/.+ unconfined_u:object_r:user_home_t:s0<br />
/root/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-root/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-root -d unconfined_u:object_r:user_tmp_t:s0<br />
</pre><br />
<br />
== modules/active/netfilter_contexts & netfilter.local File ==<br />
These files are not used at present. There is code to produce a netfilter_contexts file for use by the GNU/Linux iptables service<ref name="ftn35"><sup>This uses SECMARK labeling that has been utilised by SELinux as described in the [[NB_Networking | SELinux Networking Support]] section.</sup></ref> in the Reference Policy that would generate a file similar to the example below, however there seems much debate on how they should be managed (see [https://bugzilla.redhat.com/show_bug.cgi?id=201573 bug 201573 - Secmark iptables integration] for details).<br />
<br />
== modules/active/policy.kern File ==<br />
This is the binary policy file built by either the '''semanage'''(8) or '''semodule'''(8) commands (depending on the configuration action), that then becomes the binary policy to be loaded into the kernel.<br />
<br />
== modules/active/seusers.final and seusers Files ==<br />
The seusers.final file maps GNU / Linux users to SELinux users and becomes the policies seusers<ref name="ftn36"><sup>Many seusers make confusion: The modules/active/seusers file is used to hold initial seusers entries, the modules/active/seusers.final file holds the complete entries that then becomes the policy <tt>seusers</tt> file.</sup></ref> file as discussed in the [[PolicyConfigurationFiles#seusers | seusers]] section. The seusers.final file is built or modified when:<br />
* Building a policy where an optional seusers file has been included in the base package via the '''semodule_package'''(8) command (signified by the -s flag) as follows<ref name="ftn37"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial seusers file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -s seusers ... <br />
</pre><br />
The seusers file would be extracted by the subsequent semodule command when building the policy to produce the seusers.final file.<br />
<br />
* The semanage login command is used to map GNU / Linux users to SELinux users as follows:<br />
<pre><br />
semanage login -a -s staff_u rch <br />
</pre><br />
This action will update the seusers file that would then be used to produce the seusers.final file with both policy and locally defined user mapping.<br />
<br />
It is also possible to associate a GNU / Linux group of users to an SELinux user as follows:<br />
<pre><br />
semanage login -a -s staff_u %staff_group<br />
</pre><br />
<br />
'''The format of the seusers.final & seusers files are as follows:'''<br />
<pre><br />
[%]user_id:seuser_id[:range]<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user_id<br />
| Where <tt>user_id</tt> is the GNU / Linux user identity. If this is a GNU / Linux <tt>group_id</tt> then it will be preceded with the '<tt>%</tt>' sign as shown in the example below.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| range<br />
| The optional <tt>level</tt> or range.<br />
<br />
|}<br />
<br />
<br />
'''Example seusers.final file contents:'''<br />
<pre><br />
# modules/active/seusers.final<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux user mapping:'''<br />
<pre><br />
# This command will add the rch:user_u entry in the seusers file:<br />
<br />
semanage login -a -s user_u rch<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# modules/active/seusers<br />
<br />
rch:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# /modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux group mapping:'''<br />
<pre><br />
# This command will add the %user_group:user_u entry in the seusers file: <br />
<br />
semanage login -a -s user_u %user_group<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# /modules/active/seusers<br />
<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
== modules/active/users_extra, users_extra.local and users.local Files ==<br />
These three files work together to describe SELinux user information as follows:<br />
* The users_extra and users_extra.local files are used to map a prefix to users home directories as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section, where it is used to replace the ROLE keyword. The prefix is linked to an SELinux user id and should reflect the users role. The semanage user command will allow a prefix to be added via the -P flag (although no longer used by policies as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section). <br />
<br />
The users_extra file contains all the policy prefix entries, and the users_extra.local file contains those generated by the semanage user command.<br />
<br />
The users_extra file can optionally be included in the base package via the '''semodule_package'''(8) command (signified by the -u flag) as follows<ref name="ftn38"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial users_extra file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -u users_extra ... <br />
</pre><br />
<br />
The users_extra file would then be extracted by a subsequent semodule command when building the policy.<br />
<br />
* The users.local file is used to add new SELinux users to the policy without editing the policy source itself (with each line in the file following a policy language [[KernelPolicyLanguage#user | user]] statement section). This is useful when only the Reference Policy headers are installed and additional users need to added. The semanage user command will allow a new SELinux user to be added that would generate the user.local file and if a -P flag has been specified, then a users_extra.local file is also updated (note: if this is a new SELinux user and a prefix is not specified a default prefix of user is generated). <br />
<br />
The sections that follow will:<br />
* Define the format and show example users_extra and users_extra.local files.<br />
* Execute an semanage user command that will add a new SELinux user and associated prefix, and show the resulting users_extra, users_extra.local and users.local files. <br />
<br />
Note that each line of the users.local file contains a user statement that is defined in the policy language [[KernelPolicyLanguage#user | user]] statement section, and will be built into the policy via the semanage command.<br />
<br />
'''The format of the users_extra & users_extra.local files are as follows:'''<br />
<pre><br />
user seuser_id prefix prefix_id;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user<br />
| The user keyword.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| prefix<br />
| The prefix keyword.<br />
<br />
|-<br />
| prefix_id<br />
| An identifier that will be used to replace the ROLE keyword within the modules/active/homedir_template file when building the ./modules/active/file_contexts.homedirs file for the relabeling utilities to set the security context on users home directories.<br />
<br />
|}<br />
<br />
<br />
'''Example users_extra file contents:'''<br />
<pre><br />
# modules/active/users_extra entries, note that the <br />
# users_extra.local file contents are similar and generated by <br />
# the semanage user command.<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
</pre><br />
<br />
'''Example semanage user command to add a new SELinux user:'''<br />
<pre><br />
# This command will add the user test_u prefix staff entry in <br />
# the users_extra.local file: <br />
<br />
semanage user -a -R staff_r -P staff test_u<br />
</pre><br />
<br />
'''The resulting users_extra.local file is as follows:'''<br />
<pre><br />
# modules/active/users_extra.local<br />
<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users_extra file is as follows:'''<br />
<pre><br />
# modules/active/users_extra<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users.local file is as follows:'''<br />
<pre><br />
# modules/active/users.local file entry:<br />
<br />
user test_u roles { staff_r } level s0 range s0;<br />
</pre><br />
<br />
== modules/active/booleans.local File ==<br />
This file is created and updated by the <tt>semanage boolean</tt> command and holds boolean value as requested.<br />
<br />
'''Example semanage boolean command to modify a boolean value:'''<br />
<pre><br />
# This command will add an entry in the booleans.local <br />
# file and set the boolean value to 'off': <br />
<br />
semanage boolean -m -0 ext_gateway_audit<br />
</pre><br />
<br />
'''The resulting <tt>booleans.</tt>local file would be:'''<br />
<pre><br />
# modules/active/booleans.local<br />
<br />
ext_gateway_audit=0<br />
</pre><br />
<br />
== modules/active/file_contexts.local File ==<br />
This file is created and updated by the semanage fcontext command. It is used to hold file context information on files and directories that were not delivered by the core policy (i.e. they are not defined in any of the <nowiki>*.fc</nowiki> files delivered in the base and loadable modules).<br />
<br />
The semanage command will add the information to the policy stores file_contexts.local file and then copy this file to the ./contexts/files/file_contexts.local file, where it will be used when the file context utilities are run.<br />
<br />
The format of the file_contexts.local file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example semanage fcontext command to add a new entry:'''<br />
<pre><br />
# This command will add an entry in the file_contexts.local file: <br />
<br />
semanage fcontext -a -t user_t /usr/move_file<br />
<br />
# Note that the type (-t flag) must exist in the policy <br />
# otherwise the command will fail.<br />
</pre><br />
<br />
'''The resulting file_contexts.local file would be:'''<br />
<pre><br />
# modules/active/file_contexts.local<br />
<br />
/usr/move_filesystem_u:object_r:user_t<br />
</pre><br />
<br />
== modules/active/interfaces.local File ==<br />
This file is created and updated by the semanage interface command to hold network interface information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new interface information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a netifcon statement that is defined along with examples in the [[KernelPolicyLanguage#netifcon | netifcon]] statement section.<br />
<br />
== modules/active/nodes.local File ==<br />
This file is created and updated by the semanage node command to hold network address information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new node information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a nodecon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#nodecon | nodecon]] statement section.<br />
<br />
== modules/active/ports.local File ==<br />
This file is created and updated by the semanage port command to hold network port information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new port information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a portcon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#portcon | portcon]] statement section.<br />
<br />
== modules/active/preserve_tunables File ==<br />
This file will only exist if the policy build specified that tunables should be preserved, if so they would be converted to booleans by the policy build process.<br />
<br />
== modules/active/disable_dontaudit File ==<br />
This file will only exist if the policy build specified that [[KernelPolicyLanguage#dontaudit | dontaudit]] rules should be disabled.<br />
<br />
== modules/active/modules Directory Contents ==<br />
This directory contains loadable modules (<nowiki><module_name>.pp</nowiki> or when disabled <tt><nowiki><module_name>.pp.disabled</nowiki></tt>) that have been built by the semodule_package command and placed in the store by the semodule or <tt>semanage module -a</tt> commands as shown in the following example:<br />
<pre><br />
# Package the module move_file_c:<br />
<br />
semodule_package -o move_file_c.pp -m move_file_c.mod -f move_file.fc <br />
<br />
# Then to install it in the store (at /etc/selinux/modular-test/<br />
# modules/active/modules/move_file_c.pp) and build the binary <br />
# policy file, run the semodule command:<br />
<br />
semodule -v -s modular-test -i move_file_c.pp<br />
# Or:<br />
semanage module -a -S modular-test move_file_c.pp<br />
</pre><br />
<br />
The modules within the policy store may be compressed or not depending on the value of the <tt>bzip-blocksize</tt> parameter in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The modules and their status can be listed using the <tt>semanage module -l</tt> command as shown below.<br />
<pre><br />
semanage module -l<br />
ext_gateway 1.1.0<br />
int_gateway 1.1.0<br />
move_file 1.1.0<br />
netlabel 1.0.0 Disabled<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[GlobalConfigurationFiles | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[PolicyConfigurationFiles | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/PolicyStoreConfigurationFilesPolicyStoreConfigurationFiles2015-09-25T14:24:48Z<p>RichardHaines: /* modules/active/file_contexts File */</p>
<hr />
<div>= Policy Store Configuration Files =<br />
Depending on the release being used policy stores will be located at:<br />
* <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt><nowiki> - This is the default for systems that support versions < 2.4 of </nowiki><tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>.<br />
* <tt><nowiki>/var/lib/selinux/<policy_name>/modules</nowiki></tt> - This is the default for systems that support versions >= 2.4 of <tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>. The base (<tt>/var/lib/selinux</tt>) may be overridden by the <tt>store-root</tt> parameter defined in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The migration process from previous releases is described at [https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration]. Note that once the policy store migration is complete, these files will no longer exist<br />
<br />
Note: There can be multiple policy stores on a system at <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt>.<br />
<br />
The Policy Store files are either installed, updated or built by the '''semodule'''(8) and '''semanage'''(8) commands as a part of the build process. The resulting files will either be copied over to the [[PolicyConfigurationFiles | Policy Configuration Files]] area, or used to rebuild the kernel binary policy located at <nowiki>/etc/selinux/<policy_name>/policy</nowiki>.<br />
<br />
All files may have comments inserted where each line must have the '#' symbol to indicate the start of a comment.<br />
<br />
The command options and outputs shown in the text are based on the current F-20 build.<br />
<br />
== modules/ Files ==<br />
The policy store has two lock files that are used by libsemanage for managing the store. Their format is not relevant to policy construction:<br />
<pre><br />
semanage.read.LOCK<br />
semanage.trans.LOCK<br />
</pre><br />
<br />
== modules/active/base.pp File ==<br />
This is the packaged base policy that contains the mandatory modules and policy components such as object classes, permission declarations and initial SIDs.<br />
<br />
== modules/active/base.linked File ==<br />
This is only present if the save-linked is set to <tt>TRUE</tt> as described in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | /etc/selinux/semanage.conf]] section. It contains the modules that have been linked using the <tt>'''semodule_link'''(8)</tt> command.<br />
<br />
== modules/active/commit_num File ==<br />
This is a binary file used by libsemanage for managing updates to the store. The format is not relevant to policy construction.<br />
<br />
== modules/active/file_contexts.template File ==<br />
This contains a copy all the modules 'Labeling Policy File' entries (e.g. the <nowiki><module_name>.fc</nowiki> files) that have been extracted from the [[#modules/active/base.pp | base.pp]] and the loadable modules in the [[#modules/active/modules_Directory_Contents | modules/active/modules]] directory. <br />
<br />
The entries in the file_contexts.template file are then used to build the following files as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram:<br />
# [[#modules/active/homedir_template | homedir_template]] file that will be used to produce the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file which will then become the policies ./contexts/files/file_contexts.homedirs file. <br />
# [[#modules/active/file_contexts | file_contexts]] file that will become the policies file_contexts file.<br />
<br />
Note that as a part of the <tt>semanage</tt> build process, these two files will also have <tt>file_contexts.bin</tt> and <tt>file_contexts.homedirs.bin</tt> files present in the [[PolicyConfigurationFiles#contexts/files/file_contexts File | Policy Configuration Files]] <tt>contexts/files</tt> directory. This is because <tt>semanage</tt> requires these in the Perl compatible regular expression (PCRE) internal format. They are generated by the <tt>'''sefcontext_compile'''(8)</tt> utility.<br />
<br />
The homedir_template and file_contexts files are built is as follows:<br />
: '''homedir_template''' - Any line in the file_contexts.template file that has the keywords HOME_ROOT, HOME_DIR and/or USER are extracted and added to the homedir_template file. This is because these keywords are used to identify entries that are associated to a users home directory area. These lines may also have the ROLE keyword declared.<br />
: The homedir_template file will then be processed by '''genhomedircon'''(8)<ref name="ftn34"><sup>The genhomedircon command has now been built into the libsemanage library as a function to build the file_contexts.homedirs file via '''semanage'''(8).</sup></ref> to generate individual SELinux user entries in the file_contexts.homedirs file as discussed in the [[#modules/active/file_contexts.homedirs | modules/active/file_contexts.homedirs]] section.<br />
<br />
These are examples of one line being processed as described above, taken from the F-20 targeted policy:<br />
<br />
The master file_contexts.template entry:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The <tt>homedir_</tt>template entry is created as:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The file_contexts.homedirs entries are created by <tt>genhomedircon</tt> for the SELinux users extracted from the [[#modules/active/seusers.final and seusers Files | seusers]] file as follows:<br />
<pre><br />
# Home Context for any Linux user that is assigned<br />
# the SELinux user unconfined_u<br />
/home/[^/]*/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
<br />
# Home Context for user root<br />
/root/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
'''file_contexts''' - All other lines are extracted and added to the file_contexts file as they are files not associated to a users home directory. <br />
<br />
'''The format of the file_contexts.template file is as follows:'''<br />
<br />
Each line within the file consists of the following:<br />
<pre><br />
pathname_regexp [file_type] opt_security_context<br />
</pre><br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pathname_regexp<br />
| An entry that defines the pathname that may be in the form of a regular expression.<br />
<br />
The metacharacters '^' (match beginning of line) and '$' (match end of line) are automatically added to the expression by the routines that process this file, however they can be over-ridden by using '.*' at either the beginning or end of the expression (see the example file_contexts files below). <br />
<br />
There are also keywords of HOME_ROOT, HOME_DIR, ROLE and USER that are used by file labeling commands (see the keyword definitions below and the [[#modules/active/homedir_template | modules/active/homedir_template]] file section for their usage).<br />
<br />
|-<br />
| file_type<br />
| One of the following optional file_type entries (note if blank means "all file types"):<br />
<br />
'<tt>-b</tt>' - Block Device '<tt>-c</tt>' - Character Device<br />
<br />
'<tt>-d</tt>' - Directory '<tt>-p</tt>' - Named Pipe (FIFO)<br />
<br />
'<tt>-l</tt>' - Symbolic Link '<tt>-s</tt>' - Socket File<br />
<br />
'<tt>--</tt>' - Ordinary file<br />
<br />
By convention this entry is known as 'file type', however it really represents the 'file object class'.<br />
<br />
|-<br />
| opt_security_context<br />
| This entry can be either:<br />
# The security context, including the MLS / MCS level or range if applicable that will be assigned to the file.<br />
# A value of <nowiki><<none>></nowiki> can be used to indicate that matching files should not be re-labeled. <br />
<br />
|}<br />
<br />
<br />
'''Keywords that can be in the file_contexts.template file are:'''<br />
<br />
{| border="1"<br />
| HOME_ROOT<br />
| This keyword is replaced by the GNU / Linux users root home directory, normally '/home' is the default.<br />
<br />
|-<br />
| HOME_DIR<br />
| This keyword is replaced by the GNU / Linux users home directory, normally '/home/' is the default.<br />
<br />
|-<br />
| USER<br />
| This keyword will be replaced by the users GNU / Linux user id.<br />
<br />
|-<br />
| ROLE<br />
| This keyword is replaced by the 'prefix' entry from the users_extra configuration file that corresponds to the SELinux users user id. Example users_extra configuration file entries are:<br />
<pre><br />
user user_u prefix user;<br />
user staff_u prefix staff;<br />
</pre><br />
<br />
It is used for files and directories within the users home directory area. <br />
<br />
The prefix can be added by the semanage <tt>login</tt> command as follows (although note that the <tt>-P</tt> option is suppressed when help is displayed as it is generally it is not used (defaults to <tt>user</tt>) - see [http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701 http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701] for further information):<br />
<pre><br />
# Add a Linux user:<br />
adduser rch<br />
<br />
# Modify staff_u SELinux user and prefix:<br />
semanage user -m -R staff_r -P staff staff_u<br />
<br />
# Associate the SELinux user to the Linux user:<br />
semanage login -a -s staff_u rch<br />
</pre><br />
<br />
<br />
<br />
|}<br />
<br />
<br />
'''Example file_contexts.template''' '''contents from targeted policy:'''<br />
<pre><br />
# modules/active/file_contexts.template - These sample entries<br />
# have been taken from the targeted policy and show the<br />
# HOME_DIR, HOME_ROOT and USER keywords whose lines will be<br />
# extracted and added to the homedir_template file that is<br />
# used to manage user home directory entries.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
...<br />
/etc/ntop.* system_u:object_r:ntop_etc_t:s0<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/dev/dri/.+ -c system_u:object_r:dri_device_t:s0<br />
...<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
...<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
...<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts | contexts/files/file_contexts]] file and is built from entries in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file as explained above and shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that files and directories are labeled according to the policy.<br />
<br />
The format of the file_contexts file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
The USER keyword is replaced by the users GNU / Linux user id when the file labeling utilities are run.<br />
<br />
'''Example file_contexts contents:'''<br />
<pre><br />
# modules/active/file_contexts - These sample entries have<br />
# been taken from the targeted policy.<br />
# The keywords HOME_DIR, HOME_ROOT, USER and ROLE have been<br />
# removed and put in the homedir_template file.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
/xen(/.*)? system_u:object_r:xen_image_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt(/[^/]*)? -d system_u:object_r:mnt_t:s0<br />
/bin/.* system_u:object_r:bin_t:s0<br />
/dev/.* system_u:object_r:device_t:s0<br />
/usr/.* system_u:object_r:usr_t:s0<br />
/var/.* system_u:object_r:var_t:s0<br />
/run/.* system_u:object_r:var_run_t:s0<br />
/srv/.* system_u:object_r:var_t:s0<br />
/tmp/.* <<none>><br />
</pre><br />
<br />
<pre><br />
# contexts/files/file_contexts - Sample entries from the MLS reference policy. <br />
# Notes:<br />
# 1) The fixed_disk_device_t is labeled SystemHigh (s15:c0.c255)<br />
# as it needs to be trusted. Also some logs and configuration<br />
# files are labeled SystemHigh as they contain sensitive<br />
# information used by trusted applications.<br />
#<br />
# 2) Some directories (e.g. ''/tmp'') are labeled <br />
# SystemLow-SystemHigh (s0-s15:c0.c255) as they will<br />
# support polyinstantiated directories.<br />
<br />
/.*system_u:object_r:default_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt/[^/]*/.* <<none>><br />
/dev/.*mouse.* -c system_u:object_r:mouse_device_t:s0<br />
/dev/.*tty[^/]* -c system_u:object_r:tty_device_t:s0<br />
/dev/[shmx]d[^/]* -b system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/var/[xgk]dm(/.*)? system_u:object_r:xserver_log_t:s0<br />
/dev/(raw/)?rawctl -c system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/dev/pts -d system_u:object_r:devpts_t:s0-s15:c0.c255<br />
/var/log -d system_u:object_r:var_log_t:s0-s15:c0.c255<br />
/var/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/var/run -d system_u:object_r:var_run_t:s0-s15:c0.c255<br />
/usr/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
<pre><br />
<br />
== modules/active/homedir_template File ==<br />
This file is built from entries in the [[#modules/active/file_contexts.template | file_contexts.template]] file (as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram) and explained in the [[#modules/modules/active/file_contexts.template | modules/active/file_contexts.template]] section. <br />
<br />
The file is used by genhomedircon, semanage login or semanage user to generate individual user entries in the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file.<br />
<br />
The homedir_template file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example file contents:'''<br />
<pre><br />
# modules/active/homedir_template - These sample entries have <br />
# been taken from the targeted policy and show the <br />
# HOME_DIR, HOME_ROOT and USER keywords that are used to manage <br />
# users home directories:<br />
<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts.homedirs File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts.homedirs | contexts/files/file_contexts.homedirs]] file when building policy as shown in the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that users home directory areas are labeled according to the policy. <br />
<br />
The file can be built by the genhomedircon command (that just calls /usr/sbin/semodule -Bn) or if using semanage with user or login options to manage users, where it is called automatically as it is now a libsepol library function. <br />
<br />
The file_contexts.homedirs file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file, however the HOME_DIR, ROOT_DIR, <tt>ROLE</tt> and USER keywords will be replaced as explained in the keyword definitions section above.<br />
<br />
'''Example file_contexts.homedirs contents:'''<br />
<pre><br />
# modules/active/file_contexts.homedirs - These sample entries <br />
# have been taken from the targeted policy and show that <br />
# the HOME_DIR, HOME_ROOT and USER keywords have been replaced<br />
# by entries as explained above.<br />
#<br />
# Home Context for the default user (unconfined_u)<br />
/home/[^/]*/.+ unconfined_u:object_r:user_home_t:s0<br />
/home/[^/]*/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-.*/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-.* -d unconfined_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user rch<br />
/home/rch/.+ staff_u:object_r:user_home_t:s0<br />
/home/rch/.maildir(/.*)? staff_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-rch/.* -- staff_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-rch -d staff_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user root<br />
/root/.+ unconfined_u:object_r:user_home_t:s0<br />
/root/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-root/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-root -d unconfined_u:object_r:user_tmp_t:s0<br />
</pre><br />
<br />
== modules/active/netfilter_contexts & netfilter.local File ==<br />
These files are not used at present. There is code to produce a netfilter_contexts file for use by the GNU/Linux iptables service<ref name="ftn35"><sup>This uses SECMARK labeling that has been utilised by SELinux as described in the [[NB_Networking | SELinux Networking Support]] section.</sup></ref> in the Reference Policy that would generate a file similar to the example below, however there seems much debate on how they should be managed (see [https://bugzilla.redhat.com/show_bug.cgi?id=201573 bug 201573 - Secmark iptables integration] for details).<br />
<br />
== modules/active/policy.kern File ==<br />
This is the binary policy file built by either the '''semanage'''(8) or '''semodule'''(8) commands (depending on the configuration action), that then becomes the binary policy to be loaded into the kernel.<br />
<br />
== modules/active/seusers.final and seusers Files ==<br />
The seusers.final file maps GNU / Linux users to SELinux users and becomes the policies seusers<ref name="ftn36"><sup>Many seusers make confusion: The modules/active/seusers file is used to hold initial seusers entries, the modules/active/seusers.final file holds the complete entries that then becomes the policy <tt>seusers</tt> file.</sup></ref> file as discussed in the [[PolicyConfigurationFiles#seusers | seusers]] section. The seusers.final file is built or modified when:<br />
* Building a policy where an optional seusers file has been included in the base package via the '''semodule_package'''(8) command (signified by the -s flag) as follows<ref name="ftn37"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial seusers file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -s seusers ... <br />
</pre><br />
The seusers file would be extracted by the subsequent semodule command when building the policy to produce the seusers.final file.<br />
<br />
* The semanage login command is used to map GNU / Linux users to SELinux users as follows:<br />
<pre><br />
semanage login -a -s staff_u rch <br />
</pre><br />
This action will update the seusers file that would then be used to produce the seusers.final file with both policy and locally defined user mapping.<br />
<br />
It is also possible to associate a GNU / Linux group of users to an SELinux user as follows:<br />
<pre><br />
semanage login -a -s staff_u %staff_group<br />
</pre><br />
<br />
'''The format of the seusers.final & seusers files are as follows:'''<br />
<pre><br />
[%]user_id:seuser_id[:range]<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user_id<br />
| Where <tt>user_id</tt> is the GNU / Linux user identity. If this is a GNU / Linux <tt>group_id</tt> then it will be preceded with the '<tt>%</tt>' sign as shown in the example below.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| range<br />
| The optional <tt>level</tt> or range.<br />
<br />
|}<br />
<br />
<br />
'''Example seusers.final file contents:'''<br />
<pre><br />
# modules/active/seusers.final<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux user mapping:'''<br />
<pre><br />
# This command will add the rch:user_u entry in the seusers file:<br />
<br />
semanage login -a -s user_u rch<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# modules/active/seusers<br />
<br />
rch:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# /modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux group mapping:'''<br />
<pre><br />
# This command will add the %user_group:user_u entry in the seusers file: <br />
<br />
semanage login -a -s user_u %user_group<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# /modules/active/seusers<br />
<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
== modules/active/users_extra, users_extra.local and users.local Files ==<br />
These three files work together to describe SELinux user information as follows:<br />
* The users_extra and users_extra.local files are used to map a prefix to users home directories as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section, where it is used to replace the ROLE keyword. The prefix is linked to an SELinux user id and should reflect the users role. The semanage user command will allow a prefix to be added via the -P flag (although no longer used by policies as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section). <br />
<br />
The users_extra file contains all the policy prefix entries, and the users_extra.local file contains those generated by the semanage user command.<br />
<br />
The users_extra file can optionally be included in the base package via the '''semodule_package'''(8) command (signified by the -u flag) as follows<ref name="ftn38"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial users_extra file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -u users_extra ... <br />
</pre><br />
<br />
The users_extra file would then be extracted by a subsequent semodule command when building the policy.<br />
<br />
* The users.local file is used to add new SELinux users to the policy without editing the policy source itself (with each line in the file following a policy language [[KernelPolicyLanguage#user | user]] statement section). This is useful when only the Reference Policy headers are installed and additional users need to added. The semanage user command will allow a new SELinux user to be added that would generate the user.local file and if a -P flag has been specified, then a users_extra.local file is also updated (note: if this is a new SELinux user and a prefix is not specified a default prefix of user is generated). <br />
<br />
The sections that follow will:<br />
* Define the format and show example users_extra and users_extra.local files.<br />
* Execute an semanage user command that will add a new SELinux user and associated prefix, and show the resulting users_extra, users_extra.local and users.local files. <br />
<br />
Note that each line of the users.local file contains a user statement that is defined in the policy language [[KernelPolicyLanguage#user | user]] statement section, and will be built into the policy via the semanage command.<br />
<br />
'''The format of the users_extra & users_extra.local files are as follows:'''<br />
<pre><br />
user seuser_id prefix prefix_id;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user<br />
| The user keyword.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| prefix<br />
| The prefix keyword.<br />
<br />
|-<br />
| prefix_id<br />
| An identifier that will be used to replace the ROLE keyword within the modules/active/homedir_template file when building the ./modules/active/file_contexts.homedirs file for the relabeling utilities to set the security context on users home directories.<br />
<br />
|}<br />
<br />
<br />
'''Example users_extra file contents:'''<br />
<pre><br />
# modules/active/users_extra entries, note that the <br />
# users_extra.local file contents are similar and generated by <br />
# the semanage user command.<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
</pre><br />
<br />
'''Example semanage user command to add a new SELinux user:'''<br />
<pre><br />
# This command will add the user test_u prefix staff entry in <br />
# the users_extra.local file: <br />
<br />
semanage user -a -R staff_r -P staff test_u<br />
</pre><br />
<br />
'''The resulting users_extra.local file is as follows:'''<br />
<pre><br />
# modules/active/users_extra.local<br />
<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users_extra file is as follows:'''<br />
<pre><br />
# modules/active/users_extra<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users.local file is as follows:'''<br />
<pre><br />
# modules/active/users.local file entry:<br />
<br />
user test_u roles { staff_r } level s0 range s0;<br />
</pre><br />
<br />
== modules/active/booleans.local File ==<br />
This file is created and updated by the <tt>semanage boolean</tt> command and holds boolean value as requested.<br />
<br />
'''Example semanage boolean command to modify a boolean value:'''<br />
<pre><br />
# This command will add an entry in the booleans.local <br />
# file and set the boolean value to 'off': <br />
<br />
semanage boolean -m -0 ext_gateway_audit<br />
</pre><br />
<br />
'''The resulting <tt>booleans.</tt>local file would be:'''<br />
<pre><br />
# modules/active/booleans.local<br />
<br />
ext_gateway_audit=0<br />
</pre><br />
<br />
== modules/active/file_contexts.local File ==<br />
This file is created and updated by the semanage fcontext command. It is used to hold file context information on files and directories that were not delivered by the core policy (i.e. they are not defined in any of the <nowiki>*.fc</nowiki> files delivered in the base and loadable modules).<br />
<br />
The semanage command will add the information to the policy stores file_contexts.local file and then copy this file to the ./contexts/files/file_contexts.local file, where it will be used when the file context utilities are run.<br />
<br />
The format of the file_contexts.local file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example semanage fcontext command to add a new entry:'''<br />
<pre><br />
# This command will add an entry in the file_contexts.local file: <br />
<br />
semanage fcontext -a -t user_t /usr/move_file<br />
<br />
# Note that the type (-t flag) must exist in the policy <br />
# otherwise the command will fail.<br />
</pre><br />
<br />
'''The resulting file_contexts.local file would be:'''<br />
<pre><br />
# modules/active/file_contexts.local<br />
<br />
/usr/move_filesystem_u:object_r:user_t<br />
</pre><br />
<br />
== modules/active/interfaces.local File ==<br />
This file is created and updated by the semanage interface command to hold network interface information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new interface information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a netifcon statement that is defined along with examples in the [[KernelPolicyLanguage#netifcon | netifcon]] statement section.<br />
<br />
== modules/active/nodes.local File ==<br />
This file is created and updated by the semanage node command to hold network address information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new node information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a nodecon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#nodecon | nodecon]] statement section.<br />
<br />
== modules/active/ports.local File ==<br />
This file is created and updated by the semanage port command to hold network port information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new port information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a portcon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#portcon | portcon]] statement section.<br />
<br />
== modules/active/preserve_tunables File ==<br />
This file will only exist if the policy build specified that tunables should be preserved, if so they would be converted to booleans by the policy build process.<br />
<br />
== modules/active/disable_dontaudit File ==<br />
This file will only exist if the policy build specified that [[KernelPolicyLanguage#dontaudit | dontaudit]] rules should be disabled.<br />
<br />
== modules/active/modules Directory Contents ==<br />
This directory contains loadable modules (<nowiki><module_name>.pp</nowiki> or when disabled <tt><nowiki><module_name>.pp.disabled</nowiki></tt>) that have been built by the semodule_package command and placed in the store by the semodule or <tt>semanage module -a</tt> commands as shown in the following example:<br />
<pre><br />
# Package the module move_file_c:<br />
<br />
semodule_package -o move_file_c.pp -m move_file_c.mod -f move_file.fc <br />
<br />
# Then to install it in the store (at /etc/selinux/modular-test/<br />
# modules/active/modules/move_file_c.pp) and build the binary <br />
# policy file, run the semodule command:<br />
<br />
semodule -v -s modular-test -i move_file_c.pp<br />
# Or:<br />
semanage module -a -S modular-test move_file_c.pp<br />
</pre><br />
<br />
The modules within the policy store may be compressed or not depending on the value of the <tt>bzip-blocksize</tt> parameter in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The modules and their status can be listed using the <tt>semanage module -l</tt> command as shown below.<br />
<pre><br />
semanage module -l<br />
ext_gateway 1.1.0<br />
int_gateway 1.1.0<br />
move_file 1.1.0<br />
netlabel 1.0.0 Disabled<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[GlobalConfigurationFiles | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[PolicyConfigurationFiles | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/PolicyStoreConfigurationFilesPolicyStoreConfigurationFiles2015-09-25T14:23:46Z<p>RichardHaines: /* modules/active/file_contexts.template File */</p>
<hr />
<div>= Policy Store Configuration Files =<br />
Depending on the release being used policy stores will be located at:<br />
* <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt><nowiki> - This is the default for systems that support versions < 2.4 of </nowiki><tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>.<br />
* <tt><nowiki>/var/lib/selinux/<policy_name>/modules</nowiki></tt> - This is the default for systems that support versions >= 2.4 of <tt>libsemanage</tt>, <tt>libsepol</tt>, and <tt>policycoreutils</tt>. The base (<tt>/var/lib/selinux</tt>) may be overridden by the <tt>store-root</tt> parameter defined in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The migration process from previous releases is described at [https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration]. Note that once the policy store migration is complete, these files will no longer exist<br />
<br />
Note: There can be multiple policy stores on a system at <tt><nowiki>/etc/selinux/<policy_name>/modules</nowiki></tt>.<br />
<br />
The Policy Store files are either installed, updated or built by the '''semodule'''(8) and '''semanage'''(8) commands as a part of the build process. The resulting files will either be copied over to the [[PolicyConfigurationFiles | Policy Configuration Files]] area, or used to rebuild the kernel binary policy located at <nowiki>/etc/selinux/<policy_name>/policy</nowiki>.<br />
<br />
All files may have comments inserted where each line must have the '#' symbol to indicate the start of a comment.<br />
<br />
The command options and outputs shown in the text are based on the current F-20 build.<br />
<br />
== modules/ Files ==<br />
The policy store has two lock files that are used by libsemanage for managing the store. Their format is not relevant to policy construction:<br />
<pre><br />
semanage.read.LOCK<br />
semanage.trans.LOCK<br />
</pre><br />
<br />
== modules/active/base.pp File ==<br />
This is the packaged base policy that contains the mandatory modules and policy components such as object classes, permission declarations and initial SIDs.<br />
<br />
== modules/active/base.linked File ==<br />
This is only present if the save-linked is set to <tt>TRUE</tt> as described in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | /etc/selinux/semanage.conf]] section. It contains the modules that have been linked using the <tt>'''semodule_link'''(8)</tt> command.<br />
<br />
== modules/active/commit_num File ==<br />
This is a binary file used by libsemanage for managing updates to the store. The format is not relevant to policy construction.<br />
<br />
== modules/active/file_contexts.template File ==<br />
This contains a copy all the modules 'Labeling Policy File' entries (e.g. the <nowiki><module_name>.fc</nowiki> files) that have been extracted from the [[#modules/active/base.pp | base.pp]] and the loadable modules in the [[#modules/active/modules_Directory_Contents | modules/active/modules]] directory. <br />
<br />
The entries in the file_contexts.template file are then used to build the following files as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram:<br />
# [[#modules/active/homedir_template | homedir_template]] file that will be used to produce the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file which will then become the policies ./contexts/files/file_contexts.homedirs file. <br />
# [[#modules/active/file_contexts | file_contexts]] file that will become the policies file_contexts file.<br />
<br />
Note that as a part of the <tt>semanage</tt> build process, these two files will also have <tt>file_contexts.bin</tt> and <tt>file_contexts.homedirs.bin</tt> files present in the [[PolicyConfigurationFiles#contexts/files/file_contexts File | Policy Configuration Files]] <tt>contexts/files</tt> directory. This is because <tt>semanage</tt> requires these in the Perl compatible regular expression (PCRE) internal format. They are generated by the <tt>'''sefcontext_compile'''(8)</tt> utility.<br />
<br />
The homedir_template and file_contexts files are built is as follows:<br />
: '''homedir_template''' - Any line in the file_contexts.template file that has the keywords HOME_ROOT, HOME_DIR and/or USER are extracted and added to the homedir_template file. This is because these keywords are used to identify entries that are associated to a users home directory area. These lines may also have the ROLE keyword declared.<br />
: The homedir_template file will then be processed by '''genhomedircon'''(8)<ref name="ftn34"><sup>The genhomedircon command has now been built into the libsemanage library as a function to build the file_contexts.homedirs file via '''semanage'''(8).</sup></ref> to generate individual SELinux user entries in the file_contexts.homedirs file as discussed in the [[#modules/active/file_contexts.homedirs | modules/active/file_contexts.homedirs]] section.<br />
<br />
These are examples of one line being processed as described above, taken from the F-20 targeted policy:<br />
<br />
The master file_contexts.template entry:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The <tt>homedir_</tt>template entry is created as:<br />
<pre><br />
HOME_DIR\/.wine(/.*)? system_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
The file_contexts.homedirs entries are created by <tt>genhomedircon</tt> for the SELinux users extracted from the [[#modules/active/seusers.final and seusers Files | seusers]] file as follows:<br />
<pre><br />
# Home Context for any Linux user that is assigned<br />
# the SELinux user unconfined_u<br />
/home/[^/]*/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
<br />
# Home Context for user root<br />
/root/\.wine(/.*)? unconfined_u:object_r:wine_home_t:s0<br />
</pre><br />
<br />
'''file_contexts''' - All other lines are extracted and added to the file_contexts file as they are files not associated to a users home directory. <br />
<br />
'''The format of the file_contexts.template file is as follows:'''<br />
<br />
Each line within the file consists of the following:<br />
<pre><br />
pathname_regexp [file_type] opt_security_context<br />
</pre><br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pathname_regexp<br />
| An entry that defines the pathname that may be in the form of a regular expression.<br />
<br />
The metacharacters '^' (match beginning of line) and '$' (match end of line) are automatically added to the expression by the routines that process this file, however they can be over-ridden by using '.*' at either the beginning or end of the expression (see the example file_contexts files below). <br />
<br />
There are also keywords of HOME_ROOT, HOME_DIR, ROLE and USER that are used by file labeling commands (see the keyword definitions below and the [[#modules/active/homedir_template | modules/active/homedir_template]] file section for their usage).<br />
<br />
|-<br />
| file_type<br />
| One of the following optional file_type entries (note if blank means "all file types"):<br />
<br />
'<tt>-b</tt>' - Block Device '<tt>-c</tt>' - Character Device<br />
<br />
'<tt>-d</tt>' - Directory '<tt>-p</tt>' - Named Pipe (FIFO)<br />
<br />
'<tt>-l</tt>' - Symbolic Link '<tt>-s</tt>' - Socket File<br />
<br />
'<tt>--</tt>' - Ordinary file<br />
<br />
By convention this entry is known as 'file type', however it really represents the 'file object class'.<br />
<br />
|-<br />
| opt_security_context<br />
| This entry can be either:<br />
# The security context, including the MLS / MCS level or range if applicable that will be assigned to the file.<br />
# A value of <nowiki><<none>></nowiki> can be used to indicate that matching files should not be re-labeled. <br />
<br />
|}<br />
<br />
<br />
'''Keywords that can be in the file_contexts.template file are:'''<br />
<br />
{| border="1"<br />
| HOME_ROOT<br />
| This keyword is replaced by the GNU / Linux users root home directory, normally '/home' is the default.<br />
<br />
|-<br />
| HOME_DIR<br />
| This keyword is replaced by the GNU / Linux users home directory, normally '/home/' is the default.<br />
<br />
|-<br />
| USER<br />
| This keyword will be replaced by the users GNU / Linux user id.<br />
<br />
|-<br />
| ROLE<br />
| This keyword is replaced by the 'prefix' entry from the users_extra configuration file that corresponds to the SELinux users user id. Example users_extra configuration file entries are:<br />
<pre><br />
user user_u prefix user;<br />
user staff_u prefix staff;<br />
</pre><br />
<br />
It is used for files and directories within the users home directory area. <br />
<br />
The prefix can be added by the semanage <tt>login</tt> command as follows (although note that the <tt>-P</tt> option is suppressed when help is displayed as it is generally it is not used (defaults to <tt>user</tt>) - see [http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701 http://blog.gmane.org/gmane.linux.redhat.fedora.selinux/month=20110701] for further information):<br />
<pre><br />
# Add a Linux user:<br />
adduser rch<br />
<br />
# Modify staff_u SELinux user and prefix:<br />
semanage user -m -R staff_r -P staff staff_u<br />
<br />
# Associate the SELinux user to the Linux user:<br />
semanage login -a -s staff_u rch<br />
</pre><br />
<br />
<br />
<br />
|}<br />
<br />
<br />
'''Example file_contexts.template''' '''contents from targeted policy:'''<br />
<pre><br />
# modules/active/file_contexts.template - These sample entries<br />
# have been taken from the targeted policy and show the<br />
# HOME_DIR, HOME_ROOT and USER keywords whose lines will be<br />
# extracted and added to the homedir_template file that is<br />
# used to manage user home directory entries.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
...<br />
/etc/ntop.* system_u:object_r:ntop_etc_t:s0<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/dev/dri/.+ -c system_u:object_r:dri_device_t:s0<br />
...<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
...<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
...<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
== modules/active/file_contexts File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts | contexts/files/file_contexts]] file and is built from entries in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file as explained above and shown in the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that files and directories are labeled according to the policy.<br />
<br />
The format of the file_contexts file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
The USER keyword is replaced by the users GNU / Linux user id when the file labeling utilities are run.<br />
<br />
'''Example file_contexts contents:'''<br />
<pre><br />
# modules/active/file_contexts - These sample entries have<br />
# been taken from the targeted policy.<br />
# The keywords HOME_DIR, HOME_ROOT, USER and ROLE have been<br />
# removed and put in the homedir_template file.<br />
<br />
/.* system_u:object_r:default_t:s0<br />
/[^/]+ -- system_u:object_r:etc_runtime_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/nsr(/.*)? system_u:object_r:var_t:s0<br />
/sys(/.*)? system_u:object_r:sysfs_t:s0<br />
/xen(/.*)? system_u:object_r:xen_image_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt(/[^/]*)? -d system_u:object_r:mnt_t:s0<br />
/bin/.* system_u:object_r:bin_t:s0<br />
/dev/.* system_u:object_r:device_t:s0<br />
/usr/.* system_u:object_r:usr_t:s0<br />
/var/.* system_u:object_r:var_t:s0<br />
/run/.* system_u:object_r:var_run_t:s0<br />
/srv/.* system_u:object_r:var_t:s0<br />
/tmp/.* <<none>><br />
</pre><br />
<br />
<pre><br />
# contexts/files/file_contexts - Sample entries from the MLS reference policy. <br />
# Notes:<br />
# 1) The fixed_disk_device_t is labeled SystemHigh (s15:c0.c255)<br />
# as it needs to be trusted. Also some logs and configuration<br />
# files are labeled SystemHigh as they contain sensitive<br />
# information used by trusted applications.<br />
#<br />
# 2) Some directories (e.g. ''/tmp'') are labeled <br />
# SystemLow-SystemHigh (s0-s15:c0.c255) as they will<br />
# support polyinstantiated directories.<br />
<br />
/.*system_u:object_r:default_t:s0<br />
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0<br />
/mnt(/[^/]*) -l system_u:object_r:mnt_t:s0<br />
/mnt/[^/]*/.* <<none>><br />
/dev/.*mouse.* -c system_u:object_r:mouse_device_t:s0<br />
/dev/.*tty[^/]* -c system_u:object_r:tty_device_t:s0<br />
/dev/[shmx]d[^/]* -b system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/var/[xgk]dm(/.*)? system_u:object_r:xserver_log_t:s0<br />
/dev/(raw/)?rawctl -c system_u:object_r:fixed_disk_device_t:s15:c0.c255<br />
/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/dev/pts -d system_u:object_r:devpts_t:s0-s15:c0.c255<br />
/var/log -d system_u:object_r:var_log_t:s0-s15:c0.c255<br />
/var/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
/var/run -d system_u:object_r:var_run_t:s0-s15:c0.c255<br />
/usr/tmp -d system_u:object_r:tmp_t:s0-s15:c0.c255<br />
<pre><br />
<br />
== modules/active/homedir_template File ==<br />
This file is built from entries in the [[#modules/active/file_contexts.template | file_contexts.template]] file (as shown in the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram) and explained in the [[#modules/modules/active/file_contexts.template | modules/active/file_contexts.template]] section. <br />
<br />
The file is used by genhomedircon, semanage login or semanage user to generate individual user entries in the [[#modules/active/file_contexts.homedirs | file_contexts.homedirs]] file.<br />
<br />
The homedir_template file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example file contents:'''<br />
<pre><br />
# modules/active/homedir_template - These sample entries have <br />
# been taken from the targeted policy and show the <br />
# HOME_DIR, HOME_ROOT and USER keywords that are used to manage <br />
# users home directories:<br />
<br />
HOME_DIR/.+ system_u:object_r:user_home_t:s0<br />
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0<br />
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0<br />
HOME_ROOT/\.journal <<none>><br />
</pre><br />
<br />
<br />
== modules/active/file_contexts.homedirs File ==<br />
This file becomes the policies [[PolicyConfigurationFiles#contexts/files/file_contexts.homedirs | contexts/files/file_contexts.homedirs]] file when building policy as shown in the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/25-file_contexts.png File Context Configuration Files] diagram. It is then used by the file labeling utilities to ensure that users home directory areas are labeled according to the policy. <br />
<br />
The file can be built by the genhomedircon command (that just calls /usr/sbin/semodule -Bn) or if using semanage with user or login options to manage users, where it is called automatically as it is now a libsepol library function. <br />
<br />
The file_contexts.homedirs file has the same per line format as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file, however the HOME_DIR, ROOT_DIR, <tt>ROLE</tt> and USER keywords will be replaced as explained in the keyword definitions section above.<br />
<br />
'''Example file_contexts.homedirs contents:'''<br />
<pre><br />
# modules/active/file_contexts.homedirs - These sample entries <br />
# have been taken from the targeted policy and show that <br />
# the HOME_DIR, HOME_ROOT and USER keywords have been replaced<br />
# by entries as explained above.<br />
#<br />
# Home Context for the default user (unconfined_u)<br />
/home/[^/]*/.+ unconfined_u:object_r:user_home_t:s0<br />
/home/[^/]*/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-.*/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-.* -d unconfined_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user rch<br />
/home/rch/.+ staff_u:object_r:user_home_t:s0<br />
/home/rch/.maildir(/.*)? staff_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-rch/.* -- staff_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-rch -d staff_u:object_r:user_tmp_t:s0<br />
<br />
# Home Context for user root<br />
/root/.+ unconfined_u:object_r:user_home_t:s0<br />
/root/.maildir(/.*)? unconfined_u:object_r:mail_home_rw_t:s0<br />
...<br />
/tmp/gconfd-root/.* -- unconfined_u:object_r:gconf_tmp_t:s0<br />
/tmp/gconfd-root -d unconfined_u:object_r:user_tmp_t:s0<br />
</pre><br />
<br />
== modules/active/netfilter_contexts & netfilter.local File ==<br />
These files are not used at present. There is code to produce a netfilter_contexts file for use by the GNU/Linux iptables service<ref name="ftn35"><sup>This uses SECMARK labeling that has been utilised by SELinux as described in the [[NB_Networking | SELinux Networking Support]] section.</sup></ref> in the Reference Policy that would generate a file similar to the example below, however there seems much debate on how they should be managed (see [https://bugzilla.redhat.com/show_bug.cgi?id=201573 bug 201573 - Secmark iptables integration] for details).<br />
<br />
== modules/active/policy.kern File ==<br />
This is the binary policy file built by either the '''semanage'''(8) or '''semodule'''(8) commands (depending on the configuration action), that then becomes the binary policy to be loaded into the kernel.<br />
<br />
== modules/active/seusers.final and seusers Files ==<br />
The seusers.final file maps GNU / Linux users to SELinux users and becomes the policies seusers<ref name="ftn36"><sup>Many seusers make confusion: The modules/active/seusers file is used to hold initial seusers entries, the modules/active/seusers.final file holds the complete entries that then becomes the policy <tt>seusers</tt> file.</sup></ref> file as discussed in the [[PolicyConfigurationFiles#seusers | seusers]] section. The seusers.final file is built or modified when:<br />
* Building a policy where an optional seusers file has been included in the base package via the '''semodule_package'''(8) command (signified by the -s flag) as follows<ref name="ftn37"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial seusers file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -s seusers ... <br />
</pre><br />
The seusers file would be extracted by the subsequent semodule command when building the policy to produce the seusers.final file.<br />
<br />
* The semanage login command is used to map GNU / Linux users to SELinux users as follows:<br />
<pre><br />
semanage login -a -s staff_u rch <br />
</pre><br />
This action will update the seusers file that would then be used to produce the seusers.final file with both policy and locally defined user mapping.<br />
<br />
It is also possible to associate a GNU / Linux group of users to an SELinux user as follows:<br />
<pre><br />
semanage login -a -s staff_u %staff_group<br />
</pre><br />
<br />
'''The format of the seusers.final & seusers files are as follows:'''<br />
<pre><br />
[%]user_id:seuser_id[:range]<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user_id<br />
| Where <tt>user_id</tt> is the GNU / Linux user identity. If this is a GNU / Linux <tt>group_id</tt> then it will be preceded with the '<tt>%</tt>' sign as shown in the example below.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| range<br />
| The optional <tt>level</tt> or range.<br />
<br />
|}<br />
<br />
<br />
'''Example seusers.final file contents:'''<br />
<pre><br />
# modules/active/seusers.final<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux user mapping:'''<br />
<pre><br />
# This command will add the rch:user_u entry in the seusers file:<br />
<br />
semanage login -a -s user_u rch<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# modules/active/seusers<br />
<br />
rch:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# /modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
</pre><br />
<br />
'''Example semanage login command to add a GNU / Linux group mapping:'''<br />
<pre><br />
# This command will add the %user_group:user_u entry in the seusers file: <br />
<br />
semanage login -a -s user_u %user_group<br />
</pre><br />
<br />
'''The resulting seusers file would be:'''<br />
<pre><br />
# /modules/active/seusers<br />
<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
'''The seusers.final file that will become the <nowiki>./<policy_name>/seusers</nowiki> file is as follows:'''<br />
<pre><br />
# modules/active/seusers.final<br />
<br />
system_u:system_u<br />
root:root<br />
__default__:user_u<br />
rch:user_u<br />
%user_group:user_u<br />
</pre><br />
<br />
== modules/active/users_extra, users_extra.local and users.local Files ==<br />
These three files work together to describe SELinux user information as follows:<br />
* The users_extra and users_extra.local files are used to map a prefix to users home directories as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section, where it is used to replace the ROLE keyword. The prefix is linked to an SELinux user id and should reflect the users role. The semanage user command will allow a prefix to be added via the -P flag (although no longer used by policies as discussed in the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file section). <br />
<br />
The users_extra file contains all the policy prefix entries, and the users_extra.local file contains those generated by the semanage user command.<br />
<br />
The users_extra file can optionally be included in the base package via the '''semodule_package'''(8) command (signified by the -u flag) as follows<ref name="ftn38"><sup>The Reference Policy Makefile 'Rules.modular' script uses this method to install the initial users_extra file.</sup></ref>:<br />
<pre><br />
semodule_package -o base.pp -m base.mod -u users_extra ... <br />
</pre><br />
<br />
The users_extra file would then be extracted by a subsequent semodule command when building the policy.<br />
<br />
* The users.local file is used to add new SELinux users to the policy without editing the policy source itself (with each line in the file following a policy language [[KernelPolicyLanguage#user | user]] statement section). This is useful when only the Reference Policy headers are installed and additional users need to added. The semanage user command will allow a new SELinux user to be added that would generate the user.local file and if a -P flag has been specified, then a users_extra.local file is also updated (note: if this is a new SELinux user and a prefix is not specified a default prefix of user is generated). <br />
<br />
The sections that follow will:<br />
* Define the format and show example users_extra and users_extra.local files.<br />
* Execute an semanage user command that will add a new SELinux user and associated prefix, and show the resulting users_extra, users_extra.local and users.local files. <br />
<br />
Note that each line of the users.local file contains a user statement that is defined in the policy language [[KernelPolicyLanguage#user | user]] statement section, and will be built into the policy via the semanage command.<br />
<br />
'''The format of the users_extra & users_extra.local files are as follows:'''<br />
<pre><br />
user seuser_id prefix prefix_id;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| user<br />
| The user keyword.<br />
<br />
|-<br />
| seuser_id<br />
| The SELinux user identity.<br />
<br />
|-<br />
| prefix<br />
| The prefix keyword.<br />
<br />
|-<br />
| prefix_id<br />
| An identifier that will be used to replace the ROLE keyword within the modules/active/homedir_template file when building the ./modules/active/file_contexts.homedirs file for the relabeling utilities to set the security context on users home directories.<br />
<br />
|}<br />
<br />
<br />
'''Example users_extra file contents:'''<br />
<pre><br />
# modules/active/users_extra entries, note that the <br />
# users_extra.local file contents are similar and generated by <br />
# the semanage user command.<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
</pre><br />
<br />
'''Example semanage user command to add a new SELinux user:'''<br />
<pre><br />
# This command will add the user test_u prefix staff entry in <br />
# the users_extra.local file: <br />
<br />
semanage user -a -R staff_r -P staff test_u<br />
</pre><br />
<br />
'''The resulting users_extra.local file is as follows:'''<br />
<pre><br />
# modules/active/users_extra.local<br />
<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users_extra file is as follows:'''<br />
<pre><br />
# modules/active/users_extra<br />
<br />
user user_u prefix user;<br />
user staff_u prefix user;<br />
user sysadm_u prefix user;<br />
user root prefix user;<br />
user test_u prefix staff;<br />
</pre><br />
<br />
'''The resulting users.local file is as follows:'''<br />
<pre><br />
# modules/active/users.local file entry:<br />
<br />
user test_u roles { staff_r } level s0 range s0;<br />
</pre><br />
<br />
== modules/active/booleans.local File ==<br />
This file is created and updated by the <tt>semanage boolean</tt> command and holds boolean value as requested.<br />
<br />
'''Example semanage boolean command to modify a boolean value:'''<br />
<pre><br />
# This command will add an entry in the booleans.local <br />
# file and set the boolean value to 'off': <br />
<br />
semanage boolean -m -0 ext_gateway_audit<br />
</pre><br />
<br />
'''The resulting <tt>booleans.</tt>local file would be:'''<br />
<pre><br />
# modules/active/booleans.local<br />
<br />
ext_gateway_audit=0<br />
</pre><br />
<br />
== modules/active/file_contexts.local File ==<br />
This file is created and updated by the semanage fcontext command. It is used to hold file context information on files and directories that were not delivered by the core policy (i.e. they are not defined in any of the <nowiki>*.fc</nowiki> files delivered in the base and loadable modules).<br />
<br />
The semanage command will add the information to the policy stores file_contexts.local file and then copy this file to the ./contexts/files/file_contexts.local file, where it will be used when the file context utilities are run.<br />
<br />
The format of the file_contexts.local file is the same as the [[#modules/active/file_contexts.template | modules/active/file_contexts.template]] file.<br />
<br />
'''Example semanage fcontext command to add a new entry:'''<br />
<pre><br />
# This command will add an entry in the file_contexts.local file: <br />
<br />
semanage fcontext -a -t user_t /usr/move_file<br />
<br />
# Note that the type (-t flag) must exist in the policy <br />
# otherwise the command will fail.<br />
</pre><br />
<br />
'''The resulting file_contexts.local file would be:'''<br />
<pre><br />
# modules/active/file_contexts.local<br />
<br />
/usr/move_filesystem_u:object_r:user_t<br />
</pre><br />
<br />
== modules/active/interfaces.local File ==<br />
This file is created and updated by the semanage interface command to hold network interface information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new interface information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a netifcon statement that is defined along with examples in the [[KernelPolicyLanguage#netifcon | netifcon]] statement section.<br />
<br />
== modules/active/nodes.local File ==<br />
This file is created and updated by the semanage node command to hold network address information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new node information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a nodecon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#nodecon | nodecon]] statement section.<br />
<br />
== modules/active/ports.local File ==<br />
This file is created and updated by the semanage port command to hold network port information that was not delivered by the core policy (i.e. they are not defined in base.conf file). The new port information is then built into the policy by the '''semanage'''(8) command.<br />
<br />
Each line of the file contains a portcon statement that is defined along with examples in the policy language [[KernelPolicyLanguage#portcon | portcon]] statement section.<br />
<br />
== modules/active/preserve_tunables File ==<br />
This file will only exist if the policy build specified that tunables should be preserved, if so they would be converted to booleans by the policy build process.<br />
<br />
== modules/active/disable_dontaudit File ==<br />
This file will only exist if the policy build specified that [[KernelPolicyLanguage#dontaudit | dontaudit]] rules should be disabled.<br />
<br />
== modules/active/modules Directory Contents ==<br />
This directory contains loadable modules (<nowiki><module_name>.pp</nowiki> or when disabled <tt><nowiki><module_name>.pp.disabled</nowiki></tt>) that have been built by the semodule_package command and placed in the store by the semodule or <tt>semanage module -a</tt> commands as shown in the following example:<br />
<pre><br />
# Package the module move_file_c:<br />
<br />
semodule_package -o move_file_c.pp -m move_file_c.mod -f move_file.fc <br />
<br />
# Then to install it in the store (at /etc/selinux/modular-test/<br />
# modules/active/modules/move_file_c.pp) and build the binary <br />
# policy file, run the semodule command:<br />
<br />
semodule -v -s modular-test -i move_file_c.pp<br />
# Or:<br />
semanage module -a -S modular-test move_file_c.pp<br />
</pre><br />
<br />
The modules within the policy store may be compressed or not depending on the value of the <tt>bzip-blocksize</tt> parameter in the [[GlobalConfigurationFiles#/etc/selinux/semanage.conf File | semanage.conf]] file. The modules and their status can be listed using the <tt>semanage module -l</tt> command as shown below.<br />
<pre><br />
semanage module -l<br />
ext_gateway 1.1.0<br />
int_gateway 1.1.0<br />
move_file 1.1.0<br />
netlabel 1.0.0 Disabled<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[GlobalConfigurationFiles | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[PolicyConfigurationFiles | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_ApacheNB Apache2015-09-25T14:08:46Z<p>RichardHaines: /* Apache SELinux Support */</p>
<hr />
<div>= Apache SELinux Support =<br />
Apache web servers are supported by SELinux using the Apache policy modules from the Reference Policy (<tt>httpd</tt> modules), however there is no specific Apache object manger. There is though an SELinux-aware shared library and policy that will allow finer grained access control when using Apache with threads. The additional Apache module is called <tt>mod_selinux.so</tt> and has a supporting policy module called <tt>mod_selinux.pp</tt>.<br />
<br />
The <tt>mod_selinux</tt> policy module makes use of the [[Bounds Rules#typebounds | typebounds statement]] that was introduced into version 24 of the policy (requires a minimum kernel of 2.6.28). <tt>mod_selinux</tt> allows threads in a multi-threaded application (such as Apache) to be bound within a defined set of permissions in that the child domain cannot have greater permissions than the parent domain.<br />
<br />
These components are known as 'Apache / SELinux Plus' and are described in the sections that follow, however a full description including configuration details is available from:<br />
: [http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus]<br />
<br />
The objective of these Apache add-on services is to achieve a fully SELinux-aware web stack (although not there yet). For example, currently the LAPP<ref name="ftn29">This is similar to the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) stack, however MySQL is not SELinux-aware.</ref> (Linux, Apache, PostgreSQL, PHP / Perl / Python) stack has the following support:<br />
<br />
<br />
{| border="1"<br />
| <center>'''L'''</center><br />
| Linux has SELinux support.<br />
<br />
|-<br />
| <center>'''A'''</center><br />
| Apache has partial SELinux support using the 'Apache SELinux Plus' module.<br />
<br />
|-<br />
| <center>'''P'''</center><br />
| PostgreSQL has SELinux support using SE-PostgreSQL.<br />
<br />
|-<br />
| <center>'''P'''</center><br />
| PHP / Perl / Python are not currently SELinux-aware, however PHP and Python do have support for libselinux functions in packages: PHP - with the <tt>php-pecl-selinux</tt> package, Python - with the <tt>libselinux-python</tt> package.<br />
<br />
|}<br />
<br />
<br />
The "[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]" document gives a good overview of the LAPP architecture.<br />
<br />
== mod_selinux Overview ==<br />
What the <tt>mod_selinux</tt> module achieves is to allow a web application (or a 'request handler') to be launched by Apache with a security context based on policy rather than that of the web server process itself, for example:<br />
# A user sends an HTTP request to Apache that requires the services of a web application (Apache may or may not apply HTTP authentication).<br />
# Apache receives the request and launches the web application instance to perform the task:<br />
# Without <tt>mod_selinux</tt> enabled the web applications security context is identical to the Apache web server process, it is therefore not possible to restrict it privileges.<br />
# With <tt>mod_selinux</tt> enabled, the web application is launched with the security context defined in the <tt>mod_selinux.conf</tt> file (<tt><nowiki>selinuxDomainVal <security_context></nowiki></tt> entry). It is also possible to restrict its privileges as described in the [[#Bounds Overview | Bounds Overview]] section.<br />
<br />
# The web application exits, handing control back to the web server that replies with the HTTP response.<br />
<br />
== Bounds Overview ==<br />
Because multiple threads share the same memory segment, SELinux was unable to check the information flows between these different threads when using <tt>'''setcon'''(3)</tt> in pre 2.6.28 kernels. This meant that if a thread (the parent) should launch another thread (a child) with a different security context, SELinux could not enforce the different permissions.<br />
<br />
To resolve this issue the <tt>typebounds</tt> statement was introduced with kernel support in 2.6.28 that stops a child thread (the 'bounded domain') having greater privileges than the parent thread (the 'bounding domain') i.e. the child thread must have equal or less permissions than the parent. <br />
<br />
For example the following <tt>typebounds</tt> statement and <tt>allow</tt> rules:<br />
<pre><br />
# parent | child<br />
# domain | domain<br />
typebounds httpd_t httpd_child_t;<br />
<br />
allow httpd_t etc_t : file { getattr read };<br />
allow httpd_child_t etc_t : file { read write };<br />
</pre><br />
<br />
State that the parent domain (<tt>httpd_t</tt>) has <tt>file : { getattr read }</tt> permissions. However the child domain (<tt>httpd_child_t</tt>) has been given <tt>file : { read write }</tt>. At run-time, this would not be allowed by the kernel because the parent does not have <tt>write</tt> permission, thus ensuring the child domain will always have equal or less privileges than the parent.<br />
<br />
When <tt>'''setcon'''(3)</tt> is used to set a different context on a new thread without an associated <tt>typebounds</tt> policy statement, then the call will return 'Operation not permitted' and an <tt>SELINUX_ERR</tt> entry will be added to the audit log stating '<tt>op=security_bounded_transition result=denied</tt>' with the old and new context strings.<br />
<br />
Should there be a valid <tt>typebounds</tt> policy statement and the child domain exercises a privilege greater that that of the parent domain, the operation will be denied and an <tt>SELINUX_ERR</tt> entry will be added to the audit log stating '<tt>op=security_compute_av reason=bounds</tt>' with the context strings and the denied class and permissions. <br />
<br />
=== Notebook Examples ===<br />
The Notebook source tarball contains two demonstrations using <tt>'''setcon'''(3)</tt> with threads and how the <tt>typebounds</tt> statement is used to allow a thread to be executed. These are located in the <tt>libselinux/examples</tt> directory and are:<br />
<br />
* <tt>setcon_thread1_example.c</tt> - this example calls <tt>'''setcon'''</tt> in the main process loop but also starts a thread. If the <tt>setcon_example.conf</tt> policy module has been been loaded and a context of <tt>"unconfined_u:unconfined_r:user_t:s0</tt>" selected, then an error message should be displayed as follows:<br />
<pre><br />
setcon_raw - ERROR: Operation not permitted<br />
</pre><br />
This is because the <tt>'''setcon'''</tt> function cannot be run in a threaded environment without a <tt>typebounds</tt> statement. Now load the <tt>setcon_thread_example.conf</tt> policy module and then re-run the example, it should now complete without error.<br />
* <tt>setcon_thread2_example.c</tt> - this functions as example 1, however it calls <tt>'''setcon'''</tt> from a thread.<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_SQL_9.3 | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ConfigurationFiles | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_SQL_9.3NB SQL 9.32015-09-25T14:06:36Z<p>RichardHaines: </p>
<hr />
<div>= SE-PostgreSQL =<br />
This section gives an overview of PostgreSQL version 9.3 with the <tt>sepgsql</tt> extension to support SELinux labeling. It assumes some basic knowledge of PostgreSQL that can be found at: [http://wiki.postgresql.org/wiki/Main_Page http://wiki.postgresql.org/wiki/Main_Page]<br />
<br />
It is important to note that PostgreSQL from version 9.3 has the necessary infrastructure to support labeling of database objects via external 'providers'. An <tt>sepgsql</tt> extension has been added that provides SELinux labeling. This is not installed by default but as an option as outlined in the sections that follow. Because of these changes the original version 9.0 patches are no longer supported (i.e. the SE-PostgreSQL database engine is replaced by PostgreSQL database engine 9.3 plus the <tt>sepgsql</tt> extension). A consequence of this change is that row level labeling is no longer supported.<br />
<br />
The features of sepgsql 9.3 and its setup are covered in the following document:<br />
: [http://www.postgresql.org/docs/9.3/static/sepgsql.html http://www.postgresql.org/docs/9.3/static/sepgsql.html]<br />
<br />
== sepgsql Overview ==<br />
The <tt>sepgsql</tt> extension adds SELinux mandatory access controls (MAC) to database objects such as tables, columns, views, functions, schemas and sequences. Figure 1 shows a simple database with one table, two columns and three rows, each with their object class and associated security context (the [[#Internal Tables | Internal Tables]] section shows these entries from the <tt>testdb</tt> database in the Notebook tarball example). The database object classes and permissions are described in the [[NB_ObjectClassesPermissions | Object Classes and Permissions]] section.<br />
<br />
<center>'''Figure 1: Database Security Context Information - '''''Showing the security contexts that can be associated to a schema, table and columns.''</center><br />
{| border="1"<br />
| <br />
| colspan="3" | <center>'''database''' </center><br />
<br />
<center>context = 'unconfined_u:object_r:postgresql_db_t:s0'</center><br />
<br />
<center>This context is inherited from the database directory label - <tt>ls -Z /var/lib/pgsql/data</tt></center><br />
| <br />
<br />
|-<br />
| colspan="3" | <center>'''schema''' (db_schema)</center><br />
<br />
<center>security_label = 'unconfined_u:object_r:sepgsql_schema_t:s10'</center><br />
<br />
|-<br />
| colspan="3" | <center>'''table''' (db_table)</center><br />
<br />
<center>security_label = 'unconfined_u:object_r:sepgsql_table_t:s0:c20'</center><br />
<br />
|-<br />
| <br />
| <center>'''column 1''' (db_column)</center><br />
<br />
<center>security_label = 'unconfined_u:object_r:sepgsql_table_t:s0:c30'</center><br />
| <center>'''column 2''' (db_column)</center><br />
<br />
<center>security_label = 'unconfined_u:object_r:sepgsql_table_t:s0:c40'</center><br />
<br />
|}<br />
<br />
{| border="1"<br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
<br />
To use SE-PostgreSQL each GNU / Linux user must have a valid PostgreSQL database role (not to be confused with an SELinux role). The default installation automatically adds a user called <tt>pgsql</tt> with a suitable database role.<br />
<br />
If a client is connecting remotely and labeled networking is required, then it is possible to use IPSec or NetLabel as discussed in the [[NB_Networking | SELinux Networking Support]] section (the "[http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Security-Enhanced PostgreSQL Security Wiki]" also covers these methods of connectivity with examples). <br />
<br />
Using the [http://selinuxproject.org/~rhaines/NB4-diagrams/24-sepostgresql.png SE-PostgreSQL Services] diagram, the database client application (that could be provided by an API for Perl/PHP or some other programming language) connects to a database and executes SQL commands. As the SQL commands are processed by PostgreSQL, each operation performed on an object is checked by the object manager (OM) to see if the opration is allowed by the security policy or not.<br />
<br />
SE-PostgreSQL supports SELinux services via the <tt>libselinux</tt> library with AVC audits being logged into the standard PostgreSQL file as described in the [[#Logging Security Events|outline Logging Security Events]] section.<br />
<br />
== Installing SE-PostgreSQL ==<br />
The [http://www.postgresql.org/docs/devel/static/sepgsql.html http://www.postgresql.org/docs/devel/static/sepgsql.html] page contains all the information required to install PostgreSQL and the <tt>sepgsql</tt> extension, however the Notebook tarball <tt>sepgsql-9.3/README</tt> file also explains this and adds a simple test database.<br />
<br />
== SECURITY LABEL SQL Command ==<br />
The '<tt>SECURITY LABEL</tt>' SQL command has been added to PostgreSQL to allow security providers to label or change a label on database objects. The command format is:<br />
<pre><br />
SECURITY LABEL [ FOR provider ] ON<br />
{<br />
TABLE object_name |<br />
COLUMN table_name.column_name |<br />
AGGREGATE agg_name (agg_type [, ...] ) |<br />
DATABASE object_name |<br />
DOMAIN object_name |<br />
EVENT TRIGGER object_name |<br />
FOREIGN TABLE object_name<br />
FUNCTION function_name ( [ [ argmode ] [ argname ] argtype [, ...] ] ) |<br />
LARGE OBJECT large_object_oid |<br />
[ PROCEDURAL ] LANGUAGE object_name |<br />
ROLE object_name |<br />
SCHEMA object_name |<br />
SEQUENCE object_name |<br />
TABLESPACE object_name |<br />
TYPE object_name |<br />
VIEW object_name<br />
} IS 'label'<br />
</pre><br />
<br />
The full syntax is defined at [http://www.postgresql.org/docs/9.3/static/sql-security-label.html http://www.postgresql.org/docs/9.3/static/sql-security-label.html] and also in the <tt>'''security_label'''(7)</tt> man page. Some examples taken from the Notebook tarball are:<br />
<pre><br />
--- These set the security label on objects (default provider is SELinux):<br />
SECURITY LABEL ON SCHEMA test_ns IS 'unconfined_u:object_r:sepgsql_schema_t:s0:c10';<br />
SECURITY LABEL ON TABLE test_ns.info IS 'unconfined_u:object_r:sepgsql_table_t:s0:c20';<br />
SECURITY LABEL ON COLUMN test_ns.info.user_name IS 'unconfined_u:object_r:sepgsql_table_t:s0:c30';<br />
SECURITY LABEL ON COLUMN test_ns.info.email_addr IS 'unconfined_u:object_r:sepgsql_table_t:s0:c40';<br />
</pre><br />
<br />
== Additional SQL Functions ==<br />
The following functions have been added:<br />
<br />
{| border="1"<br />
| sepgsql_getcon()<br />
| Returns the client security context.<br />
<br />
|-<br />
| sepgsql_mcstrans_in(text con)<br />
| Translates the readable <tt>range</tt> of the context into raw format provided the <tt>mcstransd</tt> daemon is running.<br />
<br />
|-<br />
| sepgsql_mcstrans_out(text con)<br />
| Translates the raw <tt>range</tt> of the context into readable format provided the <tt>mcstransd</tt> daemon is running.<br />
<br />
|-<br />
| sepgsql_restorecon(text specfile)<br />
| Sets security contexts on all database objects (must be superuser) according to the <tt>specfile</tt>. This is normally used for initialisation of the database by the <tt>sepgsql.sql</tt> script. If the parameter is NULL, then the default <tt>sepgsql_contexts</tt> file is used. See <tt>'''selabel_db'''(5)</tt> details.<br />
<br />
|}<br />
<br />
<br />
== Additional postgresql.conf Entries ==<br />
The <tt>postgresql.conf</tt> file supports the following additional entries to enable and manage SE-PostgreSQL: <br />
* This entry is mandatory to enable the sepgsql extention to be loaded:<br />
<pre><br />
shared_preload_libraries = 'sepgsql'<br />
</pre><br />
* These entries are optional and default to 'off'. The '<tt>custom_variable_classes</tt>' entry must contain '<tt>sepgsql</tt>' to enable these to be configured.<br />
<pre><br />
# This entry allows sepgsql customised entries:<br />
custom_variable_classes = 'sepgsql'<br />
<br />
# These are the possible entries:<br />
# This enables sepgsql to always run in permissive mode:<br />
sepgsql.permissive = on<br />
<br />
# This enables printing of audit messages regardless of the policy setting:<br />
sepgsql.debug_audit = on<br />
</pre><br />
: To view these settings the <tt>SHOW</tt> SQL statement can be used (<tt>psql</tt> output shown):<br />
<pre><br />
SHOW sepgsql.permissive;<br />
sepgsql.permissive<br />
---------------<br />
on<br />
(1 row)<br />
</pre><br />
<pre><br />
SHOW sepgsql.debug_audit;<br />
sepgsql.debug_audit<br />
---------------<br />
on<br />
(1 row)<br />
</pre><br />
<br />
== Logging Security Events ==<br />
SE-PostgreSQL manages its own AVC audit entries in the standard PostgreSQL log normally located within the <tt>/var/lib/pgsql/data/pg_log</tt> directory and by default only errors are logged (Note that there are no SE-PostgreSQL AVC entries added to the standard <tt>audit.log</tt>). The '<tt>sepgsql.debug_audit = on</tt>' can be set to log all audit events.<br />
<br />
== Internal Tables ==<br />
To support the overall database operation PostgreSQL has internal tables in the system catalog that hold information relating to databases, tables etc. This section will only highlight the <tt>pg_seclabel</tt> table that holds the security label and other references. The <tt>pg_seclabel</tt> is described in Table 1 that has been taken from [http://www.postgresql.org/docs/9.3/static/catalog-pg-seclabel.html http://www.postgresql.org/docs/9.3/static/catalog-pg-seclabel.html]. <br />
<br />
<center>'''Table 1: <tt>pg_seclabel</tt> Table Columns'''</center><br />
{| border="1"<br />
! <center>Name</center><br />
! <center>Type</center><br />
! <center>References</center><br />
! Comment<br />
<br />
|-<br />
| objoid<br />
| <center>oid</center><br />
| any OID column<br />
| The OID of the object this security label pertains to.<br />
<br />
|-<br />
| classoid<br />
| <center>oid</center><br />
| [http://www.postgresql.org/docs/9.3/static/catalog-pg-class.html pg_class].oid<br />
| The OID of the system catalog this object appears in.<br />
<br />
|-<br />
| objsubid<br />
| <center>int4</center><br />
| <br />
| For a security label on a table column, this is the column number (the <tt>objoid</tt> and <tt>classoid</tt> refer to the table itself). For all other objects this column is zero.<br />
<br />
|-<br />
| provider<br />
| <center>text</center><br />
| <br />
| The label provider associated with this label. Currently only SELinux is supported.<br />
<br />
|-<br />
| label<br />
| <center>text</center><br />
| <br />
| The security label applied to this object.<br />
<br />
|}<br />
<br />
<br />
These are entries taken from a '<tt>SELECT * FROM pg_seclabel;</tt>' command that refer to the example <tt>testdb</tt> database built using the Notebook tarball samples:<br />
<pre><br />
objoid | classoid | objsubid | provider | label <br />
-------+----------+----------+----------+----------------------------------------------<br />
16390 | 2615 | 0 | selinux | unconfined_u:object_r:sepgsql_schema_t:s0:c10<br />
16391 | 1259 | 0 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c20<br />
16391 | 1259 | 1 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c30<br />
16391 | 1259 | 2 | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c40<br />
</pre><br />
<br />
The first entry is the schema, the second entry is the table itself, and the third and fourth entries are columns 1 and 2.<br />
<br />
There is also a built-in 'view' to show additional detail regarding security labels called '<tt>pg_seclabels</tt>'. Using '<tt>SELECT * FROM pg_seclabels;</tt>' command, the entries shown above become:<br />
<pre><br />
objoid | classoid | objsubid | objtype | objnamespace | objname | provider | label <br />
-------+----------+----------+-----------+------------+------------------------+----------+----------------------------------------------<br />
16390 | 2615 | 0 | schema | 16390 | test_ns | selinux | unconfined_u:object_r:sepgsql_schema_t:s0:c10<br />
16391 | 1259 | 0 | table | 16390 | test_ns.info | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c20<br />
16391 | 1259 | 1 | column | 16390 | test_ns.info.user_name | selinux | unconfined_u:object_r:sepgsql_table_t:s0:c30<br />
16391 | 1259 | 2 | column | 16390 | test_ns.info.email_addr| selinux | unconfined_u:object_r:sepgsql_table_t:s0:c40<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_XWIN | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_Apache | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_XWINNB XWIN2015-09-25T14:05:10Z<p>RichardHaines: </p>
<hr />
<div>= X-Windows SELinux Support =<br />
The SELinux X-Windows (XSELinux) implementation provides fine grained access control over the majority of the X-server objects (known as resources) using an X-Windows extention acting as the object manager (OM). The extension name is "<tt>SELinux</tt>".<br />
<br />
This Notebook will only give a high level description of the infrastructure based on the [http://selinuxproject.org/~rhaines/NB4-diagrams/23-x-server.png X-Server and XSELinux Object Manager X-Server and XSELinux Object Manager] diagram, however the "[http://www.nsa.gov/research/_files/selinux/papers/xorg07-paper.pdf Application of the Flask Architecture to the X Window ][http://www.nsa.gov/research/_files/selinux/papers/xorg07-paper.pdf System Server]" paper has a good overview of how the object manager has been implemented, although it does not cover areas such as polyinstantiation.<br />
<br />
The X-Windows object classes and permissions are listed in the [[NB_ObjectClassesPermissions#X Windows Object Classes | X Windows Object Classes]] section and the Reference Policy modules have been updated to enforce policy using the XSELinux object manager.<br />
<br />
On Fedora XSELinux is disabled in the targeted policy but enabled on the MLS policy. This is because Red Hat prefers to use sandboxing with the Xephyr server to isolate windows with the targeted policy, see the [[NB_SandBox | Sandbox Services]] section for details.<br />
<br />
== Infrastructure Overview ==<br />
It is important to note that the X-Windows OM operates on the low level window objects of the X-server. A windows manager (such as Gnome or twm) would then sit above this, however they (the windows manager or even the lower level Xlib) would not be aware of the policy being enforced by SELinux. Therefore there can be situations where X-Windows applications get bitter & twisted at the denial of a service. This can result in either opening the policy more than desired, or just letting the application keep aborting, or modifying the application.<br />
<br />
Using the [http://selinuxproject.org/~rhaines/NB4-diagrams/23-x-server.png X-Server and XSELinux Object Manager X-Server and XSELinux Object Manager] diagram, the major components that form the overall XSELinux OM are (top left to right):<br />
: '''The Policy''' - The Reference Policy has been updated, however in Fedora the OM is enabled for mls and disabled for targeted policies via the <tt>xserver-object-manager</tt> boolean. Enabling this boolean also initialises the XSELinux OM extension. Important note - The boolean must be present in any policy and be set to <tt>true</tt>, otherwise the object manager will be disabled as the code specifically checks for the boolean.<br />
: <tt>'''libselinux'''</tt> - This library provides the necessary interfaces between the OM, the SELinux userspace services (e.g. reading configuration information and providing the AVC), and kernel services (e.g. security server for access decisions and policy update notification).<br />
: <tt>'''x_contexts</tt> File''' - This contains default context configuration information that is required by the OM for labeling certain objects. The OM reads its contents using the <tt>'''selabel_lookup'''(3)</tt> function.<br />
: '''XSELinux Object Manager''' - This is an X-extension for the X-server process that mediates all access decisions between the the X-server (via the XACE interface) and the SELinux security server (via <tt>libselinux</tt>). The OM is initialised before any X-clients connect to the X-server. The OM has also added XSELinux functions that are described in [[#SELinux_Extension_Functions | Table 1]] to allow contexts to be retrieved and set by userspace SELinux-aware applications.<br />
: '''XACE Interface''' - This is an 'X Access Control Extension' (XACE) that can be used by other access control security extensions, not only SELinux. Note that if other security extensions are linked at the same time, then the X-function will only succeed if allowed by all the security extensions in the chain. This interface is defined in the "[http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.pdf X Access Control Extension Specification]. The specification also defines the hooks available to OMs and how they should be used. The provision of polyinstantiation services for properties and selections is also discussed. The XACE interface is a similar service to the LSM that supports the kernel OMs.<br />
: '''X-server''' - This is the core X-Windows server process that handles all request and responses to/from X-clients using the X-protocol. The XSELinux OM is intercepting these request/responses via XACE and enforcing policy decisions.<br />
: '''X-clients''' - These connect to the X-server are are typically windows managers such as Gnome, twm or KDE. <br />
: '''Kernel-Space Services''' - These are discussed in the [[NB_LSM | Linux Security Module and SELinux]] section.<br />
<br />
==== Polyinstantiation ====<br />
The OM / XACE services support polyinstantiation of properties and selections allowing these to be grouped into different membership areas so that one group does not know of the exsistance of the others. To implement polyinstantiation the <tt>poly_</tt> keyword is used in the <tt>x_contexts</tt> file for the required selections and properties, there would then be a corresponding <tt>type_member</tt> statement in the policy to enforce the separation by computing a new context with either <tt>'''security_compute_member'''(3)</tt> or <tt>'''avc_compute_member'''(3)</tt>.<br />
<br />
Note that the current Reference Policy does not implement polyinstantiation, instead the MLS policy uses <tt>mlsconstrain</tt> rules to limit the scope of properties and selections.<br />
<br />
== Configuration Information ==<br />
This section covers:<br />
* How to enable/disable the OM X-extension.<br />
* How to determine the OM X-extension opcode.<br />
* How to configure the OM in a specific SELinux enforcement mode.<br />
* The <tt>x-contexts</tt> configuration file.<br />
<br />
=== Enable/Disable the OM from Policy Decisions ===<br />
The Reference Policy has a <tt>xserver_object_manager</tt> boolean that enables/disables the X-server policy module and also stops the object manager extension from initialising when X-Windows is started. The following command will enable the boolean, however it will be necessary to reload X-Windows to initialise the extension (i.e. run the <tt>init 3</tt> and then <tt>init 5</tt> commands):<br />
<pre><br />
setsebool -P xserver_object_manager true<br />
</pre><br />
If the boolean is set to <tt>false</tt>, the x-server log will indicate that "SELinux: Disabled by boolean". Important note - If the boolean is not present in a policy then the object manager will always be enabled (therefore if not required then either do not include the object manager in the X-server build, add the boolean to the policy and set it to false or add a disabled entry to the <tt>xorg.conf</tt> file as described in the [[#Configure OM Enforcement Mode | Configure OM Enforcement Mode]] section).<br />
<br />
=== Determine OM X-extension Opcode ===<br />
The object manager is treated as an X-server extension and its major opcode can be queried using Xlib <tt>XQueryExtension</tt> function as follows:<br />
<pre><br />
/* Get the SELinux Extension opcode */<br />
if (!XQueryExtension (dpy, "SELinux", &opcode, &event, &error)) {<br />
perror ("XSELinux extension not available");<br />
exit (1);<br />
} else {<br />
printf ("XQueryExtension for XSELinux Extension - Opcode: %d <br />
Events: %d Error: %d \n", opcode, event, error);<br />
}<br />
<pre><br />
<br />
=== Configure OM Enforcement Mode ===<br />
If the X-server object manager needs to be run in a specific SELinux enforcement mode, then the option may be added to the <tt>xorg.conf</tt> file (normally in <tt>/etc/X11/xorg.conf.d</tt>). The option entries are as follows:<br />
: "SELinux mode disabled"<br />
: "SELinux mode permissive"<br />
: "SELinux mode enforcing"<br />
<br />
Note that the entry must be exact otherwise it will be ignored. An example entry is:<br />
<pre><br />
Section "Module"<br />
SubSection "extmod"<br />
Option "SELinux mode enforcing"<br />
EndSubSection<br />
EndSection<br />
</pre><br />
<br />
If there is no entry, the object manager will follow the current SELinux enforcement mode.<br />
<br />
=== The x_contexts File ===<br />
The <tt>x_contexts</tt> file contains default context information that is required by the OM to initialise the service and then label objects as they are created. The policy will also need to be aware of the context information being used as it will use this to enforce policy or transition new objects. A typical entry is as follows:<br />
<pre><br />
# object_type object_name context<br />
selection PRIMARY system_u:object_r:clipboard_xselection_t:s0<br />
</pre><br />
or for polyinstantiation support:<br />
<pre><br />
# object_type object_name context<br />
poly_selection PRIMARY system_u:object_r:clipboard_xselection_t:s0<br />
</pre><br />
<br />
The <tt>object_name</tt> can contain '<tt><nowiki>*</nowiki></tt>' for 'any' or '<tt>?</tt>' for 'substitute'.<br />
<br />
The OM uses the <tt>selabel</tt> functions (such as <tt>'''selabel_lookup'''(3)</tt>) that are a part of <tt>libselinux</tt> to fetch the relevant information from the<tt> x_contexts</tt> file.<br />
<br />
The valid <tt>object_type</tt> entries are <tt>client</tt>, <tt>property</tt>, <tt>poly_property</tt>, <tt>extension</tt>, <tt>selection</tt>, <tt>poly_selection</tt> and <tt>events</tt>.<br />
<br />
The <tt>object_name</tt> entries can be any valid X-server resource name that is defined in the X-server source code and can typically be found in the <tt>protocol.txt</tt> and <tt>BuiltInAtoms</tt> source files (in the <tt>dix</tt> directory of the <tt>xorg-server</tt> source package), or user generated via the Xlib libraries (e.g. <tt>XInternAtom</tt>). <br />
<br />
Notes:<br />
* The way the XSELinux extension code works (see <tt>xselinux_label.c</tt> - <tt>SELinuxAtomToSIDLookup</tt>) is that non-poly entries are searched for first, if an entry is not found then it searches for a matching poly entry.<br />
:The reason for this behavior is that when operating in a secure environment all objects would be polyinstantiated unless there are specific exemptions made for individual objects to make them non-polyinstantiated. There would then be a '<tt>poly_selection *</tt>' or '<tt>poly_property *</tt>' at the end of the section.<br />
* For systems using the Reference Policy all X-clients connecting remotely will be allocated a security context from the <tt>x_contexts</tt> file of:<br />
<pre><br />
# object_type object_name context<br />
client * system_u:object_r:remote_t:s0<br />
</pre><br />
: A full description of the <tt>x_contexts</tt> file format is given in the [[PolicyConfigurationFiles#contexts/x_contexts File | x_contexts File]] section.<br />
<br />
<br />
== SELinux Extension Functions ==<br />
<center>'''Table 1: The XSELinux Extension Functions - '''''Supported by the object manager as X-protocol extensions. Note that some functions will return the default contexts, while others (2, 6, 9, 11, 16, 18) will not return a value unless one has been set the the appropriate function (1, 5, 8, 10, 15, 17) by an SELinux-aware application.''</center><br />
{| border="1"<br />
! Function Name<br />
! Minor Opcode<br />
! Parameters<br />
! Comments<br />
<br />
|-<br />
| XSELinuxQueryVersion<br />
| <center>0</center><br />
| None<br />
| Returns the XSELinux version. F-20 returns 1.1<br />
<br />
|-<br />
| XSELinuxSetDeviceCreateContext<br />
| <center>1</center><br />
| Context+Len<br />
| Sets the context for creating a device object (<tt>x_device</tt>).<br />
<br />
|-<br />
| XSELinuxGetDeviceCreateContext<br />
| <center>2</center><br />
| None<br />
| Retrieves the context set by <tt>XSELinuxSetDeviceCreateContext</tt>.<br />
<br />
|-<br />
| XSELinuxSetDeviceContext<br />
| <center>3</center><br />
| DeviceID + Context+Len<br />
| Sets the context for creating the specified DeviceID object.<br />
<br />
|-<br />
| XSELinuxGetDeviceContext<br />
| <center>4</center><br />
| DeviceID<br />
| Retrieves the context set by <tt>XSELinuxSetDeviceContext</tt>.<br />
<br />
|-<br />
| XSELinuxSetWindowCreateContext<br />
| <center>5</center><br />
| Context+Len<br />
| Set the context for creating a window object (<tt>x_window</tt>).<br />
<br />
|-<br />
| XSELinuxGetWindowCreateContext<br />
| <center>6</center><br />
| None<br />
| Retrieves the context set by <tt>XSELinuxSetWindowCreateContext</tt>.<br />
<br />
|-<br />
| XSELinuxGetWindowContext<br />
| <center>7</center><br />
| WindowID<br />
| Retrieves the specified WindowID context.<br />
<br />
|-<br />
| XSELinuxSetPropertyCreateContext<br />
| <center>8</center><br />
| Context + Len<br />
| Sets the context for creating a property object (<tt>x_property</tt>).<br />
<br />
|-<br />
| XSELinuxGetPropertyCreateContext<br />
| <center>9</center><br />
| None<br />
| Retrieves the context set by <tt>XSELinuxSetPropertyCreateContext</tt>.<br />
<br />
|-<br />
| XSELinuxSetPropertyUseContext<br />
| <center>10</center><br />
| Context + Len<br />
| Sets the context of the property object to be retrieved when polyinstantiation is being used.<br />
<br />
|-<br />
| XSELinuxGetPropertyUseContext<br />
| <center>11</center><br />
| None<br />
| Retrieves the property object context set by <tt>SELinuxSetPropertyUseContext</tt>.<br />
<br />
|-<br />
| XSELinuxGetPropertyContext<br />
| <center>12</center><br />
| WindowID + AtomID<br />
| Retrieves the context of the property atom object.<br />
<br />
|-<br />
| XSELinuxGetPropertyDataContext<br />
| <center>13</center><br />
| WindowID + AtomID<br />
| Retrieves the context of the property atom data. <br />
<br />
|-<br />
| XSELinuxListProperties<br />
| <center>14</center><br />
| WindowID<br />
| Lists the object and data contexts of properties associated with the selected WindowID.<br />
<br />
|-<br />
| XSELinuxSetSelectionCreateContext<br />
| <center>15</center><br />
| Context+Len<br />
| Sets the context to be used for creating a selection object.<br />
<br />
|-<br />
| XSELinuxGetSelectionCreateContext<br />
| <center>16</center><br />
| None<br />
| Retrieves the context set by <tt>SELinuxSetSelectionCreateContext</tt>.<br />
<br />
|-<br />
| XSELinuxSetSelectionUseContext<br />
| <center>17</center><br />
| Context+Len<br />
| Sets the context of the selection object to be retrieved when polyinstantiation is being used. See the <tt>XSELinuxListSelections</tt> function for an example.<br />
<br />
|-<br />
| XSELinuxGetSelectionUseContext<br />
| <center>18</center><br />
| None<br />
| Retrieves the selection object context set by <tt>SELinuxSetSelectionUseContext</tt>.<br />
<br />
|-<br />
| XSELinuxGetSelectionContext<br />
| <center>19</center><br />
| AtomID<br />
| Retrieves the context of the specified selection atom object.<br />
<br />
|-<br />
| XSELinuxGetSelectionDataContext<br />
| <center>20</center><br />
| AtomID<br />
| Retrieves the context of the selection data from the current selection owner (<tt>x_application_data</tt> object).<br />
<br />
|-<br />
| XSELinuxListSelections<br />
| <center>21</center><br />
| None<br />
| Lists the selection atom object and data contexts associated with this display. The main difference in the listings is that when (for example) the <tt>PRIMARY</tt> selection atom is polyinstantiated, multiple entries can returned. One has the context of the atom itself, and one entry for each process (or x-client) that has an active polyinstantiated entry, for example:<br />
<br />
<br />
Atom: PRIMARY - label defined in the<tt> x_contexts</tt> file (this is also for non-poly listing):<br />
<br />
Object Context: system_u:object_r:primary_xselection_t<br />
<br />
Data Context: system_u:object_r:primary_xselection_t<br />
<br />
<br />
Atom: PRIMARY - Labels for client 1:<br />
<br />
Object Context: system_u:object_r:x_select_paste1_t<br />
<br />
Data Context: system_u:object_r:x_select_paste1_t<br />
<br />
<br />
Atom: PRIMARY - Labels for client 2:<br />
<br />
Object Context: system_u:object_r:x_select_paste2_t<br />
<br />
Data Context: system_u:object_r:x_select_paste2_t<br />
<br />
|-<br />
| XSELinuxGetClientContext<br />
| <center>22</center><br />
| ResourceID<br />
| Retrieves the client context of the specified ResourceID.<br />
<br />
|}<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_PAM | '''Previous''']]<br />
| <center>[[NB_SandBox | '''Home''']]</center><br />
| <center>[[NB_SQL_9.3 | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_VMNB VM2015-09-25T14:04:09Z<p>RichardHaines: /* Xen Support */</p>
<hr />
<div>= SELinux Virtual Machine Support =<br />
SELinux support is available in the KVM/QEMU and Xen virtual machine (VM) technologies<ref name="ftn25">KVM (Kernel-based Virtual Machine) and Xen are classed as 'bare metal' hypervisors and they rely on other services to manage the overall VM environment. QEMU (Quick Emulator) is an emulator that emulates the BIOS and I/O device functionality and can be used standalone or with KVM and Xen.</ref> that are discussed in the sections that follow, however the package documentation should be read for how these products actually work and how they are configured. <br />
<br />
Currently the main SELinux support for virtualisation is via <tt>libvirt</tt> that is an open-source virtualisation API used to dynamically load guest VMs. Security extensions were added as a part of the [http://selinuxproject.org/page/SVirt Svirt] project and the SELinux implementation for the KVM/QEMU package (<tt>qemu-kvm</tt> and <tt>libvirt</tt> rpms) is discussed using some examples. The Xen product has Flask/TE services that can be built as an optional service, although it can also use the security enhanced <tt>libvirt</tt> services as well.<br />
<br />
The sections that follow give an introduction to KVM/QEMU, then <tt>libvirt</tt> support with some examples using the Virtual Machine Manager to configure VMs, then an overview of the Xen implementation follows.<br />
<br />
To ensure all dependencies are installed run:<br />
<pre><br />
yum install libvirt<br />
yum install qemu<br />
yum install virt-manager<br />
</pre><br />
<br />
== KVM / QEMU Support ==<br />
KVM is a kernel loadable module that uses the Linux kernel as a hypervisor and makes use of a modified QEMU emulator to support the hardware I/O emulation. The "[http://www.redhat.com/f/pdf/rhev/DOC-KVM.pdf Kernel-based Virtual Machine]" document gives a good overview of how KVM and QEMU are implemented. It also provides an introduction to virtualisation in general. Note that KVM requires virtulisation support in the CPU (Intel-VT or AMD-V extensions).<br />
<br />
The SELinux support for VMs is implemented by the <tt>libvirt</tt> sub-system that is used to manage the VM images using a Virtual Machine Manager, and as KVM is based on Linux it has SELinux support by default. There are also Reference Policy modules to support the overall infrastructure (KVM support is in various kernel and system modules with a <tt>virt</tt> module supporting the <tt>libvirt</tt> services).The [http://selinuxproject.org/~rhaines/NB4-diagrams/18-kvm.png KVM Environment] diagram shows a high level overview with two VMs running in their own domains. The [[#libsvirt Support | libvirt Support]] section shows how to configure these and their VM image files.<br />
<br />
== libvirt Support ==<br />
The Svirt project added security hooks into the <tt>libvirt</tt> library that is used by the <tt>libvirtd</tt> daemon. This daemon is used by a number of VM products (such as KVM, QEMU and Xen) to start their VMs running as guest operating systems.<br />
<br />
The VM supplier can implement any security mechanism they require using a product specific libvirt [http://libvirt.org/drvqemu.html driver] that will load and manage the images. The SELinux implementation supports four methods of labeling VM images, processes and their resources with support from the Reference Policy <tt>modules/services/virt.*</tt> loadable module<ref name="ftn26">The various images would have been labeled by the <tt>virt</tt> module installation process (see the <tt>virt.fc</tt> module file or the policy <tt>file_contexts</tt> file <tt>libvirt</tt> entries). If not, then need to ensure it is relabeled by the most appropriate SELinux tool.</ref>. To support this labeling, <tt>libvirt</tt> requires an MCS or MLS enabled policy as the <tt>level</tt> entry of the security context is used (<tt>user:role:type:level</tt>).<br />
<br />
The link [http://libvirt.org/drvqemu.html#securityselinux http://libvirt.org/drvqemu.html#securityselinux] has details regarding the QEMU driver and the SELinux confinement modes it supports.<br />
<br />
== VM Image Labeling ==<br />
This sections assumes VM images have been generated using the simple Linux kernel available at: [http://wiki.qemu.org/Testing http://wiki.qemu.org/Testing] (the <tt>linux-0.2.img.bz2</tt> disk image), this image was renamed to reflect each test, for example '<tt>Dynamic_VM1.img</tt>'.<br />
<br />
These images can be generated using the VMM by selecting the 'Create a new virtual machine' menu, 'importing existing disk image' then in step 2 Browse... selecting 'Choose Volume: <tt>Dynamic_VM1.img</tt>' with OS type: <tt>Linux</tt>, Version: <tt>Generic 2.6.x kernel</tt> and change step 4 'Name' to <tt>Dynamic_VM1</tt>.<br />
<br />
=== Dynamic Labeling ===<br />
The default mode is where each VM is run under its own dynamically configured domain and image file therefore isolating the VMs from each other (i.e. every time the VM is run a different and unique MCS label will be generated to confine each VM to its own domain). This mode is implemented as follows:<br />
<br />
# An initial context for the process is obtained from the <tt><nowiki>/etc/selinux/<</nowiki>SELINUXTYPE>/contexts/virtual_domain_context</tt> file (the default is <tt>system_u:system_r:svirt_tcg_t:s0</tt>).<br />
# An initial context for the image file label is obtained from the <tt><nowiki>/etc/selinux/<</nowiki>SELINUXTYPE>/contexts/virtual_image_context</tt> file. The default is <tt>system_u:system_r:svirt_image_t:s0</tt> that allows read/write of image files.<br />
# When the image is used to start the VM, a random MCS <tt>level</tt> is generated and added to the process context and the image file context. The process and image files are then transitioned to the context by the<tt> libselinux</tt> API calls <tt>setfilecon</tt> and <tt>setexeccon</tt> respectively (see <tt>security_selinux.c</tt> in the <tt>libvirt </tt>source). The following example shows two running VM sessions each having different labels:<br />
<br />
{| border="1"<br />
| '''VM Name'''<br />
| '''Object'''<br />
| '''Dynamically assigned security context '''<br />
<br />
|-<br />
| Dynamic_VM1<br />
| Process<br />
| system_u:system_r:svirt_tcg_t:s0:c585,c813<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:svirt_image_t:s0:c585,c813<br />
<br />
|-<br />
| Dynamic_VM2<br />
| Process<br />
| system_u:system_r:svirt_tcg_t:s0:c535,c601<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:svirt_image_t:s0:c535,c601<br />
<br />
|}<br />
<br />
<br />
The running image <tt>ls -Z</tt> and <tt>ps -eZ</tt> are as follows, and for completeness an <tt>ls -Z</tt> is shown when both VMs have been stopped:<br />
<pre><br />
# Both VMs running:<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:svirt_image_t:s0:c585,c813 Dynamic_VM1.img<br />
system_u:object_r:svirt_image_t:s0:c535,c601 Dynamic_VM2.img<br />
<br />
ps -eZ | grep qemu<br />
system_u:system_r:svirt_tcg_t:s0:c585,c813 8707 ? 00:00:44 qemu-system-x86<br />
system_u:system_r:svirt_tcg_t:s0:cc535,c601 8796 ? 00:00:37 qemu-system-x86<br />
<br />
# Both VMs stopped (note that the categories are now missing AND<br />
# the type has changed from svirt_image_t to virt_image_t):<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:virt_image_t:s0 Dynamic_VM1.img<br />
system_u:object_r:virt_image_t:s0 Dynamic_VM2.img<br />
</pre><br />
<br />
=== Shared Image ===<br />
If the disk image has been set to shared, then a dynamically allocated <tt>level</tt> will be generated for each VM process instance, however there will be a single instance of the disk image.<br />
<br />
The Virtual Machine Manager can be used to set the image as shareable by checking the <tt>Shareable</tt> box as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/19-shareable.png Setting the Virtual Disk as Shareable] screen shot.<br />
<br />
This will set the image (<tt>Shareable_VM.xml</tt>) resource XML configuration file located in the <tt>/etc/libvirt/qemu</tt> directory <tt><nowiki><disk></nowiki></tt> contents as follows:<br />
<pre><br />
# /etc/libvirt/qemu/Shareable_VM.xml:<br />
<br />
<disk type='file' device='disk'><br />
<driver name='qemu' type='raw'/><br />
<source file='/var/lib/libvirt/images/Shareable_VM.img'/><br />
<target dev='hda' bus='ide'/><br />
<shareable/><br />
<address type='drive' controller='0' bus='0' unit='0'/><br />
</disk><br />
</pre><br />
<br />
As the two VMs will share the same image, the <tt>Shareable_VM</tt> service needs to be cloned and the VM resource name selected was <tt>Shareable_VM-clone</tt> as shown in this [http://selinuxproject.org/~rhaines/NB4-diagrams/20-clone.png screen shot].<br />
<br />
The resource XML file <tt><nowiki><disk></nowiki></tt> contents generated are shown - note that it has the same <tt>source file</tt> name as the <tt>Shareable_VM.xml</tt> file shown above.<br />
<pre><br />
# /etc/libvirt/qemu/Shareable_VM-clone.xml:<br />
<br />
<disk type='file' device='disk'><br />
<driver name='qemu' type='raw'/><br />
<source file='/var/lib/libvirt/images/Shareable_VM.img'/><br />
<target dev='hda' bus='ide'/><br />
<shareable/><br />
<address type='drive' controller='0' bus='0' unit='0'/><br />
</disk><br />
</pre><br />
<br />
<br />
With the targeted policy on F-20 the shareable option gave a error when the VMs were run as follows:<br />
<pre><br />
Could not allocate dynamic translator buffer<br />
</pre><br />
<br />
The audit log contained the following AVC message:<br />
<pre><br />
type=AVC msg=audit(1326028680.405:367): avc: denied { execmem } for pid=5404 comm="qemu-system-x86" <br />
scontext=system_u:system_r:svirt_t:s0:c121,c746 tcontext=system_u:system_r:svirt_t:s0:c121,c746 tclass=process<br />
</pre><br />
<br />
To overcome this error, the following boolean needs to be enabled with <tt>'''setsebool'''(8)</tt> to allow access to shared memory (the <tt>-P</tt> option will set the boolean across reboots):<br />
<pre><br />
setsebool -P virt_use_execmem on<br />
</pre><br />
<br />
Now that the image has been configured as shareable, the following initialisation process will take place:<br />
<br />
# An initial context for the process is obtained from the <tt><nowiki>/etc/selinux/<</nowiki>SELINUXTYPE>/contexts/virtual_domain_context</tt> file (the default is <tt>system_u:system_r:svirt_tcg_t:s0</tt>).<br />
# An initial context for the image file label is obtained from the <tt><nowiki>/etc/selinux/<</nowiki>SELINUXTYPE>/contexts/virtual_image_context</tt> file. The default is <tt>system_u:system_r:svirt_image_t:s0</tt> that allows read/write of image files.<br />
# When the image is used to start the VM a random MCS level is generated and added to the process context (but not the image file). The process is then transitioned to the appropriate context by the<tt> libselinux</tt> API calls <tt>setfilecon</tt> and <tt>setexeccon</tt> respectively. The following example shows each VM having the same file label but different process labels:<br />
<br />
{| border="1"<br />
| '''VM Name'''<br />
| '''Object'''<br />
| '''Security context '''<br />
<br />
|-<br />
| Shareable_VM<br />
| Process<br />
| system_u:system_r:svirt_tcg_t:s0:c231,c245<br />
<br />
|-<br />
| Shareable_VM-clone<br />
| Process<br />
| system_u:system_r:svirt_tcg_t:s0:c695,c894<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:svirt_image_t:s0<br />
<br />
|}<br />
<br />
<br />
The running image <tt>ls -Z</tt> and <tt>ps -eZ</tt> are as follows and for completeness an <tt>ls -Z</tt> is shown when both VMs have been stopped:<br />
<pre><br />
# Both VMs running and sharing same image:<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:svirt_image_t:s0 Shareable_VM.img<br />
<br />
# but with separate processes:<br />
ps -eZ | grep qemu<br />
system_u:system_r:svirt_t:s0:c231,c254 6748 ? 00:01:17 qemu-system-x86<br />
system_u:system_r:svirt_t:s0:c695,c894 7664 ? 00:00:03 qemu-system-x86<br />
<br />
# Both VMs stopped (note that the type has remained as svirt_image_t)<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:svirt_image_t:s0 Shareable_VM.img<br />
</pre><br />
<br />
=== Static Labeling ===<br />
It is possible to set static labels on each image file, however a consequence of this is that the image cannot be cloned using the VMM, therefore an image for each VM will be required. This is the method used to configure VMs on MLS systems as there is a known label that would define the security level. With this method it is also possible to configure two or more VMs with the same security context so that they can share resources. A useful reference is at: [http://libvirt.org/formatdomain.html#seclabel http://libvirt.org/formatdomain.html#seclabel].<br />
<br />
If using the Virtual Machine Manager GUI, then by default it will start each VM running as they are built, therefore they need to be stopped and restarted once configured for static labels, the image file will also need to be relabeled. An example VM configuration follows where the VM has been created as <tt>Static_VM1</tt> using the F-20 <tt>targeted</tt> policy in enforcing mode (just so all errors are flagged during the build):<br />
<br />
* To set the required security context requires editing the <tt>Static_VM1</tt> configuration file using <tt>'''virsh'''(1)</tt> as follows:<br />
<pre><br />
virsh edit Static_VM1<br />
</pre><br />
<br />
Then add the following at the end of the file:<br />
<pre><br />
....<br />
</devices><br />
<br />
<!-- The <seclabel> tag needs to be placed btween the existing<br />
</devices> and </domain> tags --><br />
<br />
<seclabel type='static' model='selinux' relabel='no'><br />
<label>system_u:system_r:svirt_t:s0:c1022,c1023</label><br />
</seclabel><br />
<br />
</domain><br />
</pre><br />
<br />
: For this example <tt>svirt_t</tt> has been chosen as it is a valid context (however it will not run as explained in the text). This context will be written to the <tt>Static_VM1.xml</tt> configuration file in <tt>/etc/libvirt/qemu</tt>.<br />
<br />
* If the VM is now started an error will be shown as show in the this [http://selinuxproject.org/~rhaines/NB4-diagrams/21-error.png screen shot].<br />
: This is because the image file label is incorrect as by default it is labeled <tt>virt_image_t</tt> when the VM image is built (and <tt>svirt_t</tt> does not have read/write permission for this label):<br />
<pre><br />
# The default label of the image at build time:<br />
system_u:object_r:virt_image_t:s0 Static_VM1.img<br />
</pre><br />
<br />
: There are a number of ways to fix this, such as adding an allow rule or changing the image file label. In this example the image file label will be changed using <tt>'''chcon'''(1)</tt> as follows:<br />
<pre><br />
# This command is executed from /var/lib/libvirt/images<br />
#<br />
# This sets the correct type:<br />
chcon -t svirt_image_t Static_VM1.img<br />
</pre><br />
<br />
: Optionally, the image can also be relabeled so that the <tt><nowiki>[level]</nowiki></tt> is the same as the process using <tt>chcon</tt> as follows:<br />
<pre><br />
# This command is executed from /var/lib/libvirt/images<br />
#<br />
# Set the MCS label to match the process (optional step):<br />
chcon -l s0:c1022,c1023 Static_VM1.img<br />
</pre><br />
<br />
* Now that the image has been relabeled, the VM can now be started. <br />
<br />
The following example shows two static VMs (one is configured for <tt>unconfined_t</tt> that is allowed to run under the targeted policy - this was possible because the 's<tt>etsebool -P virt_transition_userdomain on</tt>'<tt> </tt>boolean was set that allows <tt>virtd_t</tt> domain to transition to a user domain (e.g. <tt>unconfined_t</tt>).<br />
<br />
{| border="1"<br />
| '''VM Name'''<br />
| '''Object'''<br />
| '''Static security context '''<br />
<br />
|-<br />
| Static_VM1<br />
| Process<br />
| system_u:system_r:svirt_t:s0:c1022,c1023<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:svirt_image_t:s0:c1022,c1023<br />
<br />
|-<br />
| Static_VM2<br />
| Process<br />
| system_u:system_r:unconfined_t:s0:c11,c22<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:virt_image_t:s0<br />
<br />
|}<br />
<br />
<br />
The running image <tt>ls -Z</tt> and <tt>ps -eZ</tt> are as follows, and for completeness an <tt>ls -Z</tt> is shown when both VMs have been stopped:<br />
<pre><br />
# Both VMs running (Note that Static_VM2 did not have file level reset):<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:svirt_image_t:s0:c1022,c1023 Static_VM1.img<br />
system_u:object_r:virt_image_t:s0 Static_VM2.img<br />
<br />
ps -eZ | grep qemu<br />
system_u:system_r:svirt_t:s0:c585,c813 6707 ? 00:00:45 qemu-system-x86<br />
system_u:system_r:unconfined_t:s0:c11,c22 6796 ? 00:00:26 qemu-system-x86<br />
<br />
# Both VMs stopped (note that Static_VM1.img was relabeled svirt_image_t<br />
# to enable it to run, however Static_VM2.img is still labeled<br />
# virt_image_t and runs okay. This is because the process is run as<br />
# unconfined_t that is allowed to use virt_image_t):<br />
system_u:object_r:svirt_image_t:s0:c1022,c1023 Static_VM1.img<br />
system_u:object_r:virt_image_t:s0 Static_VM2.img<br />
</pre><br />
<br />
== Xen Support ==<br />
This is not supported by SELinux in the usual way as it is built into the actual Xen software as a 'Flask/TE' extension<ref name="ftn27">This is a version of the SELinux security server, avc etc. that has been specifically ported for the Xen implementation.</ref> for the XSM (Xen Security Module). Also the Xen implementation has its own built-in policy (<tt>xen.te</tt>) and supporting definitions for access vectors, security classes and initial SIDs for the policy. These Flask/TE components run in Domain 0 as part of the domain management and control supporting the Virtual Machine Monitor (VMM) as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/22-xen.png Xen Hypervisor] diagram. <br />
<br />
The "[http://www.xen.org/files/Marketing/HowDoesXenWork.pdf How Does Xen Work] document describes the basic operation of Xen, the "[http://www.xen.org/files/xensummit_4/xsm-summit-041707_Coker.pdf Xen Security Modules]" describes the XSM/Flask implementation, and the <tt>xsm-flask.txt</tt> file in the Xen source package describes how SELinux and its supporting policy is implemented.<br />
<br />
However (just to confuse the issue), there is another Xen policy module (also called <tt>xen.te</tt>) in the Reference Policy to support the management of images etc. via the Xen console.<br />
<br />
For reference, the Xen policy supports additional policy language statements: <tt>iomemcon</tt>, <tt>ioportcon</tt>, <tt>pcidevicecon</tt> and <tt>pirqcon</tt> that are discussed in the [[XENStatements | SELinux Policy Xen Statements]].<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Networking | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_SandBox | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_VMNB VM2015-09-25T14:02:59Z<p>RichardHaines: </p>
<hr />
<div>= SELinux Virtual Machine Support =<br />
SELinux support is available in the KVM/QEMU and Xen virtual machine (VM) technologies<ref name="ftn25">KVM (Kernel-based Virtual Machine) and Xen are classed as 'bare metal' hypervisors and they rely on other services to manage the overall VM environment. QEMU (Quick Emulator) is an emulator that emulates the BIOS and I/O device functionality and can be used standalone or with KVM and Xen.</ref> that are discussed in the sections that follow, however the package documentation should be read for how these products actually work and how they are configured. <br />
<br />
Currently the main SELinux support for virtualisation is via <tt>libvirt</tt> that is an open-source virtualisation API used to dynamically load guest VMs. Security extensions were added as a part of the [http://selinuxproject.org/page/SVirt Svirt] project and the SELinux implementation for the KVM/QEMU package (<tt>qemu-kvm</tt> and <tt>libvirt</tt> rpms) is discussed using some examples. The Xen product has Flask/TE services that can be built as an optional service, although it can also use the security enhanced <tt>libvirt</tt> services as well.<br />
<br />
The sections that follow give an introduction to KVM/QEMU, then <tt>libvirt</tt> support with some examples using the Virtual Machine Manager to configure VMs, then an overview of the Xen implementation follows.<br />
<br />
To ensure all dependencies are installed run:<br />
<pre><br />
yum install libvirt<br />
yum install qemu<br />
yum install virt-manager<br />
</pre><br />
<br />
== KVM / QEMU Support ==<br />
KVM is a kernel loadable module that uses the Linux kernel as a hypervisor and makes use of a modified QEMU emulator to support the hardware I/O emulation. The "[http://www.redhat.com/f/pdf/rhev/DOC-KVM.pdf Kernel-based Virtual Machine]" document gives a good overview of how KVM and QEMU are implemented. It also provides an introduction to virtualisation in general. Note that KVM requires virtulisation support in the CPU (Intel-VT or AMD-V extensions).<br />
<br />
The SELinux support for VMs is implemented by the <tt>libvirt</tt> sub-system that is used to manage the VM images using a Virtual Machine Manager, and as KVM is based on Linux it has SELinux support by default. There are also Reference Policy modules to support the overall infrastructure (KVM support is in various kernel and system modules with a <tt>virt</tt> module supporting the <tt>libvirt</tt> services).The [http://selinuxproject.org/~rhaines/NB4-diagrams/18-kvm.png KVM Environment] diagram shows a high level overview with two VMs running in their own domains. The [[#libsvirt Support | libvirt Support]] section shows how to configure these and their VM image files.<br />
<br />
== libvirt Support ==<br />
The Svirt project added security hooks into the <tt>libvirt</tt> library that is used by the <tt>libvirtd</tt> daemon. This daemon is used by a number of VM products (such as KVM, QEMU and Xen) to start their VMs running as guest operating systems.<br />
<br />
The VM supplier can implement any security mechanism they require using a product specific libvirt [http://libvirt.org/drvqemu.html driver] that will load and manage the images. The SELinux implementation supports four methods of labeling VM images, processes and their resources with support from the Reference Policy <tt>modules/services/virt.*</tt> loadable module<ref name="ftn26">The various images would have been labeled by the <tt>virt</tt> module installation process (see the <tt>virt.fc</tt> module file or the policy <tt>file_contexts</tt> file <tt>libvirt</tt> entries). If not, then need to ensure it is relabeled by the most appropriate SELinux tool.</ref>. To support this labeling, <tt>libvirt</tt> requires an MCS or MLS enabled policy as the <tt>level</tt> entry of the security context is used (<tt>user:role:type:level</tt>).<br />
<br />
The link [http://libvirt.org/drvqemu.html#securityselinux http://libvirt.org/drvqemu.html#securityselinux] has details regarding the QEMU driver and the SELinux confinement modes it supports.<br />
<br />
== VM Image Labeling ==<br />
This sections assumes VM images have been generated using the simple Linux kernel available at: [http://wiki.qemu.org/Testing http://wiki.qemu.org/Testing] (the <tt>linux-0.2.img.bz2</tt> disk image), this image was renamed to reflect each test, for example '<tt>Dynamic_VM1.img</tt>'.<br />
<br />
These images can be generated using the VMM by selecting the 'Create a new virtual machine' menu, 'importing existing disk image' then in step 2 Browse... selecting 'Choose Volume: <tt>Dynamic_VM1.img</tt>' with OS type: <tt>Linux</tt>, Version: <tt>Generic 2.6.x kernel</tt> and change step 4 'Name' to <tt>Dynamic_VM1</tt>.<br />
<br />
=== Dynamic Labeling ===<br />
The default mode is where each VM is run under its own dynamically configured domain and image file therefore isolating the VMs from each other (i.e. every time the VM is run a different and unique MCS label will be generated to confine each VM to its own domain). This mode is implemented as follows:<br />
<br />
# An initial context for the process is obtained from the <tt><nowiki>/etc/selinux/<</nowiki>SELINUXTYPE>/contexts/virtual_domain_context</tt> file (the default is <tt>system_u:system_r:svirt_tcg_t:s0</tt>).<br />
# An initial context for the image file label is obtained from the <tt><nowiki>/etc/selinux/<</nowiki>SELINUXTYPE>/contexts/virtual_image_context</tt> file. The default is <tt>system_u:system_r:svirt_image_t:s0</tt> that allows read/write of image files.<br />
# When the image is used to start the VM, a random MCS <tt>level</tt> is generated and added to the process context and the image file context. The process and image files are then transitioned to the context by the<tt> libselinux</tt> API calls <tt>setfilecon</tt> and <tt>setexeccon</tt> respectively (see <tt>security_selinux.c</tt> in the <tt>libvirt </tt>source). The following example shows two running VM sessions each having different labels:<br />
<br />
{| border="1"<br />
| '''VM Name'''<br />
| '''Object'''<br />
| '''Dynamically assigned security context '''<br />
<br />
|-<br />
| Dynamic_VM1<br />
| Process<br />
| system_u:system_r:svirt_tcg_t:s0:c585,c813<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:svirt_image_t:s0:c585,c813<br />
<br />
|-<br />
| Dynamic_VM2<br />
| Process<br />
| system_u:system_r:svirt_tcg_t:s0:c535,c601<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:svirt_image_t:s0:c535,c601<br />
<br />
|}<br />
<br />
<br />
The running image <tt>ls -Z</tt> and <tt>ps -eZ</tt> are as follows, and for completeness an <tt>ls -Z</tt> is shown when both VMs have been stopped:<br />
<pre><br />
# Both VMs running:<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:svirt_image_t:s0:c585,c813 Dynamic_VM1.img<br />
system_u:object_r:svirt_image_t:s0:c535,c601 Dynamic_VM2.img<br />
<br />
ps -eZ | grep qemu<br />
system_u:system_r:svirt_tcg_t:s0:c585,c813 8707 ? 00:00:44 qemu-system-x86<br />
system_u:system_r:svirt_tcg_t:s0:cc535,c601 8796 ? 00:00:37 qemu-system-x86<br />
<br />
# Both VMs stopped (note that the categories are now missing AND<br />
# the type has changed from svirt_image_t to virt_image_t):<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:virt_image_t:s0 Dynamic_VM1.img<br />
system_u:object_r:virt_image_t:s0 Dynamic_VM2.img<br />
</pre><br />
<br />
=== Shared Image ===<br />
If the disk image has been set to shared, then a dynamically allocated <tt>level</tt> will be generated for each VM process instance, however there will be a single instance of the disk image.<br />
<br />
The Virtual Machine Manager can be used to set the image as shareable by checking the <tt>Shareable</tt> box as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/19-shareable.png Setting the Virtual Disk as Shareable] screen shot.<br />
<br />
This will set the image (<tt>Shareable_VM.xml</tt>) resource XML configuration file located in the <tt>/etc/libvirt/qemu</tt> directory <tt><nowiki><disk></nowiki></tt> contents as follows:<br />
<pre><br />
# /etc/libvirt/qemu/Shareable_VM.xml:<br />
<br />
<disk type='file' device='disk'><br />
<driver name='qemu' type='raw'/><br />
<source file='/var/lib/libvirt/images/Shareable_VM.img'/><br />
<target dev='hda' bus='ide'/><br />
<shareable/><br />
<address type='drive' controller='0' bus='0' unit='0'/><br />
</disk><br />
</pre><br />
<br />
As the two VMs will share the same image, the <tt>Shareable_VM</tt> service needs to be cloned and the VM resource name selected was <tt>Shareable_VM-clone</tt> as shown in this [http://selinuxproject.org/~rhaines/NB4-diagrams/20-clone.png screen shot].<br />
<br />
The resource XML file <tt><nowiki><disk></nowiki></tt> contents generated are shown - note that it has the same <tt>source file</tt> name as the <tt>Shareable_VM.xml</tt> file shown above.<br />
<pre><br />
# /etc/libvirt/qemu/Shareable_VM-clone.xml:<br />
<br />
<disk type='file' device='disk'><br />
<driver name='qemu' type='raw'/><br />
<source file='/var/lib/libvirt/images/Shareable_VM.img'/><br />
<target dev='hda' bus='ide'/><br />
<shareable/><br />
<address type='drive' controller='0' bus='0' unit='0'/><br />
</disk><br />
</pre><br />
<br />
<br />
With the targeted policy on F-20 the shareable option gave a error when the VMs were run as follows:<br />
<pre><br />
Could not allocate dynamic translator buffer<br />
</pre><br />
<br />
The audit log contained the following AVC message:<br />
<pre><br />
type=AVC msg=audit(1326028680.405:367): avc: denied { execmem } for pid=5404 comm="qemu-system-x86" <br />
scontext=system_u:system_r:svirt_t:s0:c121,c746 tcontext=system_u:system_r:svirt_t:s0:c121,c746 tclass=process<br />
</pre><br />
<br />
To overcome this error, the following boolean needs to be enabled with <tt>'''setsebool'''(8)</tt> to allow access to shared memory (the <tt>-P</tt> option will set the boolean across reboots):<br />
<pre><br />
setsebool -P virt_use_execmem on<br />
</pre><br />
<br />
Now that the image has been configured as shareable, the following initialisation process will take place:<br />
<br />
# An initial context for the process is obtained from the <tt><nowiki>/etc/selinux/<</nowiki>SELINUXTYPE>/contexts/virtual_domain_context</tt> file (the default is <tt>system_u:system_r:svirt_tcg_t:s0</tt>).<br />
# An initial context for the image file label is obtained from the <tt><nowiki>/etc/selinux/<</nowiki>SELINUXTYPE>/contexts/virtual_image_context</tt> file. The default is <tt>system_u:system_r:svirt_image_t:s0</tt> that allows read/write of image files.<br />
# When the image is used to start the VM a random MCS level is generated and added to the process context (but not the image file). The process is then transitioned to the appropriate context by the<tt> libselinux</tt> API calls <tt>setfilecon</tt> and <tt>setexeccon</tt> respectively. The following example shows each VM having the same file label but different process labels:<br />
<br />
{| border="1"<br />
| '''VM Name'''<br />
| '''Object'''<br />
| '''Security context '''<br />
<br />
|-<br />
| Shareable_VM<br />
| Process<br />
| system_u:system_r:svirt_tcg_t:s0:c231,c245<br />
<br />
|-<br />
| Shareable_VM-clone<br />
| Process<br />
| system_u:system_r:svirt_tcg_t:s0:c695,c894<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:svirt_image_t:s0<br />
<br />
|}<br />
<br />
<br />
The running image <tt>ls -Z</tt> and <tt>ps -eZ</tt> are as follows and for completeness an <tt>ls -Z</tt> is shown when both VMs have been stopped:<br />
<pre><br />
# Both VMs running and sharing same image:<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:svirt_image_t:s0 Shareable_VM.img<br />
<br />
# but with separate processes:<br />
ps -eZ | grep qemu<br />
system_u:system_r:svirt_t:s0:c231,c254 6748 ? 00:01:17 qemu-system-x86<br />
system_u:system_r:svirt_t:s0:c695,c894 7664 ? 00:00:03 qemu-system-x86<br />
<br />
# Both VMs stopped (note that the type has remained as svirt_image_t)<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:svirt_image_t:s0 Shareable_VM.img<br />
</pre><br />
<br />
=== Static Labeling ===<br />
It is possible to set static labels on each image file, however a consequence of this is that the image cannot be cloned using the VMM, therefore an image for each VM will be required. This is the method used to configure VMs on MLS systems as there is a known label that would define the security level. With this method it is also possible to configure two or more VMs with the same security context so that they can share resources. A useful reference is at: [http://libvirt.org/formatdomain.html#seclabel http://libvirt.org/formatdomain.html#seclabel].<br />
<br />
If using the Virtual Machine Manager GUI, then by default it will start each VM running as they are built, therefore they need to be stopped and restarted once configured for static labels, the image file will also need to be relabeled. An example VM configuration follows where the VM has been created as <tt>Static_VM1</tt> using the F-20 <tt>targeted</tt> policy in enforcing mode (just so all errors are flagged during the build):<br />
<br />
* To set the required security context requires editing the <tt>Static_VM1</tt> configuration file using <tt>'''virsh'''(1)</tt> as follows:<br />
<pre><br />
virsh edit Static_VM1<br />
</pre><br />
<br />
Then add the following at the end of the file:<br />
<pre><br />
....<br />
</devices><br />
<br />
<!-- The <seclabel> tag needs to be placed btween the existing<br />
</devices> and </domain> tags --><br />
<br />
<seclabel type='static' model='selinux' relabel='no'><br />
<label>system_u:system_r:svirt_t:s0:c1022,c1023</label><br />
</seclabel><br />
<br />
</domain><br />
</pre><br />
<br />
: For this example <tt>svirt_t</tt> has been chosen as it is a valid context (however it will not run as explained in the text). This context will be written to the <tt>Static_VM1.xml</tt> configuration file in <tt>/etc/libvirt/qemu</tt>.<br />
<br />
* If the VM is now started an error will be shown as show in the this [http://selinuxproject.org/~rhaines/NB4-diagrams/21-error.png screen shot].<br />
: This is because the image file label is incorrect as by default it is labeled <tt>virt_image_t</tt> when the VM image is built (and <tt>svirt_t</tt> does not have read/write permission for this label):<br />
<pre><br />
# The default label of the image at build time:<br />
system_u:object_r:virt_image_t:s0 Static_VM1.img<br />
</pre><br />
<br />
: There are a number of ways to fix this, such as adding an allow rule or changing the image file label. In this example the image file label will be changed using <tt>'''chcon'''(1)</tt> as follows:<br />
<pre><br />
# This command is executed from /var/lib/libvirt/images<br />
#<br />
# This sets the correct type:<br />
chcon -t svirt_image_t Static_VM1.img<br />
</pre><br />
<br />
: Optionally, the image can also be relabeled so that the <tt><nowiki>[level]</nowiki></tt> is the same as the process using <tt>chcon</tt> as follows:<br />
<pre><br />
# This command is executed from /var/lib/libvirt/images<br />
#<br />
# Set the MCS label to match the process (optional step):<br />
chcon -l s0:c1022,c1023 Static_VM1.img<br />
</pre><br />
<br />
* Now that the image has been relabeled, the VM can now be started. <br />
<br />
The following example shows two static VMs (one is configured for <tt>unconfined_t</tt> that is allowed to run under the targeted policy - this was possible because the 's<tt>etsebool -P virt_transition_userdomain on</tt>'<tt> </tt>boolean was set that allows <tt>virtd_t</tt> domain to transition to a user domain (e.g. <tt>unconfined_t</tt>).<br />
<br />
{| border="1"<br />
| '''VM Name'''<br />
| '''Object'''<br />
| '''Static security context '''<br />
<br />
|-<br />
| Static_VM1<br />
| Process<br />
| system_u:system_r:svirt_t:s0:c1022,c1023<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:svirt_image_t:s0:c1022,c1023<br />
<br />
|-<br />
| Static_VM2<br />
| Process<br />
| system_u:system_r:unconfined_t:s0:c11,c22<br />
<br />
|-<br />
| <br />
| File<br />
| system_u:system_r:virt_image_t:s0<br />
<br />
|}<br />
<br />
<br />
The running image <tt>ls -Z</tt> and <tt>ps -eZ</tt> are as follows, and for completeness an <tt>ls -Z</tt> is shown when both VMs have been stopped:<br />
<pre><br />
# Both VMs running (Note that Static_VM2 did not have file level reset):<br />
ls -Z /var/lib/libvirt/images<br />
system_u:object_r:svirt_image_t:s0:c1022,c1023 Static_VM1.img<br />
system_u:object_r:virt_image_t:s0 Static_VM2.img<br />
<br />
ps -eZ | grep qemu<br />
system_u:system_r:svirt_t:s0:c585,c813 6707 ? 00:00:45 qemu-system-x86<br />
system_u:system_r:unconfined_t:s0:c11,c22 6796 ? 00:00:26 qemu-system-x86<br />
<br />
# Both VMs stopped (note that Static_VM1.img was relabeled svirt_image_t<br />
# to enable it to run, however Static_VM2.img is still labeled<br />
# virt_image_t and runs okay. This is because the process is run as<br />
# unconfined_t that is allowed to use virt_image_t):<br />
system_u:object_r:svirt_image_t:s0:c1022,c1023 Static_VM1.img<br />
system_u:object_r:virt_image_t:s0 Static_VM2.img<br />
</pre><br />
<br />
== Xen Support ==<br />
This is not supported by SELinux in the usual way as it is built into the actual Xen software as a 'Flask/TE' extension<ref name="ftn27">This is a version of the SELinux security server, avc etc. that has been specifically ported for the Xen implementation.</ref> for the XSM (Xen Security Module). Also the Xen implementation has its own built-in policy (<tt>xen.te</tt>) and supporting definitions for access vectors, security classes and initial SIDs for the policy. These Flask/TE components run in Domain 0 as part of the domain management and control supporting the Virtual Machine Monitor (VMM) as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/22-xen.png Xen Hypervisor] diagram. <br />
<br />
The "[http://www.xen.org/files/Marketing/HowDoesXenWork.pdf How Does Xen Work] document describes the basic operation of Xen, the "[http://www.xen.org/files/xensummit_4/xsm-summit-041707_Coker.pdf Xen Security Modules]" describes the XSM/Flask implementation, and the <tt>xsm-flask.txt</tt> file in the Xen source package describes how SELinux and its supporting policy is implemented.<br />
<br />
However (just to confuse the issue), there is another Xen policy module (also called <tt>xen.te</tt>) in the Reference Policy to support the management of images etc. via the Xen console.<br />
<br />
For reference, the Xen policy supports additional policy language statements: <tt>iomemcon</tt>, <tt>ioportcon</tt>, <tt>pcidevicecon</tt> and <tt>pirqcon</tt> that are discussed in the [[KernelPolicyLanguage#Xen Statements | SELinux Policy Xen Statements]].<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Networking | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_SandBox | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_NetworkingNB Networking2015-09-25T14:01:19Z<p>RichardHaines: /* SELinux Networking Support */</p>
<hr />
<div>= SELinux Networking Support =<br />
SELinux supports the following types of network labeling:<br />
: '''Internal labeling''' - This is where network objects are labeled and managed internally within a single machine (i.e. their labels are not transmitted as part of the session with remote systems). There are two types supported: SECMARK and NetLabel. There was a service known as 'compat_net' controls, however that was removed in kernel 2.6.30.<br />
: '''Labeled Networking''' - This is where labels are passed to/from remote systems where they can be interpreted and a MAC policy enforced on each system. There are two types supported: Labeled IPSec and CIPSO (Commercial IP Security Option).<br />
<br />
There are two policy capability options that can be set within policy using the <tt>policycap</tt> statement that affect networking configuration:<br />
: '''network_peer_controls''' - This is always enabled in the latest Reference Policy source. The [http://selinuxproject.org/~rhaines/NB4-diagrams/14-fallback.png Fallback Labeling] diagram shows the differences between the policy capability being set to 0 and 1.<br />
: '''always_use_network''' - This capability would normally be set to false. If true SECMARK and NetLabel peer labeling are always enabled even if there are no SECMARK, NetLabel or Labeled IPsec rules configured. This forces checking of the <tt>packet</tt> class to protect the system should any rules fail to load or they get maliciously flushed. Requires kernel 3.13 minimum.<br />
<br />
The policy capability settings are available in userspace via the SELinux filesystem as shown in the [[NB_LSM#SELinux Filesystem | SELinux Filesystem]] section.<br />
<br />
To support peer labeling and CIPSO the NetLabel tools need to be installed:<br />
<pre><br />
yum install netlabel_tools<br />
</pre><br />
<br />
To support Labeled IPSec the IPSec tools need to be installed:<br />
<pre><br />
yum install ipsec-tools<br />
</pre><br />
<br />
It is also possible to use an alternative Labeled IPSec service that was OpenSwan but is now distributed as LibreSwan:<br />
<pre><br />
yum install libreswan <br />
</pre><br />
<br />
It is important to note that the kernel must be configured to support these services. The F-20 kernels are configured to handle all the above services.<br />
<br />
The Linux networking package <tt>iproute</tt> has an SELinux aware socket statistics command <tt>'''ss'''(8)</tt> that will show the SELinux context of network processes (<tt>-Z</tt> or <tt>--context</tt> option) and network sockets (<tt>-z</tt> or <tt>--contexts</tt> option). Although note that the socket contexts are taken from the inode associated to the socket and not from the actual kernel socket structure (as currently there is no standard kernel/userspace interface to achieve this).<br />
<br />
== SECMARK ==<br />
SECMARK makes use of the standard kernel NetFilter framework that underpins the GNU / Linux IP networking sub-system. NetFilter services automatically inspects all incoming and outgoing packets and can place controls on interfaces, IP addresses (nodes) and ports with the added advantage of connection tracking. The SECMARK security extensions allow security contexts to be added to packets (SECMARK) or sessions (CONNSECMARK).<br />
<br />
The NetFilter framework inspects and tag packets with labels as defined within '''iptables'''(8) and then uses the security framework (e.g. SELinux) to enforce the policy rules. Therefore SECMARK services are not SELinux specific as other security modules using the LSM infrastructure could also implement the same services (e.g. SMACK).<br />
<br />
While the implementation of iptables / NetFilter is beyond the scope of this Notebook, there are tutorials available<ref name="ftn16"><sup>There is a very good tutorial at [http://www.frozentux.net/documents/iptables-tutorial/ http://www.frozentux.net/documents/iptables-tutorial/], however it does not cover the security table that was introduced by: [http://lwn.net/Articles/267140/ http://lwn.net/Articles/267140/]. It is still possible to use the 'mangle table' to hold security labels.</sup></ref>. The [http://selinuxproject.org/~rhaines/NB4-diagrams/13-secmark.png SECMARK Processing] diagram shows the basic structure with the process working as follows:<br />
* A table called the 'security table' is used to define the parameters that identify and 'mark' packets that can then be tracked as the packet travels through the networking sub-system. These 'marks' are called SECMARK and CONNSECMARK.<br />
* A SECMARK is placed against a packet if it matches an entry in the security table applying a label that can then be used to enforce policy on the packet.<br />
* The CONNSECMARK 'marks' all packets within a session<ref name="ftn17"><sup>For example, an ftp session where the server is listening on a specific port (the destination port) but the client will be assigned a random source port. The CONNSECMARK will ensure that all packets for the ftp session are marked with the same label.</sup></ref> with the appropriate label that can then be used to enforce policy.<br />
<br />
An example iptables<ref name="ftn18"><sup>The tables will not load correctly if the policy does not allow the iptables domain to relabel the security table entries unless permissive mode is enabled (i.e. iptables must have the relabel permission for each entry in the table).</sup></ref> 'security table' entry is as follows:<br />
<pre><br />
# Flush the security table first:<br />
iptables -t security -F<br />
<br />
#-------------- INPUT IP Stream --------------------#<br />
<br />
# This INPUT rule sets all packets to msg_filter.default_packet: as it is executed first:<br />
iptables -t security -A INPUT -i lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system.user:object_r:msg_filter.default_packet:s0<br />
<br />
# These rules will replace the above context with the internal or<br />
# external gateway if port 9999 or 1111 is found in either the source or<br />
# destination port of the packet:<br />
iptables -t security -A INPUT -i lo -p tcp --dport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0<br />
iptables -t security -A INPUT -i lo -p tcp --sport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0<br />
#<br />
# The internal gateway:<br />
iptables -t security -A INPUT -i lo -p tcp --dport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0<br />
iptables -t security -A INPUT -i lo -p tcp --sport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0<br />
<br />
iptables -t security -A INPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --save<br />
<br />
#-------------- OUTPUT IP Stream --------------------#<br />
<br />
# This OUTPUT rule sets all packets to msg_filter.default_packet: as it is executed first:<br />
iptables -t security -A OUTPUT -o lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system.user:object_r:msg_filter.default_packet:s0<br />
<br />
# These rules will replace the above context with the internal or<br />
# external gateway if port 9999 or 1111 is found in either the source or<br />
# destination port of the packet:<br />
iptables -t security -A OUTPUT -o lo -p tcp --dport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0<br />
iptables -t security -A OUTPUT -o lo -p tcp --sport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0<br />
#<br />
# The internal gateway:<br />
iptables -t security -A OUTPUT -o lo -p tcp --dport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0<br />
iptables -t security -A OUTPUT -o lo -p tcp --sport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0<br />
<br />
iptables -t security -A OUTPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --save<br />
</pre> <br />
<br />
An example policy that makes use of SECMARK services is described in the Notebook source tarball. There are also articles "[http://paulmoore.livejournal.com/4281.html Transitioning to Secmark] and "[http://james-morris.livejournal.com/11010.html New secmark-based network controls for SELinux]" that explain the services.<br />
<br />
== NetLabel - Fallback Peer Labeling ==<br />
Fallback labeling can optionally be implemented on a system if the Labeled IPSec or CIPSO is not being used (hence 'fallback labeling'). If either Labeled IPSec or CIPSO are being used, then these take priority. There is an article "[http://paulmoore.livejournal.com/1758.html Fallback Label Configuration Example]" that explains their usage, the <tt>'''netlabelctl'''(8)</tt> man page is also a useful reference.<br />
<br />
The example message filter has an optional module that makes use of fallback labels and can be found in the Notebook source tarball.<br />
<br />
The network peer controls have been extended to support an additional object class of 'peer' that is enabled by default in the F-20 policy as the network_peer_controls in <tt>/sys/fs/selinux/policy_capabilities</tt> is set to '<tt>1</tt>'. The [http://selinuxproject.org/~rhaines/NB4-diagrams/14-fallback.png Fallback Labeling] diagram shows the differences between the policy capability network_peer_controls being set to 0 and 1.<br />
<br />
== NetLabel - CIPSO ==<br />
To allow security levels to be passed over a network between MLS systems<ref name="ftn19"><sup>Note only the security levels are passed over the network as the other components of the security context are not part of standard MLS systems (as it may be that the remote end is a Trusted Solaris system).</sup></ref>, the CIPSO protocol is used. This is defined in the [http://tools.ietf.org/html/draft-ietf-cipso-ipsecurity-01 CIPSO Internet Draft] document (this is an obsolete document, however the protocol is still in use). The protocol defines how security levels are encoded in the IP packet header.<br />
<br />
Note that only the level component of the security context is passed over the network. The exception is in loopback mode as explained in "[http://paulmoore.livejournal.com/7234.html Full SELinux Labels Over Loopback with NetLabel and CIPSO]" available at [http://paulmoore.livejournal.com/7234.html http://paulmoore.livejournal.com/7234.html].<br />
<br />
The protocol is implemented by the NetLabel service (see <tt>'''netlabelctl'''(8)</tt>) and can be used by other security modules that use the LSM infrastructure. The NetLabel implementation supports:<br />
# Tag Type 1 bit mapped format that allows a maximum of 256 sensitivity levels and 240 categories to be mapped.<br />
# A non-translation option where labels are passed to / from systems unchanged (for host to host communications as show in the [http://selinuxproject.org/~rhaines/NB4-diagrams/15-mls1.png MLS Systems on the same network] diagram).<br />
# A translation option where both the sensitivity and category components can be mapped for systems that have either different definitions for labels or information can be exchanged over different networks (for example using an SELinux enabled gateway as a guard as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/16-mls2.png MLS Systems on different networks communicating via a gateway] diagram).<br />
<br />
== Labeled IPSec ==<br />
Labeled IPSec has been built into the standard GNU / Linux IPSec services as described in the "[http://nsrc.cse.psu.edu/tech_report/NAS-TR-0037-2006.pdf Leveraging IPSec for Distributed Authorization]. the [http://selinuxproject.org/~rhaines/NB4-diagrams/17-ipsec.png IPSec communications] diagram shows the basic components that form the service based on IPSec tools where it is generally used to set up either an encrypted tunnel between two machines<ref name="ftn20"><sup>Also known as a virtual private network (VPN).</sup></ref> or an encrypted transport session. The extensions defined in describe how the security context is configured and negotiated between the two systems (called security associations (SAs) in IPSec terminology).<br />
<br />
Basically what happens is as follows<ref name="ftn21"><sup>There is an “IPSec HOWTO" at [http://www.ipsec-howto.org/ http://www.ipsec-howto.org] that gives the gory details, however it does not cover Labeled IPSec.</sup></ref>:<br />
# The security policy database (SPD) defines the security communications characteristics to be used between the two systems. This is populated using the '''setkey'''(8) utility with an example shown in the [[#Configuration Example | Configuration Example]] section.<br />
# The SAs have their configuration parameters such as protocols used for securing packets, encryption algorithms and how long the keys are valid held in the Security Association database (SAD). For Labeled IPSec the security context (or labels) is also defined within the SAD. SAs can be negotiated between the two systems using either racoon or pluto<ref name="ftn22"><sup>These are the Internet Key Exchange (IKE) daemons that exchange encryption keys securely and also supports Labeled IPSec parameter exchanges.</sup></ref> that will automatically populate the SAD or manually by the setkey utility (see the example below).<br />
# Once the SAs have been negotiated and agreed, the link should be active.<br />
<br />
A point to note is that SAs are one way only, therefore when two systems are communicating (using the above example), one system will have an SA, SAout for processing outbound packets and another SA, SAin, for processing the inbound packets. The other system will also create two SAs for processing its packets. <br />
<br />
Each SA will share the same cryptographic parameters such as keys and protocol<ref name="ftn23"><sup>The GNU / Linux version supports a number of secure protocols, see '''setkey'''(8) for details.</sup></ref> (e.g. ESP (encapsulated security payload) and AH (authentication header)). <br />
<br />
The object class used for the association of an SA is association and the permissions available are as follows:<br />
<br />
{| border="1"<br />
| polmatch<br />
| Match the SPD context (-ctx) entry to an SELinux domain (that is contained in the SAD -ctx entry)<br />
<br />
|-<br />
| recvfrom<br />
| Receive from an IPSec association.<br />
<br />
|-<br />
| sendto<br />
| Send to an IPSec association.<br />
<br />
|-<br />
| setcontext<br />
| Set the context of an IPSec association on creation (e.g. when running setkey the process will require this permission to set the context in the SAD and SPD, also racoon / <tt>pluto</tt> will need this permission to build the SAD).<br />
<br />
|}<br />
<br />
<br />
When running Labeled IPSec it is recommended that the systems use the same type/version of policy to avoid any problems with them having different meanings.<br />
<br />
There are worked examples of Labeled IPSec sessions showing manual configuration using <tt>setkey</tt> and IKE exchanges using racoon<ref name="ftn24"><sup>Unfortunately racoon core dumps when using non MCS/MLS policies.</sup></ref> and LibreSwan (<tt>pluto</tt>) configurations in the Notebook source tarball (note that the LibreSwan examples use the kernel <tt>netkey</tt> services).<br />
<br />
There is a further example in the "[http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ Secure Networking with SELinux]" article.<br />
<br />
There is a good reference covering "Basic Labeled IPsec Configuration" available at:<br />
: [http://www.redhat.com/archives/redhat-lspp/2006-November/msg00051.html http://www.redhat.com/archives/redhat-lspp/2006-November/msg00051.html]<br />
<br />
<br />
=== Configuration Examples ===<br />
There are two possible labeled IPSec solutions available:<br />
: IPSec Tools - This uses the <tt>'''setkey'''(8)</tt> tools and <tt>'''racoon'''(8)</tt> Internet Key Exchange (IKE) daemon.<br />
: LibreSwan - This uses <tt>'''ipsec'''(8)</tt> tools and <tt>'''pluto'''(8)</tt> Internet Key Exchange (IKE) daemon.<br />
<br />
Both work in much the same way but use different configuration files with samples shown below. The one point they have in common is that to start any session for label exchange using IKE, <tt>setkey</tt> must be used to initially set up the labels in the security policy database (SPD) on each machine.<br />
<br />
Another point to note is that if interoperating between racoon and pluto the IPSEC Security Association Attribute values are different:<br />
<br />
* <tt>racoon</tt> has this hard-wired to a value of '<tt>10</tt>'.<br />
* <tt>pluto</tt> is configurable with a default of '<tt>32001</tt>'. To interoperate with <tt>racoon</tt> the <tt>'''ipsec.conf'''(5)</tt> file must have:<br />
<pre><br />
config setup<br />
secctx_attr_value = 10<br />
</pre><br />
<br />
The following example configurations show the common setkey configuration to set up the SPD entries and then a sample supporting racoon and pluto (LibreSwan) configuration file:<br />
<br />
Add label / context to SPD for loopback:<br />
<pre><br />
# setkey -f configuration file entries for RACOON SA configuration<br />
#<br />
# If the Internal Gateway module (int_gateway.conf) is not loaded,<br />
# then the entries should be removed from this file.<br />
#<br />
<br />
# Flush the SAD and SPD<br />
flush;<br />
spdflush;<br />
<br />
#<br />
########### Security Policy Database entries ##########################<br />
#<br />
<br />
# Note that the only part of the security context matched against is<br />
# the 'type' (e.g. ext_gateway_t).<br />
<br />
# Security policies for external gateway:<br />
spdadd 127.0.0.1 127.0.0.1 tcp<br />
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0"<br />
-P out ipsec esp/transport//require;<br />
<br />
spdadd 127.0.0.1 127.0.0.1 tcp<br />
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0"<br />
-P in ipsec esp/transport//require;<br />
<br />
# Security policies for internal gateway:<br />
spdadd 127.0.0.1 127.0.0.1 tcp<br />
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.int_gateway.process:s0"<br />
-P out ipsec esp/transport//require;<br />
<br />
spdadd 127.0.0.1 127.0.0.1 tcp<br />
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.int_gateway.process:s0"<br />
-P in ipsec esp/transport//require;<br />
</pre><br />
<br />
racoon configuration:<br />
<pre><br />
# Racoon IKE daemon configuration file.<br />
# See 'man racoon.conf' for a description of the format and entries.<br />
<br />
path include "/etc/racoon";<br />
path pre_shared_key "/etc/racoon/psk.txt";<br />
path certificate "/etc/racoon/certs";<br />
path script "/etc/racoon/scripts";<br />
<br />
sainfo anonymous<br />
{<br />
lifetime time 1 hour ;<br />
encryption_algorithm 3des, blowfish 448, rijndael ;<br />
authentication_algorithm hmac_sha1, hmac_md5 ;<br />
compression_algorithm deflate ;<br />
}<br />
</pre><br />
<br />
LibreSwan / pluto loopback configuration:<br />
<pre><br />
# /etc/ipsec.conf - Libreswan IPsec configuration file<br />
<br />
version 2.0<br />
config setup<br />
plutorestartoncrash=false<br />
protostack=netkey<br />
plutodebug="all"<br />
<br />
# A "secctx_attr_value" is optional for >= 3.6 as defaults to this:<br />
secctx_attr_value = 32001<br />
<br />
conn labeled_loopback_test<br />
auto=start<br />
rekey=no<br />
authby=secret<br />
type=transport<br />
left=127.0.0.1<br />
right=127.0.0.1<br />
ike=3des-sha1<br />
phase2=esp<br />
phase2alg=aes-sha1<br />
loopback=yes<br />
labeled_ipsec=yes<br />
policy_label=unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0<br />
leftprotoport=tcp<br />
rightprotoport=tcp<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Userspace_Libraries | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_VM | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_LSMNB LSM2015-09-25T13:58:45Z<p>RichardHaines: /* The SELinux Module */</p>
<hr />
<div>= Linux Security Module and SELinux =<br />
This section gives a high level overview of the LSM and SELinux internal kernel structure and workings as enabled in kernel 3.14. A more detailed view can be found in the "[http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml Implementing SELinux as a Linux Security Module]" that was used extensively to develop this section (and also using the SELinux kernel source code). The major areas covered are:<br />
# How the LSM and SELinux modules work together.<br />
# The major SELinux internal services.<br />
# The <tt>fork</tt> and <tt>exec</tt> system calls are followed through as an example to tie in with the transition process covered in the [[NB_Domain_and_Object_Transitions#Domain Transition | Domain Transition]] section.<br />
# The SELinux filesystem <tt>/sys/fs/selinux</tt>.<br />
# The <tt>/proc</tt> filesystem area most applicable to SELinux.<br />
<br />
== The LSM Module ==<br />
The LSM is the Linux security framework that allows 3<sup>rd</sup> party access control mechanisms to be linked into the GNU / Linux kernel. Currently there are five 3<sup>rd</sup> party services that utilise the LSM: <br />
<br />
# SELinux - the subject of this Notebook.<br />
# AppArmor is a MAC service based on pathnames and does not require labeling or relabeling of filesystems. See [http://wiki.apparmor.net/ http://wiki.apparmor.net] for details.<br />
# Simplified Mandatory Access Control Kernel (SMACK). See [http://www.schaufler-ca.com/ http://www.schaufler-ca.com/] for details.<br />
# Tomoyo that is a name based MAC and details can be found at [http://sourceforge.jp/projects/tomoyo/docs http://sourceforge.jp/projects/tomoyo/docs].<br />
# Yama extends the DAC support for <tt>ptrace</tt>. See <tt>Documentation/security/Yama.txt</tt> for further details.<br />
<br />
The basic idea behind LSM is to:<br />
* Insert security function hooks and security data structures in the various kernel services to allow access control to be applied over and above that already implemented via DAC. The type of service that have hooks inserted are shown in Table 5 with an example task and program execution shown in the [[#Fork Walk-thorough | Fork Walk-thorough]] and [[#Process Transition Walk-thorough | Process Transition Walk-thorough]] sections.<br />
* Allow registration and initialisation services for the 3<sup>rd</sup> party security modules.<br />
* Allow process security attributes to be available to userspace services by extending the <tt>/proc</tt> filesystem with a security namespace as shown in Table 2. These are located at:<br />
<pre><br />
/proc/<self | pid>/attr/<attr><br />
/proc/<self | pid>/task/<tid>/attr/<attr><br />
</pre><br />
<br />
: Where <tt><nowiki><pid></nowiki></tt> is the process id, <tt><nowiki><tid></nowiki></tt> is the thread id and <tt><nowiki><attr></nowiki></tt> is the entry described in Table 2.<br />
<br />
* Support filesystems that use extended attributes (SELinux uses <tt>security.selinux</tt> as explained in the [[NB_Objects#Labeling_Extended_Attribute_Filesystems | Labeling Extended Attribute Filesystems]] section).<br />
* Consolidate the Linux capabilities into an optional module.<br />
<br />
It should be noted that the LSM does not provide any security services itself, only the hooks and structures for supporting 3<sup>rd</sup> party modules. If no 3<sup>rd</sup> party module is loaded, the capabilities module becomes the default module thus allowing standard DAC access control.<br />
<br />
<center>'''Table 1: LSM Hooks - '''''These are the kernel services that LSM has inserted security hooks and structures to allow access control to be managed by 3<sup>rd</sup> party modules (see <tt>./linux-3.14/include/linux/security.h</tt>).''</center><br />
{| border="1"<br />
| Program execution<br />
| Filesystem operations<br />
| Inode operations<br />
<br />
|-<br />
| File operations<br />
| Task operations<br />
| Netlink messaging<br />
<br />
|-<br />
| Unix domain networking<br />
| Socket operations<br />
| XFRM operations<br />
<br />
|-<br />
| Key Management operations<br />
| IPC operations<br />
| Memory Segments<br />
<br />
|-<br />
| Semaphores<br />
| Capability<br />
| Sysctl<br />
<br />
|-<br />
| Syslog<br />
| Audit<br />
| <br />
<br />
|}<br />
<br />
<br />
<center>'''Table 2: /proc Filesystem attribute files''' - ''These files are used by the kernel services and libselinux (for userspace) to manage setting and reading of security contexts within the LSM defined data structures.''</center><br />
{| border="1"<br />
! <center>/proc/self/attr/ File Name</center><br />
! Permissions<br />
! Function<br />
<br />
|-<br />
| current<br />
| -rw-rw-rw-<br />
| Contains the current process security context.<br />
<br />
|-<br />
| exec<br />
| -rw-rw-rw-<br />
| Used to set the security context for the next exec call.<br />
<br />
|-<br />
| fscreate<br />
| -rw-rw-rw-<br />
| Used to set the security context of a newly created file.<br />
<br />
|-<br />
| keycreate<br />
| -rw-rw-rw-<br />
| Used to set the security context for keys that are cached in the kernel.<br />
<br />
|-<br />
| prev<br />
| -r--r--r--<br />
| Contains the previous process security context.<br />
<br />
|-<br />
| sockcreate<br />
| -rw-rw-rw-<br />
| Used to set the security context of a newly created socket.<br />
<br />
|}<br />
<br />
<br />
The major kernel source files (relative to <tt>./linux-3.14/security</tt>) that form the LSM are shown in Table 7. However there is one major header file (<tt>include/linux/security.h</tt>) that describes all the LSM security hooks and structures.<br />
<br />
<center>'''Table 3: The core LSM source modules.'''</center><br />
{| border="1"<br />
! Name<br />
! Function<br />
<br />
|-<br />
| capability.c<br />
| Some capability functions were in various kernel modules have been consolidated into these source files.<br />
<br />
|-<br />
| commoncap.c<br />
<br />
|-<br />
| device_cgroup.c<br />
<br />
|-<br />
| inode.c<br />
| This allows the 3<sup>rd</sup> party security module to initialise a security filesystem. In the case of SELinux this would be <tt>/sys/fs/selinux</tt> that is defined in the <tt>selinux/selinuxfs.c</tt> source file. <br />
<br />
|-<br />
| security.c<br />
| Contains the LSM framework initialisation services that will set up the hooks described in <tt>security.h</tt> and those in the capability source files. It also provides functions to initialise 3<sup>rd</sup> party modules. <br />
<br />
|-<br />
| lsm_audit.c<br />
| Contains common LSM audit functions.<br />
<br />
|-<br />
| min_addr.c<br />
| Minimum VM address protection from userspace for DAC and LSM.<br />
<br />
|}<br />
<br />
== The SELinux Module ==<br />
This section does not go into detail of all the SELinux module functionality as the [http://www.nsa.gov/research/_files/publications/implementing_selinux.pdf Implementing SELinux as a Linux Security Module] does this (although a bit dated), however it attempts to highlight the way some areas work by using the [[#Fork and Domain Transition Walk-thorough | fork and transition process example]] described in the [[NB_Domain_and_Object_Transitions#Domain Transition | Domain Transition]] section.<br />
<br />
The major kernel SELinux source files (relative to <tt>./linux-3.14/security/selinux</tt>) that form the SELinux security module are shown in Table 4. The diagrams shown in[http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] and [http://selinuxproject.org/~rhaines/NB4-diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] can be used to see how some of these kernel source modules fit together. <br />
<br />
<center>'''Table 4: The core SELinux source modules - '''''The <tt>.h</tt> files and those in the <tt>include</tt> directory have a number of useful comments.''</center><br />
<br />
{| border="1"<br />
! Name<br />
! Function<br />
<br />
|-<br />
| avc.c<br />
| Access Vector Cache functions and structures. The function calls are for the kernel services, however they have been ported to form the <tt>libselinux</tt> userspace library.<br />
<br />
|-<br />
| exports.c<br />
| Exported SELinux services for SECMARK (as there is SELinux specific code in the netfilter source tree).<br />
<br />
|-<br />
| hooks.c<br />
| Contains all the SELinux functions that are called by the kernel resources via the <tt>security_ops</tt> function table (they form the kernel resource object managers). There are also support functions for managing process exec's, managing SID allocation and removal, interfacing into the AVC and Security Server.<br />
<br />
|-<br />
| netif.c<br />
| These manage the mapping between labels and SIDs for the <tt>net</tt><nowiki>* language statements when they are declared in the active policy.</nowiki><br />
<br />
|-<br />
| netnode.c<br />
<br />
|-<br />
| netport.c<br />
<br />
|-<br />
| netlabel.c<br />
| The interface between NetLabel services and SELinux.<br />
<br />
|-<br />
| netlink.c<br />
| Manages the notification of policy updates to resources including userspace applications via <tt>libselinux</tt>.<br />
<br />
|-<br />
| nlmsgtab.c<br />
<br />
|-<br />
| selinuxfs.c<br />
| The <tt>selinuxfs</tt> pseudo filesystem (<tt>/sys/fs/selinux</tt>) that imports/exports security policy information to/from userspace services. The services exported are shown in the [[#SELinux Filesystem | SELinux Filesystem]] section.<br />
<br />
|-<br />
| xfrm.c<br />
| Contains the IPSec XFRM (transform) hooks for SELinux.<br />
<br />
|-<br />
| include/classmap.h<br />
| <tt>classmap.h</tt> contains all the kernel security classes and permissions. <tt>initial_sid_to_string.h</tt> contains the initial SID contexts. These are used to build the <tt>flask.h</tt> and <tt>av_permissions.h</tt> kernel configuration files when the kernel is being built (using the <tt>genheaders</tt> script defined in the <tt>selinux/Makefile</tt>). <br />
<br />
These files are built this way now to support the new dynamic security class mapping structure to remove the need for fixed class to SID mapping.<br />
<br />
|-<br />
| include/initial_sid_to_string.h<br />
<br />
|-<br />
| ss/avtab.c<br />
| AVC table functions for inserting / deleting entries.<br />
<br />
|-<br />
| ss/conditional.c<br />
| Support boolean statement functions and implements a conditional AV table to hold entries.<br />
<br />
|-<br />
| ss/ebitmap.c<br />
| Bitmaps to represent sets of values, such as types, roles, categories, and classes.<br />
<br />
|-<br />
| ss/hashtab.c<br />
| Hash table.<br />
<br />
|-<br />
| ss/mls.c<br />
| Functions to support MLS.<br />
<br />
|-<br />
| ss/policydb.c<br />
| Defines the structure of the policy database. See the "[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer]" article for details on the structure.<br />
<br />
|-<br />
| ss/services.c<br />
| This contains the supporting services for kernel hooks defined in <tt>hooks.c</tt>, the AVC and the Security Server. <br />
<br />
For example the <tt>security_transition_sid</tt> that computes the SID for a new subject / object shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram.<br />
<br />
|-<br />
| ss/sidtab.c<br />
| The SID table contains the security context indexed by its SID value.<br />
<br />
|-<br />
| ss/status.c<br />
| Interface for <tt>selinuxfs/status</tt>. Used by the <tt>libselinux</tt> <tt>selinux_status_*(3)</tt> functions.<br />
<br />
|-<br />
| ss/symtab.c<br />
| Maintains associations between symbol strings and their values.<br />
<br />
|}<br />
<br />
<br />
<br />
=== Fork System Call Walk-thorough ===<br />
This section walks through the the <tt>'''fork'''(2)</tt> system call shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram starting at the kernel hooks that link to the SELinux services. The way the SELinux hooks are initialised into the LSM <tt>security_ops</tt> function table are also described.<br />
<br />
Using the [http://selinuxproject.org/~rhaines/NB4-diagrams/10-fork.png hooks for a fork] diagram, the major steps to check whether the <tt>unconfined_t</tt> process has permission to use the fork permission are:<br />
# The <tt>kernel/fork.c</tt> has a hook that links it to the LSM function <tt>security_task_create()</tt> that is called to check access permissions. <br />
# Because the SELinux module has been initialised as the security module, the <tt>security_ops</tt> table has been set to point to the SELinux <tt>selinux_task_create()</tt> function in <tt>hooks.c</tt>.<br />
# The <tt>selinux_task_create()</tt> function check whether the task has permission via the <tt>current_has_perm(current, PROCESS__FORK)</tt> function. <br />
# This will result in a call to the AVC via the <tt>avc_has_perm()</tt> function in <tt>avc.c</tt> that checks whether the permission has been granted or not. First (via <tt>avc_has_perm_noaudit()</tt>) the cache is checked for an entry. Assuming that there is no entry in the AVC, then the <tt>security_compute_av()</tt> function in <tt>services.c</tt> is called.<br />
# The <tt>security_compute_av()</tt> function will search the SID table for source and target entries, and if found will then call the <tt>context_struct_compute_av()</tt> function. The <tt>context_struct_compute_av()</tt> function carries out many checks to validate whether access is allowed. The steps are (assuming the access is valid):<br />
## Initialise the AV structure so that it is clear.<br />
## Check the object class and permissions are correct. It also checks the status of the <tt>allow_unknown</tt> flag (see the [[#SELinux Filesystem | SELinux Filesystem]], <tt>[[GlobalConfigurationFiles#/etc/selinux/semanage.conf | /etc/selinux/semanage.conf]]</tt> file and<tt> </tt>[[NB_RefPolicy#Build Options | Reference Policy Build Options - build.conf UNK_PERMS]] sections).<br />
## Checks if there are any type enforcement rules (<tt>ALLOW</tt>, <tt>AUDIT_ALLOW</tt>, <tt>AUDIT_DENY</tt>).<br />
## Check whether any conditional statements are involved via the <tt>cond_compute_av()</tt> function in <tt>conditional.c</tt>.<br />
## Remove permissions that are defined in any constraint via the <tt>constraint_expr_eval()</tt> function call (in <tt>services.c</tt>). This function will also check any MLS constraints.<br />
## <tt>context_struct_compute_av()</tt> checks if a process transition is being requested (it is not). If it were, then the <tt>TRANSITION</tt> and <tt>DYNTRANSITION</tt> permissions are checked and whether the role is changing.<br />
## Finally check whether there are any constraints applied via the <tt>typebounds</tt> rule. <br />
# Once the result has been computed it is returned to the <tt>kernel/fork.c</tt> system call via the initial <tt>selinux_task_create()</tt> function. In this case the <tt>fork</tt> call is allowed. <br />
# The End.<br />
<br />
<br />
=== Process Transition Walk-thorough ===<br />
This section walks through the <tt>'''execve'''(2)</tt> and checking whether a process transition to the <tt>ext_gateway_t</tt> domain is allowed, and if so obtain a new SID for the context (<tt>unconfined_u:message_filter_r:ext_gateway_t</tt>) as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram.<br />
<br />
The process starts with the Linux operating system issuing a <tt>do_execve<ref name="ftn14">This function call will pass over the file name to be run and its environment + arguments.</ref> call from the CPU specific architecture code to execute a new program (for example, from <tt>arch/ia64/kernel/process.c</tt>). The <tt>do_execve()</tt> function is located in the <tt>fs/exec.c</tt> source code module and does the loading and final exec as described below.<br />
<br />
<tt>do_execve()</tt> has a number of calls to <tt>security_bprm_*</tt> functions that are a part of the LSM (see <tt>include/linux</tt>/<tt>security.h</tt>), and are hooked by SELinux during the initialisation process (in <tt>security/selinux</tt>/<tt>hooks.c</tt>). Table 5 briefly describes these <tt>security_bprm</tt> functions that are hooks for validating program loading and execution (although see <tt>security.h</tt> for greater detail).<br />
<br />
<center>'''Table 5: The LSM / SELinux Program Loading Hooks'''</center><br />
{| border="1"<br />
| '''LSM / SElinux Function Name'''<br />
| '''Description'''<br />
<br />
|-<br />
| security_bprm_set_creds-><br />
<br />
<br />
selinux_bprm_set_creds<br />
| Set up security information in the <tt>bprm->security</tt> field based on the file to be exec'ed contained in <tt>bprm->file</tt>. SELinux uses this hook to check for domain transitions and the whether the appropriate permissions have been granted, and obtaining a new SID if required.<br />
<br />
|-<br />
| security_bprm_committing_creds-><br />
<br />
<br />
selinux_bprm_committing_creds<br />
| Prepare to install the new security attributes of the process being transformed by an execve operation. SELinux uses this hook to close any unauthorised files, clear parent signal and reset resource limits if required.<br />
<br />
|-<br />
| security_bprm_committed_creds-><br />
<br />
<br />
selinux_bprm_ committed_creds<br />
| Tidy up after the installation of the new security attributes of a process being transformed by an <tt>execve</tt> operation. SELinux uses this hook to check whether signal states can be inherited if new SID allocated.<br />
<br />
|-<br />
| security_bprm_secureexec-><br />
<br />
<br />
selinux_bprm_secureexec<br />
| Called when loading libraries to check <tt>AT_SECURE</tt> flag for glibc secure mode support. SELinux uses this hook to check the <tt>process</tt> class <tt>noatsecure</tt> permission if appropriate.<br />
<br />
|-<br />
| security_bprm_check-><br />
<br />
<br />
selinux_bprm_check_security<br />
| This hook is not used by SELinux.<br />
<br />
|}<br />
<br />
<br />
Therefore starting at the <tt>do_execve()</tt> function and using the [http://selinuxproject.org/~rhaines/NB4-diagrams/11-transition.png Process Transition] diagram, the following major steps will be carried out to check whether the <tt>unconfined_t</tt> process has permission to transition the <tt>secure_server</tt> executable to the <tt>ext_gateway_t</tt> domain:<br />
# The executable file is opened, a call issued to the <tt>sched_exec()</tt> function and the <tt>bprm</tt> structure is initialised with the file parameters (name, environment and arguments). <br />
# Via the <tt>prepare_binprm()</tt> function call the UID and GIDs are checked and a call issued to <tt>security_bprm_set_creds()</tt> that will carry out the following:<br />
# Call <tt>cap_bprm_set_creds</tt> function in <tt>commoncap.c</tt>, that will set up credentials based on any configured capabilities. If <tt>'''setexeccon'''(3)</tt> has been called prior to the exec, then that context will be used otherwise call <tt>security_transition_sid()</tt> function in <tt>services.c</tt>. This function will then call <tt>security_compute_sid()</tt> to check whether a new SID needs to be computed. This function will (assuming there are no errors):<br />
## Search the SID table for the source and target SIDs.<br />
## Sets the SELinux user identity.<br />
## Set the source role and type.<br />
## Checks that a <tt>type_transition</tt> rule exists in the AV table and / or the conditional AV table (see the [http://selinuxproject.org/~rhaines/NB4-diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram).<br />
## If a <tt>type_transition</tt>, then also check for a <tt>role_transition</tt> (there is a role change in the <tt>ext_gateway.conf</tt> policy module), set the role.<br />
## Check if any MLS attributes by calling <tt>mls_compute_sid()</tt> in <tt>mls.c</tt>. It also checks whether MLS is enabled or not, if so sets up MLS contexts.<br />
## Check whether the contexts are valid by calling <tt>compute_sid_handle_invalid_context()</tt> that will also log an audit message if the context is invalid.<br />
## Finally obtains a SID for the new context by calling <tt>sidtab_context_to_sid()</tt> in <tt>sidtab.c</tt> that will search the SID table (see the [http://selinuxproject.org/~rhaines/NB4-diagrams/12-lsm-selinux-arch.png The Main LSM / SELinux Modules] diagram) and insert a new entry if okay or log a kernel event if invalid.<br />
# The <tt>selinux_bprm_set_creds()</tt> function will continue by checking via the <tt>avc_has_perm()</tt> functions (in <tt>avc.c</tt>) whether the <tt>file</tt> class <tt>file_execute_no_trans</tt> is set (in this case it is not), therefore the <tt>process</tt> class <tt>transition</tt> and <tt>file</tt> class <tt>file_entrypoint</tt> permissions are checked (in this case they are allowed), therefore the new SID is set, and after checking various other permissions, control is passed back to the <tt>do_execve</tt> function.<br />
# The <tt>exec_binprm</tt> function will ultimately commit the credentials calling the SELinux <tt>selinux_bprm_committing_creds</tt> and <tt>selinux_bprm_committed_creds</tt>.<br />
# Various strings are copied (args etc.) and a check is made to see if the exec succeeded or not (in this case it did), therefore the <tt>security_bprm_free()</tt> function is ultimately called to free the <tt>bprm</tt> security structure. <br />
# The End.<br />
<br />
<br />
<br />
=== SELinux Filesystem ===<br />
Table 6 shows the information contained in the SELinux filesystem (<tt>selinuxfs</tt>) /sys/fs/selinux (or /selinux on older systems) where the SELinux kernel exports information regarding its configuration and active policy. <tt>selinuxfs</tt> is a read/write interface used by SELinux library functions for userspace SELinux-aware applications and object managers. Note: while it is possible for userspace applications to read/write to this interface, it is not recommended - use the libselinux library.<br />
<br />
<center>'''Table 6: selinux filesystem Information'''</center><br />
{| border="1"<br />
! <center>selinuxfs Directory and File Names</center><br />
! <center>Permissions</center><br />
! <center>Comments</center><br />
<br />
|-<br />
| '''/sys/fs/selinux'''<br />
| <center>'''Directory'''</center><br />
| This is the root directory where the SELinux kernel exports relevant information regarding its configuration and active policy for use by the libselinux library.<br />
<br />
|-<br />
| <div align="right">access</div><br />
| <center>-rw-rw-rw-</center><br />
| Compute access decision interface that is used by the <tt>'''security_compute_av'''(3)</tt>,<tt> '''security_compute_av_flags'''(3)</tt>, <tt>'''avc_has_perm'''(3)</tt>and <tt>'''avc_has_perm_noaudit'''(3)</tt> functions. <br />
<br />
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_compute_av_user</tt> function to compute the new SID that is then converted to a context string.<br />
<br />
Requires <tt>security {compute_av}</tt> permission.<br />
<br />
|-<br />
| <div align="right">checkreqprot</div><br />
| <center>-rw-r--r--</center><br />
| <tt>0</tt> = Check requested protection applied by kernel.<br />
<br />
<tt>1</tt> = Check protection requested by application. This is the default.<br />
<br />
These apply to the <tt>mmap</tt> and <tt>mprotect</tt> kernel calls. Default value can be changed at boot time via the <tt>checkreqprot=</tt> parameter.<br />
<br />
Requires <tt>security {setcheckreqprot}</tt> permission.<br />
<br />
|-<br />
| <div align="right">commit_pending_bools</div><br />
| <center>--w-------</center><br />
| Commit new boolean values to the kernel policy.<br />
<br />
Requires <tt>security {setbool}</tt> permission.<br />
<br />
|-<br />
| <div align="right">context</div><br />
| <center>-rw-rw-rw-</center><br />
| Validate context interface used by the <tt>'''security_check_context'''(3)</tt> function.<br />
<br />
Requires <tt>security {check_context}</tt> permission.<br />
<br />
|-<br />
| <div align="right">create</div><br />
| <center>-rw-rw-rw-</center><br />
| Compute create labeling decision interface that is used by the <tt>'''security_compute_create'''(3)</tt> and <tt>'''avc_compute_create'''(3)</tt> functions. <br />
<br />
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_transition_sid_user</tt> function to compute the new SID that is then converted to a context string.<br />
<br />
Requires <tt>security {compute_create}</tt> permission.<br />
<br />
|-<br />
| <div align="right">deny_unknown</div><br />
| <center>-r--r--r--</center><br />
| These two files export deny_unknown (read by <tt>'''security_deny_unknown'''(3)</tt> function) and reject_unknown status to user space. <br />
<br />
These are taken from the handle-unknown parameter set<ref name="ftn15"><sup>This is also set in the UNK_PERMS entry of the Reference Policy [#_Reference_Policy_Build_Options (bui build.conf] file. The entry in <tt>semanage.conf</tt> will over-ride the <tt>build.conf</tt> entry.</sup></ref> in the <tt>/etc/selinux/semanage.conf</tt> file when policy is being built and are set as follows:<br />
<br />
deny:reject<br />
<br />
0:0 = Allow unknown object class / permissions. This will set the returned AV with all 1's.<br />
<br />
1:0 = Deny unknown object class / permissions (the default). This will set the returned AV with all 0's.<br />
<br />
1:1 = Reject loading the policy if it does not contain all the object classes / permissions.<br />
<br />
|-<br />
| <div align="right">reject_unknown</div><br />
| <center>-r--r--r--</center><br />
<br />
|-<br />
| <div align="right">disable</div><br />
| <center>--w-------</center><br />
| Disable SELinux until next reboot.<br />
<br />
|-<br />
| <div align="right">enforce</div><br />
| <center>-rw-r--r--</center><br />
| Get or set enforcing status.<br />
<br />
Requires <tt>security {setenforce}</tt> permission.<br />
<br />
|-<br />
| <div align="right">load</div><br />
| <center>-rw-------</center><br />
| Load policy interface.<br />
<br />
Requires <tt>security {load_policy}</tt> permission.<br />
<br />
|-<br />
| <div align="right">member</div><br />
| <center>-rw-rw-rw-</center><br />
| Compute polyinstantiation membership decision interface that is used by the <tt>'''security_compute_member'''(3)</tt> and <tt>'''avc_compute_member'''(3)</tt> functions. <br />
<br />
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_member_sid</tt> function to compute the new SID that is then converted to a context string.<br />
<br />
Requires <tt>security {compute_member}</tt> permission.<br />
<br />
|-<br />
| <div align="right">mls</div><br />
| <center>-r--r--r--</center><br />
| Returns 1 if MLS policy is enabled or 0 if not.<br />
<br />
|-<br />
| <div align="right">null</div><br />
| <center>crw-rw-rw-</center><br />
| The SELinux equivalent of <tt>/dev/null</tt> for file descriptors that have been redirected by SELinux.<br />
<br />
|-<br />
| <div align="right">policy</div><br />
| <center>-r--r--r--</center><br />
| Interface to upload the current running policy in kernel binary format. This is useful to check the running policy using <tt>'''apol'''(1)</tt> , <tt>dispol</tt>/<tt>sedispol</tt> etc. (e.g. <tt>cat /sys/fs/selinux/policy > current-policy</tt> then load it into the required tool).<br />
<br />
|-<br />
| <div align="right">policyvers</div><br />
| <center>-r--r--r--</center><br />
| Returns supported policy version for kernel. Read by <tt>'''security_policyvers'''(3)</tt> function.<br />
<br />
|-<br />
| <div align="right">relabel</div><br />
| <center>-rw-rw-rw-</center><br />
| Compute relabeling decision interface that is used by the <tt>'''security_compute_relabel'''(3)</tt> function. <br />
<br />
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_change_sid</tt> function to compute the new SID that is then converted to a context string.<br />
<br />
Requires <tt>security {compute_relabel}</tt> permission.<br />
<br />
|-<br />
| <div align="right">status</div><br />
| <center>-r--r--r--</center><br />
| This can be used to obtain enforcing mode and policy load changes with much less over-head than using the <tt>libselinux</tt> netlink / call backs. This was added for Object Managers that have high volumes of AVC requests so they can quickly check whether to invalidate their cache or not.<br />
<br />
The status structure indicates the following:<br />
<br />
<tt>version</tt> - Version number of the status structure. This will increase as other entries are added.<br />
<br />
<tt>sequence</tt> - This is incremented for each event with an even number meaning that the events are stable. An odd number indicates that one of the events is changing and therefore the userspace application should wait before reading the status of any event.<br />
<br />
<tt>enforcing</tt> - <tt>0</tt> = Permissive mode, <tt>1</tt> = enforcing mode.<br />
<br />
<tt>policyload</tt> - This contains the policy load sequence number and should be read and stored, then compared to detect a policy reload.<br />
<br />
<tt>deny_unknown</tt> - <tt>0</tt> = Allow and <tt>1</tt> = Deny unknown object classes / permissions. This is the same as the <tt>deny_unknown</tt> entry above.<br />
<br />
|-<br />
| <div align="right">user</div><br />
| <center>-rw-rw-rw-</center><br />
| Compute reachable user contexts interface that is used by the <tt>'''security_compute_user'''(3)</tt> function. <br />
<br />
The kernel security server (see <tt>services.c</tt>) converts the contexts to SIDs and then calls the <tt>security_get_user_sids</tt> function to compute the user SIDs that are then converted to context strings.<br />
<br />
Requires <tt>security {compute_user}</tt> permission.<br />
<br />
|-<br />
| '''/sys/fs/selinux/avc'''<br />
| <center>'''Directory'''</center><br />
| This directory contains information regarding the kernel AVC that can be displayed by the avcstat command.<br />
<br />
|-<br />
| <div align="right">cache_stats</div><br />
| <center>-r--r--r--</center><br />
| Shows the kernel AVC lookups, hits, misses etc.<br />
<br />
|-<br />
| <div align="right">cache_threshold</div><br />
| <center>-rw-r--r--</center><br />
| The default value is 512, however caching can be turned off (but performance suffers) by:<br />
<br />
echo 0 > /selinux/avc/cache_threshold<br />
<br />
Requires <tt>security {setsecparam}</tt> permission.<br />
<br />
|-<br />
| <div align="right">hash_stats</div><br />
| <center>-r--r--r--</center><br />
| Shows the number of kernel AVC entries, longest chain etc.<br />
<br />
|-<br />
| '''/sys/fs/selinux/booleans'''<br />
| <center>'''Directory'''</center><br />
| This directory contains one file for each boolean defined in the active policy.<br />
<br />
|-<br />
| <div align="right">secmark_audit</div><br />
<br />
<div align="right">......</div><br />
<br />
<div align="right">......</div><br />
| <center>-rw-r--r--</center><br />
| Each file contains the current and pending status of the boolean (0 = false or 1 = true). The '''getsebool'''(8), '''setsebool'''(8) and '''sestatus'''(8)''' -b''' commands use this interface via the <tt>libselinux</tt> library functions.<br />
<br />
|-<br />
| '''/sys/fs/selinux/initial_contexts'''<br />
| <center>'''Directory'''</center><br />
| This directory contains one file for each initial SID defined in the active policy. The file name is the initial SID name with the contents containing its security context.<br />
<br />
|-<br />
| <div align="right">any_socket</div><br />
<br />
<div align="right">devnull</div><br />
<br />
<div align="right">.....</div><br />
| <center>-r--r--r--</center><br />
| Each file contains the initial context of the initial SID as defined in the active policy (e.g. any_socket was assigned system_u:object_r:unconfined_t).<br />
<br />
|-<br />
| '''/sys/fs/selinux/policy_capabilities'''<br />
| <center>'''Directory'''</center><br />
| This directory contains the policy capabilities that have been configured by default in the kernel via the <tt>policycap</tt> statement in the active policy. These are generally new features that can be enabled by using the policycap statement in policy. Their default values are false.<br />
<br />
|-<br />
| <div align="right">always_check_network</div><br />
| <center>-r--r--r--</center><br />
| If true SECMARK and peer labeling are always enabled even if there are no SECMARK, NetLabel or Labeled IPsec rules configured. This forces checking of the <tt>packet</tt> class to protect the system should any rules fail to load or they get maliciously flushed. Requires kernel 3.14 minimum.<br />
<br />
|-<br />
| <div align="right">network_peer_controls</div><br />
| <center>-r--r--r--</center><br />
| If true the following network_peer_controls are enabled:<br />
<br />
node: sendto recvfrom<br />
<br />
netif: ingress egress<br />
<br />
peer: recv<br />
<br />
|-<br />
| <div align="right">open_perms</div><br />
| <center>-r--r--r--</center><br />
| If true the open permissions are enabled by default on the following object classes: dir, file, fifo_file, chr_file, blk_file.<br />
<br />
|-<br />
| <div align="right">redhat1</div><br />
| <center>-r--r--r--</center><br />
| Available in kernel 3.4 to allow finer control of <tt>ptrace</tt> (this will be named correctly one day). Requires policy support and the <tt>security</tt> class permission <tt>ptrace_child</tt>.<br />
<br />
|-<br />
| '''/sys/fs/selinux/class'''<br />
| <center>'''Directory'''</center><br />
| This directory contains a list of classes and their permissions as defined by the policy (for the Reference Policy the order in the <tt>security_classes</tt> and <tt>access_vectors</tt> files).<br />
<br />
|-<br />
| '''/sys/fs/selinux/class/appletalk_socket'''<br />
| <center>'''Directory'''</center><br />
| Each class has its own directory where each one is named using the appropriate class statement from the policy (i.e. <tt>class appletalk_socket</tt>). Each directory contains the following: <br />
<br />
|-<br />
| <div align="right">index</div><br />
| <center>-r--r--r--</center><br />
| This file contains the allocated class number (e.g. appletalk_socket is the 56<sup>th</sup> entry in the policy <tt>security_classes</tt> file).<br />
<br />
|-<br />
| '''/sys/fs/selinux/class/appletalk_socket/perms'''<br />
| <center>'''Directory'''</center><br />
| This directory contains one file for each permission defined in the policy.<br />
<br />
|-<br />
| <div align="right">accept</div><br />
<br />
<div align="right">append</div><br />
<br />
<div align="right">bind</div><br />
<br />
<div align="right">....</div><br />
| <center>-r--r--r--</center><br />
| Each file is named by the permission assigned in the policy and contains a number that represents its position in the list (e.g. <tt>accept</tt> is the 14<sup>th</sup> permission listed in the policy <tt>access_vector</tt> file for the <tt>appletalk_socket</tt> and therefore contains '14'.<br />
<br />
|}<br />
<br />
<br />
Notes:<br />
# Kernel SIDs are not passed to userspace only the context strings.<br />
# The <tt>/proc</tt> filesystem exports the process security context string to userspace via <tt><nowiki>/proc/<self|pid>/attr</nowiki></tt> and <tt><nowiki>/proc/<self|pid>/task/<tid>/attr/<attr></nowiki></tt> interfaces.<br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_PAM | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_Userspace_Libraries | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_PolicyTypeNB PolicyType2015-09-25T13:51:51Z<p>RichardHaines: /* Policy Versions */</p>
<hr />
<div>= Types of SELinux Policy =<br />
This section describes the different type of policy descriptions and versions that can be found within SELinux.<br />
<br />
The type of SELinux policy can described in a number of ways:<br />
<br />
# Source code - These can be described as: [[#Example_Policy | Example]], [[#Reference_Policy | Reference Policy]] or [[#Custom_Policy | Custom]]. They are generally written using either [[KernelPolicyLanguage | kernel policy language]], [[NB_RefPolicy#Reference Policy Support Macros | m4 macro support with kernel policy language]], or [[CIL_Language | CIL]].<br />
# They can also be classified as: [[#Monolithic_Policy | Monolithic]], [[#Reference_Policy | Base Module or Loadable Module]].<br />
# Policies can also be described by the [[#Policy_Functionality_Type | type of policy functionality]] they provide such as: targeted, mls, mcs, standard, strict or minimum.<br />
# Classified using language statements - These can be described as [[#Reference_Policy | Modular, Optional]] or [[#Conditional_Policy | Conditional]].<br />
# Binary policy (or kernel policy) - These can be described as [[#Policy_Versions | Monolithic, Kernel Policy or Binary file]].<br />
# Classification can also be on the '[[#Policy_Versions | policy version]]' used (examples are version 27, 28 and 29).<br />
# Policy can also be generated depending on the target platform of either 'selinux' (the default) or 'xen' (see the SELinux policy generation tools <tt>'''checkpolicy'''(8)</tt> and <tt>'''secilc'''(8)</tt> <tt>target_platform</tt> option).<br />
<br />
As can be seen the description of a policy can vary depending on the context.<br />
<br />
== Example Policy ==<br />
The Example policy is the name used to describe the original SELinux policy source used to build a [[#Policy_Versions | monolithic]]<ref name="ftn12"><sup>The term 'monolithic' generally means a single policy source is used to create the binary policy file that is then loaded as the 'policy' using the '''checkpolicy'''(8) command. However the term is sometimes used to refer to the binary policy file (as it is one file that describes the policy).</sup></ref> policy produced by the NSA and is now superseded by the Reference Policy.<br />
<br />
== Reference Policy ==<br />
Note that this section only gives an introduction to the Reference Policy, the installation, configuration and building of a policy using this is contained in [[NB_RefPolicy | The Reference Policy]] section.<br />
<br />
The Reference Policy is now the standard policy source used to build Linux based SELinux policies, and its main aim is to provide a single source tree with supporting documentation that can be used to build policies for different purposes such as confining important daemons, supporting MLS / MCS and locking down systems so that all processes are under SELinux control. <br />
<br />
The Reference Policy is now used by all major distributions of Linux, however each distribution makes its own specific changes to support their 'version of the Reference Policy'. For example, the F-20 distribution is based on a specific build of the standard Reference Policy that is then modified and distributed by Red Hat as a number of RPMs.<br />
<br />
== Policy Functionality Based on Name or Type ==<br />
Generally a policy is installed with a given name such as <tt>targeted</tt>, <tt>mls</tt>, <tt>refpolicy</tt> or <tt>minimum</tt> that attempts to describes its functionality. This name then becomes the entry in: <br />
<br />
# The directory pointing to the policy location (e.g. if the name is <tt>targeted</tt>, then the policy will be installed in <tt>/etc/selinux/targeted</tt>).<br />
# The <tt>SELINUXTYPE</tt> entry in the <tt>/etc/selinux/config</tt> file when it is the active policy (e.g. if the name is <tt>targeted</tt>, then a <tt>SELINUXTYPE=targeted</tt> entry would be in the <tt>/etc/selinux/config</tt> file).<br />
<br />
This is how the reference policies distributed with F-20 are named, where:<br />
: minimum - supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space. Red Hat pre-configure MCS support within this policy.<br />
: targeted - supports a greater number of confined daemons and can also confine other areas and users. Red Hat pre-configure MCS support within this policy.<br />
: mls - supports server based MLS systems.<br />
<br />
The Reference Policy also has a <tt>TYPE</tt> description that describes the type of policy being built by the build process, these are:<br />
: standard - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older 'targeted' and 'strict' versions).<br />
: mcs - As standard but supports MCS labels.<br />
: mls - supports server based MLS systems.<br />
<br />
The <tt>NAME</tt> and <tt>TYPE</tt> entries are defined in the reference policy <tt>build.conf</tt> file that is described in the [[NB_RefPolicy#Source Configuration Files | Source Configuration Files]] section. <br />
<br />
== Custom Policy ==<br />
This generally refers to a policy source that is either:<br />
<br />
# A customised version of the Example policy.<br />
# A customised version of the Reference Policy (i.e. not the standard distribution version e.g. Red Hat policies).<br />
# A policy that has been built using policy language statements to build a specific policy such as the basic policy built in the Notebook source tarball.<br />
<br />
== Monolithic Policy ==<br />
A Monolithic policy is an SELinux policy that is compiled from one source file called (by convention) <tt>policy.conf</tt> (i.e. it does not use the Loadable Module Policy statements and infrastructure which therefore makes it suitable for embedded systems as there is no policy store overhead). <br />
<br />
An example monolithic policy is the NSAs original [[#Example_Policy | Example Policy]].<br />
<br />
Monolithic policies are compiled using the '''checkpolicy''' (8) SELinux command. <br />
<br />
The Reference Policy supports the building of monolithic policies.<br />
<br />
In some cases the kernel policy binary file (see the [[#Binary Policy | Binary Policy]] section) is also called a monolithic policy.<br />
<br />
== Loadable Module Policy ==<br />
The loadable module infrastructure allows policy to be managed on a modular basis, in that there is a base policy module that contains all the core components of the policy (i.e. the policy that should always be present), and zero or more modules that can be loaded and unloaded as required (for example if there is a module to enforce policy for ftp, but ftp is not used, then that module could be unloaded).<br />
<br />
There are number of components that form the infrastructure:<br />
<br />
# Policy source code that is constructed for a modular policy with a base module and optional loadable modules.<br />
# Utilities to compile and link modules and place them into a 'policy store'.<br />
# Utilities to manage the modules and associated configuration files within the 'policy store'.<br />
<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows these components along the top of the diagram. The files contained in the policy store are detailed in the [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]] section.<br />
<br />
The policy language was extended to handle loadable modules as detailed in the [[PolicyStatements | Modular Policy Support Statements]] section. For a detailed overview on how the modular policy is built into the final binary policy for loading into the kernel, see "[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer].<br />
<br />
== Optional Policy ==<br />
The loadable module policy infrastructure supports an [[PolicyStatements#optional | optional policy statement]] that allows policy rules to be defined but only enabled in the binary policy once the conditions have been satisfied.<br />
<br />
== Conditional Policy ==<br />
Conditional policies can be implemented in monolithic or loadable module policies and allow parts of the policy to be enabled or not depending on the state of a boolean flag at run time. This is often used to enable or disable features within the policy (i.e. change the policy enforcement rules).<br />
<br />
The boolean flag status is held in kernel and can be changed using the '''setsebool'''(8) command either persistently across system re-boots or temporarily (i.e. only valid until a re-boot). The following example shows a persistent conditional policy change:<br />
<pre><br />
setsebool -P ext_gateway_audit false<br />
</pre><br />
<br />
The conditional policy language statements are the <tt>bool</tt> Statement that defines the boolean flag identifier and its initial status, and the <tt>if</tt> Statement that allows certain rules to be executed depending on the state of the boolean value or values.<br />
<br />
== Binary Policy ==<br />
This is also know as the kernel policy and is the policy file that is loaded into the kernel and is located at <nowiki>/etc/selinux/<SELINUXTYPE>/policy/policy.<version></nowiki>. Where <tt><nowiki><SELINUXTYPE</nowiki>></tt> is the policy name specified in the SELinux configuration file /etc/selinux/config and <nowiki><version></nowiki> is the SELinux [[#Policy_Versions | policy version]].<br />
<br />
The binary policy can be built from source files supplied by the Reference Policy or custom built source files.<br />
<br />
An example /etc/selinux/config file is shown below where the <tt>SELINUXTYPE=targeted</tt> entry identifies the policy name that will be used to locate and load the active policy:<br />
<pre><br />
SELINUX=permissive<br />
SELINUXTYPE=targeted<br />
</pre><br />
<br />
From the above example, the actual binary policy file would be located at /etc/selinux/targeted/policy and be called policy.29 (as version 29 is supported by F-20):<br />
<pre><br />
/etc/selinux/targeted/policy/policy.29<br />
</pre><br />
<br />
== Policy Versions ==<br />
SELinux has a policy database (defined in the libsepol library) that describes the format of data held within a [[#Binary_Policy | binary policy]], however, if any new features are added to SELinux (generally language extensions) this can result in a change to the policy database. Whenever the policy database is updated, the policy version is incremented. <br />
<br />
The '''sestatus'''(8) command will show the maximum policy version supported by the kernel in its output as follows:<br />
<pre><br />
SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
Loaded policy name targeted<br />
Current mode: enforcing<br />
Mode from config file: permissive<br />
Policy MLS status: enabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 29<br />
</pre><br />
<br />
The following table describes the different versions, although note that there is also another version that applies to the modular policy, however the main policy database version is the one that is generally quoted (some SELinux utilities give both version numbers).<br />
<br />
{| border="1"<br />
! policy db Version<br />
! modular db Version<br />
! Description<br />
<br />
|-<br />
| <center>15</center><br />
| <center>4</center><br />
| The base version when SELinux was merged into the kernel.<br />
<br />
|-<br />
| <center>16</center><br />
| <center>-</center><br />
| Added [[#Conditional_Policy | Conditional Policy]] support (the bool feature).<br />
<br />
|-<br />
| <center>17</center><br />
| <center>-</center><br />
| Added support for IPv6.<br />
<br />
|-<br />
| <center>18</center><br />
| <center>-</center><br />
| Added Netlink support.<br />
<br />
|-<br />
| <center>19</center><br />
| <center>5</center><br />
| Added MLS support, plus the validatetrans Statement.<br />
<br />
|-<br />
| <center>20</center><br />
| <center>-</center><br />
| Reduced the size of the access vector table.<br />
<br />
|-<br />
| <center>21</center><br />
| <center>6</center><br />
| Added support for the MLS range_transition Statement.<br />
<br />
|-<br />
| <center>22</center><br />
| <center>7</center><br />
| Added [[Policy_Configuration_Statements#policycap | policy capabilities]] that allows various kernel options to be enabled as described in the [[NB_LSM#SELinux Filesystem | SELinux Filesystem]] section.<br />
<br />
|-<br />
| <center>23</center><br />
| <center>8</center><br />
| Added support for the permissive statement. This allows a domain to run in permissive mode while the others are still confined (instead of the all or nothing set by the <tt>SELINUX</tt> entry in the <tt>/etc/selinux/config</tt> file).<br />
<br />
|-<br />
| <center>24</center><br />
| <center>9 / 10</center><br />
| Add support for the <tt>typebounds</tt> statement. This was added to support a hierarchical relationship between two domains in multi-threaded web servers as described in "[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]".<br />
|-<br />
| <center>25</center><br />
| <center>11</center><br />
| Add support for file name transition in the <tt>type_transition</tt> rule. Requires kernel 2.6.39 minimum.<br />
<br />
|-<br />
| <center>26</center><br />
| <center>12/13</center><br />
| Add support for a class parameter in the <tt>role_transition</tt> rule.<br />
<br />
Add support for the <tt>attribute_role</tt> and <tt>roleattribute</tt> statements.<br />
<br />
These require kernel 2.6.39 minimum.<br />
<br />
|-<br />
| <center>-</center><br />
| <center>14</center><br />
| Separate tunables.<br />
<br />
|-<br />
| <center>27</center><br />
| <center>15</center><br />
| Support setting object defaults for the user, role and range components when computing a new context. Requires kernel 3.5 minimum.<br />
<br />
|-<br />
| <center>28</center><br />
| <center>16</center><br />
| Support setting object defaults for the type component when computing a new context. Requires kernel 3.5 minimum.<br />
<br />
|-<br />
| <center>29</center><br />
| <center>17</center><br />
| Support attribute names within constraints. This allows attributes as well as the types to be retrieved from a kernel policy to assist <tt>'''audit2allow'''(8)</tt> etc. to determine what attribute needs to be updated. Note that the attribute does not determine the constraint outcome, it is still the list of types associated to the constraint. Requires kernel 3.14 minimum.<br />
<br />
|-<br />
| <center>30</center><br />
|<br />
| There are two version 30 enhancements that depend on the policy being built:<br />
# For the 'selinux' target platform adds new 'xperm' rules and extends the permission sets as explained in the [[XpermRules | Extended Permission Access Vector Rules]] section. This is to support 'ioctl whitelisting' as explained in the [[XpermRules#ioctl_Operation_Rules | ioctl Operation Rules]] section.<br />
# For the 'xen' target platform support the <tt>devicetreecon</tt> statement and also expand the existing I/O memory range to 64 bits as explained in the [[XENStatements | XEN Statements]] section.<br />
<br />
|}<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_MLS | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_PandE | '''Next''']]</center><br />
|}<br />
<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_PolicyTypeNB PolicyType2015-09-25T13:49:54Z<p>RichardHaines: /* Optional Policy */</p>
<hr />
<div>= Types of SELinux Policy =<br />
This section describes the different type of policy descriptions and versions that can be found within SELinux.<br />
<br />
The type of SELinux policy can described in a number of ways:<br />
<br />
# Source code - These can be described as: [[#Example_Policy | Example]], [[#Reference_Policy | Reference Policy]] or [[#Custom_Policy | Custom]]. They are generally written using either [[KernelPolicyLanguage | kernel policy language]], [[NB_RefPolicy#Reference Policy Support Macros | m4 macro support with kernel policy language]], or [[CIL_Language | CIL]].<br />
# They can also be classified as: [[#Monolithic_Policy | Monolithic]], [[#Reference_Policy | Base Module or Loadable Module]].<br />
# Policies can also be described by the [[#Policy_Functionality_Type | type of policy functionality]] they provide such as: targeted, mls, mcs, standard, strict or minimum.<br />
# Classified using language statements - These can be described as [[#Reference_Policy | Modular, Optional]] or [[#Conditional_Policy | Conditional]].<br />
# Binary policy (or kernel policy) - These can be described as [[#Policy_Versions | Monolithic, Kernel Policy or Binary file]].<br />
# Classification can also be on the '[[#Policy_Versions | policy version]]' used (examples are version 27, 28 and 29).<br />
# Policy can also be generated depending on the target platform of either 'selinux' (the default) or 'xen' (see the SELinux policy generation tools <tt>'''checkpolicy'''(8)</tt> and <tt>'''secilc'''(8)</tt> <tt>target_platform</tt> option).<br />
<br />
As can be seen the description of a policy can vary depending on the context.<br />
<br />
== Example Policy ==<br />
The Example policy is the name used to describe the original SELinux policy source used to build a [[#Policy_Versions | monolithic]]<ref name="ftn12"><sup>The term 'monolithic' generally means a single policy source is used to create the binary policy file that is then loaded as the 'policy' using the '''checkpolicy'''(8) command. However the term is sometimes used to refer to the binary policy file (as it is one file that describes the policy).</sup></ref> policy produced by the NSA and is now superseded by the Reference Policy.<br />
<br />
== Reference Policy ==<br />
Note that this section only gives an introduction to the Reference Policy, the installation, configuration and building of a policy using this is contained in [[NB_RefPolicy | The Reference Policy]] section.<br />
<br />
The Reference Policy is now the standard policy source used to build Linux based SELinux policies, and its main aim is to provide a single source tree with supporting documentation that can be used to build policies for different purposes such as confining important daemons, supporting MLS / MCS and locking down systems so that all processes are under SELinux control. <br />
<br />
The Reference Policy is now used by all major distributions of Linux, however each distribution makes its own specific changes to support their 'version of the Reference Policy'. For example, the F-20 distribution is based on a specific build of the standard Reference Policy that is then modified and distributed by Red Hat as a number of RPMs.<br />
<br />
== Policy Functionality Based on Name or Type ==<br />
Generally a policy is installed with a given name such as <tt>targeted</tt>, <tt>mls</tt>, <tt>refpolicy</tt> or <tt>minimum</tt> that attempts to describes its functionality. This name then becomes the entry in: <br />
<br />
# The directory pointing to the policy location (e.g. if the name is <tt>targeted</tt>, then the policy will be installed in <tt>/etc/selinux/targeted</tt>).<br />
# The <tt>SELINUXTYPE</tt> entry in the <tt>/etc/selinux/config</tt> file when it is the active policy (e.g. if the name is <tt>targeted</tt>, then a <tt>SELINUXTYPE=targeted</tt> entry would be in the <tt>/etc/selinux/config</tt> file).<br />
<br />
This is how the reference policies distributed with F-20 are named, where:<br />
: minimum - supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space. Red Hat pre-configure MCS support within this policy.<br />
: targeted - supports a greater number of confined daemons and can also confine other areas and users. Red Hat pre-configure MCS support within this policy.<br />
: mls - supports server based MLS systems.<br />
<br />
The Reference Policy also has a <tt>TYPE</tt> description that describes the type of policy being built by the build process, these are:<br />
: standard - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older 'targeted' and 'strict' versions).<br />
: mcs - As standard but supports MCS labels.<br />
: mls - supports server based MLS systems.<br />
<br />
The <tt>NAME</tt> and <tt>TYPE</tt> entries are defined in the reference policy <tt>build.conf</tt> file that is described in the [[NB_RefPolicy#Source Configuration Files | Source Configuration Files]] section. <br />
<br />
== Custom Policy ==<br />
This generally refers to a policy source that is either:<br />
<br />
# A customised version of the Example policy.<br />
# A customised version of the Reference Policy (i.e. not the standard distribution version e.g. Red Hat policies).<br />
# A policy that has been built using policy language statements to build a specific policy such as the basic policy built in the Notebook source tarball.<br />
<br />
== Monolithic Policy ==<br />
A Monolithic policy is an SELinux policy that is compiled from one source file called (by convention) <tt>policy.conf</tt> (i.e. it does not use the Loadable Module Policy statements and infrastructure which therefore makes it suitable for embedded systems as there is no policy store overhead). <br />
<br />
An example monolithic policy is the NSAs original [[#Example_Policy | Example Policy]].<br />
<br />
Monolithic policies are compiled using the '''checkpolicy''' (8) SELinux command. <br />
<br />
The Reference Policy supports the building of monolithic policies.<br />
<br />
In some cases the kernel policy binary file (see the [[#Binary Policy | Binary Policy]] section) is also called a monolithic policy.<br />
<br />
== Loadable Module Policy ==<br />
The loadable module infrastructure allows policy to be managed on a modular basis, in that there is a base policy module that contains all the core components of the policy (i.e. the policy that should always be present), and zero or more modules that can be loaded and unloaded as required (for example if there is a module to enforce policy for ftp, but ftp is not used, then that module could be unloaded).<br />
<br />
There are number of components that form the infrastructure:<br />
<br />
# Policy source code that is constructed for a modular policy with a base module and optional loadable modules.<br />
# Utilities to compile and link modules and place them into a 'policy store'.<br />
# Utilities to manage the modules and associated configuration files within the 'policy store'.<br />
<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows these components along the top of the diagram. The files contained in the policy store are detailed in the [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]] section.<br />
<br />
The policy language was extended to handle loadable modules as detailed in the [[PolicyStatements | Modular Policy Support Statements]] section. For a detailed overview on how the modular policy is built into the final binary policy for loading into the kernel, see "[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer].<br />
<br />
== Optional Policy ==<br />
The loadable module policy infrastructure supports an [[PolicyStatements#optional | optional policy statement]] that allows policy rules to be defined but only enabled in the binary policy once the conditions have been satisfied.<br />
<br />
== Conditional Policy ==<br />
Conditional policies can be implemented in monolithic or loadable module policies and allow parts of the policy to be enabled or not depending on the state of a boolean flag at run time. This is often used to enable or disable features within the policy (i.e. change the policy enforcement rules).<br />
<br />
The boolean flag status is held in kernel and can be changed using the '''setsebool'''(8) command either persistently across system re-boots or temporarily (i.e. only valid until a re-boot). The following example shows a persistent conditional policy change:<br />
<pre><br />
setsebool -P ext_gateway_audit false<br />
</pre><br />
<br />
The conditional policy language statements are the <tt>bool</tt> Statement that defines the boolean flag identifier and its initial status, and the <tt>if</tt> Statement that allows certain rules to be executed depending on the state of the boolean value or values.<br />
<br />
== Binary Policy ==<br />
This is also know as the kernel policy and is the policy file that is loaded into the kernel and is located at <nowiki>/etc/selinux/<SELINUXTYPE>/policy/policy.<version></nowiki>. Where <tt><nowiki><SELINUXTYPE</nowiki>></tt> is the policy name specified in the SELinux configuration file /etc/selinux/config and <nowiki><version></nowiki> is the SELinux [[#Policy_Versions | policy version]].<br />
<br />
The binary policy can be built from source files supplied by the Reference Policy or custom built source files.<br />
<br />
An example /etc/selinux/config file is shown below where the <tt>SELINUXTYPE=targeted</tt> entry identifies the policy name that will be used to locate and load the active policy:<br />
<pre><br />
SELINUX=permissive<br />
SELINUXTYPE=targeted<br />
</pre><br />
<br />
From the above example, the actual binary policy file would be located at /etc/selinux/targeted/policy and be called policy.29 (as version 29 is supported by F-20):<br />
<pre><br />
/etc/selinux/targeted/policy/policy.29<br />
</pre><br />
<br />
== Policy Versions ==<br />
SELinux has a policy database (defined in the libsepol library) that describes the format of data held within a [[#Binary_Policy | binary policy]], however, if any new features are added to SELinux (generally language extensions) this can result in a change to the policy database. Whenever the policy database is updated, the policy version is incremented. <br />
<br />
The '''sestatus'''(8) command will show the maximum policy version supported by the kernel in its output as follows:<br />
<pre><br />
SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
Loaded policy name targeted<br />
Current mode: enforcing<br />
Mode from config file: permissive<br />
Policy MLS status: enabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 29<br />
</pre><br />
<br />
The following table describes the different versions, although note that there is also another version that applies to the modular policy, however the main policy database version is the one that is generally quoted (some SELinux utilities give both version numbers).<br />
<br />
{| border="1"<br />
! policy db Version<br />
! modular db Version<br />
! Description<br />
<br />
|-<br />
| <center>15</center><br />
| <center>4</center><br />
| The base version when SELinux was merged into the kernel.<br />
<br />
|-<br />
| <center>16</center><br />
| <center>-</center><br />
| Added [[#Conditional_Policy | Conditional Policy]] support (the bool feature).<br />
<br />
|-<br />
| <center>17</center><br />
| <center>-</center><br />
| Added support for IPv6.<br />
<br />
|-<br />
| <center>18</center><br />
| <center>-</center><br />
| Added Netlink support.<br />
<br />
|-<br />
| <center>19</center><br />
| <center>5</center><br />
| Added MLS support, plus the validatetrans Statement.<br />
<br />
|-<br />
| <center>20</center><br />
| <center>-</center><br />
| Reduced the size of the access vector table.<br />
<br />
|-<br />
| <center>21</center><br />
| <center>6</center><br />
| Added support for the MLS range_transition Statement.<br />
<br />
|-<br />
| <center>22</center><br />
| <center>7</center><br />
| Added [[KernelPolicyLanguage#policycap | policy capabilities]] that allows various kernel options to be enabled as described in the [[NB_LSM#SELinux Filesystem | SELinux Filesystem]] section.<br />
<br />
|-<br />
| <center>23</center><br />
| <center>8</center><br />
| Added support for the permissive statement. This allows a domain to run in permissive mode while the others are still confined (instead of the all or nothing set by the <tt>SELINUX</tt> entry in the <tt>/etc/selinux/config</tt> file).<br />
<br />
|-<br />
| <center>24</center><br />
| <center>9 / 10</center><br />
| Add support for the <tt>typebounds</tt> statement. This was added to support a hierarchical relationship between two domains in multi-threaded web servers as described in "[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]".<br />
|-<br />
| <center>25</center><br />
| <center>11</center><br />
| Add support for file name transition in the <tt>type_transition</tt> rule. Requires kernel 2.6.39 minimum.<br />
<br />
|-<br />
| <center>26</center><br />
| <center>12/13</center><br />
| Add support for a class parameter in the <tt>role_transition</tt> rule.<br />
<br />
Add support for the <tt>attribute_role</tt> and <tt>roleattribute</tt> statements.<br />
<br />
These require kernel 2.6.39 minimum.<br />
<br />
|-<br />
| <center>-</center><br />
| <center>14</center><br />
| Separate tunables.<br />
<br />
|-<br />
| <center>27</center><br />
| <center>15</center><br />
| Support setting object defaults for the user, role and range components when computing a new context. Requires kernel 3.5 minimum.<br />
<br />
|-<br />
| <center>28</center><br />
| <center>16</center><br />
| Support setting object defaults for the type component when computing a new context. Requires kernel 3.5 minimum.<br />
<br />
|-<br />
| <center>29</center><br />
| <center>17</center><br />
| Support attribute names within constraints. This allows attributes as well as the types to be retrieved from a kernel policy to assist <tt>'''audit2allow'''(8)</tt> etc. to determine what attribute needs to be updated. Note that the attribute does not determine the constraint outcome, it is still the list of types associated to the constraint. Requires kernel 3.14 minimum.<br />
<br />
|-<br />
| <center>30</center><br />
|<br />
| There are two version 30 enhancements that depend on the policy being built:<br />
# For the 'selinux' target platform adds new 'xperm' rules and extends the permission sets as explained in the [[XpermRules | Extended Permission Access Vector Rules]] section. This is to support 'ioctl whitelisting' as explained in the [[XpermRules#ioctl_Operation_Rules | ioctl Operation Rules]] section.<br />
# For the 'xen' target platform support the <tt>devicetreecon</tt> statement and also expand the existing I/O memory range to 64 bits as explained in the [[XENStatements | XEN Statements]] section.<br />
<br />
|}<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_MLS | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_PandE | '''Next''']]</center><br />
|}<br />
<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_PolicyTypeNB PolicyType2015-09-25T13:47:36Z<p>RichardHaines: /* Loadable Module Policy */</p>
<hr />
<div>= Types of SELinux Policy =<br />
This section describes the different type of policy descriptions and versions that can be found within SELinux.<br />
<br />
The type of SELinux policy can described in a number of ways:<br />
<br />
# Source code - These can be described as: [[#Example_Policy | Example]], [[#Reference_Policy | Reference Policy]] or [[#Custom_Policy | Custom]]. They are generally written using either [[KernelPolicyLanguage | kernel policy language]], [[NB_RefPolicy#Reference Policy Support Macros | m4 macro support with kernel policy language]], or [[CIL_Language | CIL]].<br />
# They can also be classified as: [[#Monolithic_Policy | Monolithic]], [[#Reference_Policy | Base Module or Loadable Module]].<br />
# Policies can also be described by the [[#Policy_Functionality_Type | type of policy functionality]] they provide such as: targeted, mls, mcs, standard, strict or minimum.<br />
# Classified using language statements - These can be described as [[#Reference_Policy | Modular, Optional]] or [[#Conditional_Policy | Conditional]].<br />
# Binary policy (or kernel policy) - These can be described as [[#Policy_Versions | Monolithic, Kernel Policy or Binary file]].<br />
# Classification can also be on the '[[#Policy_Versions | policy version]]' used (examples are version 27, 28 and 29).<br />
# Policy can also be generated depending on the target platform of either 'selinux' (the default) or 'xen' (see the SELinux policy generation tools <tt>'''checkpolicy'''(8)</tt> and <tt>'''secilc'''(8)</tt> <tt>target_platform</tt> option).<br />
<br />
As can be seen the description of a policy can vary depending on the context.<br />
<br />
== Example Policy ==<br />
The Example policy is the name used to describe the original SELinux policy source used to build a [[#Policy_Versions | monolithic]]<ref name="ftn12"><sup>The term 'monolithic' generally means a single policy source is used to create the binary policy file that is then loaded as the 'policy' using the '''checkpolicy'''(8) command. However the term is sometimes used to refer to the binary policy file (as it is one file that describes the policy).</sup></ref> policy produced by the NSA and is now superseded by the Reference Policy.<br />
<br />
== Reference Policy ==<br />
Note that this section only gives an introduction to the Reference Policy, the installation, configuration and building of a policy using this is contained in [[NB_RefPolicy | The Reference Policy]] section.<br />
<br />
The Reference Policy is now the standard policy source used to build Linux based SELinux policies, and its main aim is to provide a single source tree with supporting documentation that can be used to build policies for different purposes such as confining important daemons, supporting MLS / MCS and locking down systems so that all processes are under SELinux control. <br />
<br />
The Reference Policy is now used by all major distributions of Linux, however each distribution makes its own specific changes to support their 'version of the Reference Policy'. For example, the F-20 distribution is based on a specific build of the standard Reference Policy that is then modified and distributed by Red Hat as a number of RPMs.<br />
<br />
== Policy Functionality Based on Name or Type ==<br />
Generally a policy is installed with a given name such as <tt>targeted</tt>, <tt>mls</tt>, <tt>refpolicy</tt> or <tt>minimum</tt> that attempts to describes its functionality. This name then becomes the entry in: <br />
<br />
# The directory pointing to the policy location (e.g. if the name is <tt>targeted</tt>, then the policy will be installed in <tt>/etc/selinux/targeted</tt>).<br />
# The <tt>SELINUXTYPE</tt> entry in the <tt>/etc/selinux/config</tt> file when it is the active policy (e.g. if the name is <tt>targeted</tt>, then a <tt>SELINUXTYPE=targeted</tt> entry would be in the <tt>/etc/selinux/config</tt> file).<br />
<br />
This is how the reference policies distributed with F-20 are named, where:<br />
: minimum - supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space. Red Hat pre-configure MCS support within this policy.<br />
: targeted - supports a greater number of confined daemons and can also confine other areas and users. Red Hat pre-configure MCS support within this policy.<br />
: mls - supports server based MLS systems.<br />
<br />
The Reference Policy also has a <tt>TYPE</tt> description that describes the type of policy being built by the build process, these are:<br />
: standard - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older 'targeted' and 'strict' versions).<br />
: mcs - As standard but supports MCS labels.<br />
: mls - supports server based MLS systems.<br />
<br />
The <tt>NAME</tt> and <tt>TYPE</tt> entries are defined in the reference policy <tt>build.conf</tt> file that is described in the [[NB_RefPolicy#Source Configuration Files | Source Configuration Files]] section. <br />
<br />
== Custom Policy ==<br />
This generally refers to a policy source that is either:<br />
<br />
# A customised version of the Example policy.<br />
# A customised version of the Reference Policy (i.e. not the standard distribution version e.g. Red Hat policies).<br />
# A policy that has been built using policy language statements to build a specific policy such as the basic policy built in the Notebook source tarball.<br />
<br />
== Monolithic Policy ==<br />
A Monolithic policy is an SELinux policy that is compiled from one source file called (by convention) <tt>policy.conf</tt> (i.e. it does not use the Loadable Module Policy statements and infrastructure which therefore makes it suitable for embedded systems as there is no policy store overhead). <br />
<br />
An example monolithic policy is the NSAs original [[#Example_Policy | Example Policy]].<br />
<br />
Monolithic policies are compiled using the '''checkpolicy''' (8) SELinux command. <br />
<br />
The Reference Policy supports the building of monolithic policies.<br />
<br />
In some cases the kernel policy binary file (see the [[#Binary Policy | Binary Policy]] section) is also called a monolithic policy.<br />
<br />
== Loadable Module Policy ==<br />
The loadable module infrastructure allows policy to be managed on a modular basis, in that there is a base policy module that contains all the core components of the policy (i.e. the policy that should always be present), and zero or more modules that can be loaded and unloaded as required (for example if there is a module to enforce policy for ftp, but ftp is not used, then that module could be unloaded).<br />
<br />
There are number of components that form the infrastructure:<br />
<br />
# Policy source code that is constructed for a modular policy with a base module and optional loadable modules.<br />
# Utilities to compile and link modules and place them into a 'policy store'.<br />
# Utilities to manage the modules and associated configuration files within the 'policy store'.<br />
<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows these components along the top of the diagram. The files contained in the policy store are detailed in the [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]] section.<br />
<br />
The policy language was extended to handle loadable modules as detailed in the [[PolicyStatements | Modular Policy Support Statements]] section. For a detailed overview on how the modular policy is built into the final binary policy for loading into the kernel, see "[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer].<br />
<br />
== Optional Policy ==<br />
The loadable module policy infrastructure supports an [[KernelPolicyLanguage#optional | optional policy statement]] that allows policy rules to be defined but only enabled in the binary policy once the conditions have been satisfied. <br />
<br />
== Conditional Policy ==<br />
Conditional policies can be implemented in monolithic or loadable module policies and allow parts of the policy to be enabled or not depending on the state of a boolean flag at run time. This is often used to enable or disable features within the policy (i.e. change the policy enforcement rules).<br />
<br />
The boolean flag status is held in kernel and can be changed using the '''setsebool'''(8) command either persistently across system re-boots or temporarily (i.e. only valid until a re-boot). The following example shows a persistent conditional policy change:<br />
<pre><br />
setsebool -P ext_gateway_audit false<br />
</pre><br />
<br />
The conditional policy language statements are the <tt>bool</tt> Statement that defines the boolean flag identifier and its initial status, and the <tt>if</tt> Statement that allows certain rules to be executed depending on the state of the boolean value or values.<br />
<br />
== Binary Policy ==<br />
This is also know as the kernel policy and is the policy file that is loaded into the kernel and is located at <nowiki>/etc/selinux/<SELINUXTYPE>/policy/policy.<version></nowiki>. Where <tt><nowiki><SELINUXTYPE</nowiki>></tt> is the policy name specified in the SELinux configuration file /etc/selinux/config and <nowiki><version></nowiki> is the SELinux [[#Policy_Versions | policy version]].<br />
<br />
The binary policy can be built from source files supplied by the Reference Policy or custom built source files.<br />
<br />
An example /etc/selinux/config file is shown below where the <tt>SELINUXTYPE=targeted</tt> entry identifies the policy name that will be used to locate and load the active policy:<br />
<pre><br />
SELINUX=permissive<br />
SELINUXTYPE=targeted<br />
</pre><br />
<br />
From the above example, the actual binary policy file would be located at /etc/selinux/targeted/policy and be called policy.29 (as version 29 is supported by F-20):<br />
<pre><br />
/etc/selinux/targeted/policy/policy.29<br />
</pre><br />
<br />
== Policy Versions ==<br />
SELinux has a policy database (defined in the libsepol library) that describes the format of data held within a [[#Binary_Policy | binary policy]], however, if any new features are added to SELinux (generally language extensions) this can result in a change to the policy database. Whenever the policy database is updated, the policy version is incremented. <br />
<br />
The '''sestatus'''(8) command will show the maximum policy version supported by the kernel in its output as follows:<br />
<pre><br />
SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
Loaded policy name targeted<br />
Current mode: enforcing<br />
Mode from config file: permissive<br />
Policy MLS status: enabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 29<br />
</pre><br />
<br />
The following table describes the different versions, although note that there is also another version that applies to the modular policy, however the main policy database version is the one that is generally quoted (some SELinux utilities give both version numbers).<br />
<br />
{| border="1"<br />
! policy db Version<br />
! modular db Version<br />
! Description<br />
<br />
|-<br />
| <center>15</center><br />
| <center>4</center><br />
| The base version when SELinux was merged into the kernel.<br />
<br />
|-<br />
| <center>16</center><br />
| <center>-</center><br />
| Added [[#Conditional_Policy | Conditional Policy]] support (the bool feature).<br />
<br />
|-<br />
| <center>17</center><br />
| <center>-</center><br />
| Added support for IPv6.<br />
<br />
|-<br />
| <center>18</center><br />
| <center>-</center><br />
| Added Netlink support.<br />
<br />
|-<br />
| <center>19</center><br />
| <center>5</center><br />
| Added MLS support, plus the validatetrans Statement.<br />
<br />
|-<br />
| <center>20</center><br />
| <center>-</center><br />
| Reduced the size of the access vector table.<br />
<br />
|-<br />
| <center>21</center><br />
| <center>6</center><br />
| Added support for the MLS range_transition Statement.<br />
<br />
|-<br />
| <center>22</center><br />
| <center>7</center><br />
| Added [[KernelPolicyLanguage#policycap | policy capabilities]] that allows various kernel options to be enabled as described in the [[NB_LSM#SELinux Filesystem | SELinux Filesystem]] section.<br />
<br />
|-<br />
| <center>23</center><br />
| <center>8</center><br />
| Added support for the permissive statement. This allows a domain to run in permissive mode while the others are still confined (instead of the all or nothing set by the <tt>SELINUX</tt> entry in the <tt>/etc/selinux/config</tt> file).<br />
<br />
|-<br />
| <center>24</center><br />
| <center>9 / 10</center><br />
| Add support for the <tt>typebounds</tt> statement. This was added to support a hierarchical relationship between two domains in multi-threaded web servers as described in "[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]".<br />
|-<br />
| <center>25</center><br />
| <center>11</center><br />
| Add support for file name transition in the <tt>type_transition</tt> rule. Requires kernel 2.6.39 minimum.<br />
<br />
|-<br />
| <center>26</center><br />
| <center>12/13</center><br />
| Add support for a class parameter in the <tt>role_transition</tt> rule.<br />
<br />
Add support for the <tt>attribute_role</tt> and <tt>roleattribute</tt> statements.<br />
<br />
These require kernel 2.6.39 minimum.<br />
<br />
|-<br />
| <center>-</center><br />
| <center>14</center><br />
| Separate tunables.<br />
<br />
|-<br />
| <center>27</center><br />
| <center>15</center><br />
| Support setting object defaults for the user, role and range components when computing a new context. Requires kernel 3.5 minimum.<br />
<br />
|-<br />
| <center>28</center><br />
| <center>16</center><br />
| Support setting object defaults for the type component when computing a new context. Requires kernel 3.5 minimum.<br />
<br />
|-<br />
| <center>29</center><br />
| <center>17</center><br />
| Support attribute names within constraints. This allows attributes as well as the types to be retrieved from a kernel policy to assist <tt>'''audit2allow'''(8)</tt> etc. to determine what attribute needs to be updated. Note that the attribute does not determine the constraint outcome, it is still the list of types associated to the constraint. Requires kernel 3.14 minimum.<br />
<br />
|-<br />
| <center>30</center><br />
|<br />
| There are two version 30 enhancements that depend on the policy being built:<br />
# For the 'selinux' target platform adds new 'xperm' rules and extends the permission sets as explained in the [[XpermRules | Extended Permission Access Vector Rules]] section. This is to support 'ioctl whitelisting' as explained in the [[XpermRules#ioctl_Operation_Rules | ioctl Operation Rules]] section.<br />
# For the 'xen' target platform support the <tt>devicetreecon</tt> statement and also expand the existing I/O memory range to 64 bits as explained in the [[XENStatements | XEN Statements]] section.<br />
<br />
|}<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_MLS | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_PandE | '''Next''']]</center><br />
|}<br />
<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_MLSNB MLS2015-09-25T13:43:41Z<p>RichardHaines: </p>
<hr />
<div>= Multi-Level Security and Multi-Category Security =<br />
As stated in the [[NB_MAC | Mandatory Access Control (MAC)]] section as well as supporting Type Enforcement (TE), SELinux also supports MLS and MCS by adding an optional <tt>level</tt> or <tt>range</tt> entry to the security context. This section gives a brief introduction to MLS and MCS.<br />
<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/8-security-levels.png Security Levels and Data Flows] diagram shows a simple view where security levels represent the classification of files within a file server. The security levels are strictly hierarchical and conform to the [http://en.wikipedia.org/wiki/Bell-LaPadula_model Bell-La Padula model] (BLP) in that (in the case of SELinux) a process (running at the "Confidential" level) can read / write at their current level but only read down levels or write up levels (the assumption here is that the process is authorised).<br />
<br />
This ensures confidentiality as the process can copy a file up to the secret level, but can never re-read that content unless the process "steps up to that level", also the process cannot write files to the lower levels as confidential information would then drift downwards.<br />
<br />
To achieve this level of control, the MLS extensions to SELinux make use of constraints similar to those described in the type enforcement [[NB_TE#Constraints | Constraints]] section, except that the statement is called [[MLSStatements | mlsconstrain]]. <br />
<br />
However, as always life is not so simple as:<br />
<br />
# Processes and objects can be given a range that represents the low and high security levels.<br />
# The security level can be more complex, in that it is a hierarchical sensitivity and zero or more non-hierarchical categories.<br />
# Allowing a process access to an object is managed by "dominance" rules applied to the security levels. <br />
# Trusted processes can be given privileges that will allow them to bypass the BLP rules and basically do anything (that the security policy allowed of course).<br />
# Some objects do not support separate read / write functions as they need to read / respond in cases such as networks.<br />
<br />
The sections that follow discuss the format of a security level and range, and how these are managed by the constraints mechanism within SELinux using the "dominance" rules.<br />
<br />
== Security Levels ==<br />
Table 1 shows the components that make up a security level and how two security levels form a range for the fourth and optional <tt><nowiki>[:level]</nowiki></tt> of the [[NB_SC | security context]] within an MLS / MCS environment.<br />
<br />
The table also adds terminology in general use as other terms can be used that have the same meanings. <br />
<br />
''Table 1: Level, Label, Category or Compartment - this table shows the meanings depending on the context being discussed.''<br />
{|border="1"<br />
|<center>'''Security Level (or Level)'''</center><br />
<br />
<center>Consisting of a sensitivity and zero or more category entries:</center><br />
<br />
!colspan="2" rowspan="2"| Note that SELinux uses level, sensitivity and category in the language statements, however when discussing these the following terms can also be used: labels, classifications, and compartments.<br />
<br />
|-<br />
| <tt><center>sensitivity [: category, ... ]</center></tt><br />
<br />
<center>also known as:</center><br />
<br />
<center>'''Sensitivity Label'''</center><br />
<br />
<center>Consisting of a classification and compartment.</center><br />
<br />
|-<br />
!colspan="3"|<center>Range</center><br />
<br />
|-<br />
|<center>Low</center><br />
| <br />
|<center>High</center><br />
<br />
|-<br />
| <tt><center>sensitivity [: category, ... ]</center></tt><br />
| <center>-</center><br />
| <tt><center>sensitivity [: category, ... ]</center></tt><br />
<br />
|-<br />
|<center>For a process or subject this is the current level or sensitivity</center><br />
| <br />
|<center>For a process or subject this is the Clearance</center><br />
<br />
|-<br />
|<center>For an object this is the current level or sensitivity</center><br />
| <br />
|<center>For an object this is the maximum range </center><br />
<br />
<center>(for SELinux polyinstantiated directories)</center><br />
<br />
|-<br />
|<tt><center>SystemLow</center></tt><br />
| <br />
|<tt><center>SystemHigh</center></tt><br />
<br />
|-<br />
|<center>This is the lowest level or classification for the system (for SELinux this is generally '<tt>s0</tt>', note that there are no categories).</center><br />
| <br />
|<center>This is the highest level or classification for the system (for SELinux this is generally '<tt>s15:c0,c255</tt>', although note that they will be the highest set by the policy).</center><br />
<br />
|}<br />
<br />
<br />
The format used in the policy language statements is fully described in the [[MLSStatements | MLS Statements]] section, however a brief overview follows.<br />
<br />
=== MLS / MCS Range Format ===<br />
The following components are used to define the MLS / MCS security levels within the security context:<br />
<pre><br />
user:role:type:sensitivity[:category,...] - sensitivity [:category,...]<br />
---------------â–¼------------------------â–¼-----â–¼-------------------------â–¼<br />
| level | - | level |<br />
| |<br />
|range|<br />
</pre><br />
<br />
'''Where:'''<br />
{| border="1"<br />
| <tt>sensitivity</tt><br />
| Sensitivity levels are hierarchical with (traditionally) <tt>s0</tt> being the lowest. These values are defined using the <tt>sensitivity</tt> language statement. To define their hierarchy, the <tt>dominance</tt> statement is used.<br />
<br />
For MLS systems the highest sensitivity is the last one defined in the dominance statement (low to high). Traditionally the maximum for MLS systems is <tt>s15</tt> (although the maximum value for the Reference Policy is a compile time option). <br />
<br />
For MCS systems there is only one sensitivity defined, and that is <tt>s0</tt>.<br />
<br />
|-<br />
| <tt>category</tt><br />
| Categories are optional (i.e. there can be zero or more categories) and they form unordered and unrelated lists of "compartments". These values are defined using the <tt>category</tt> statement, where for example <tt>c0.c3</tt> represents a range (<tt>c0 c1 c3</tt>) and <tt>c0, c3, c7</tt> represent an unordered list. Traditionally the values are between <tt>c0</tt> and <tt>c255</tt> (although the maximum value for the Reference Policy is a compile time option).<br />
<br />
|-<br />
| <tt>level</tt><br />
| The level is a combination of the sensitivity and category values that form the actual security level. These values are defined using the <tt>level</tt> statement.<br />
<br />
|}<br />
<br />
<br />
=== Translating Levels ===<br />
When writing policy for MLS / MCS security level components it is usual to use an abbreviated form such as s0, s1 etc. to represent sensitivities and c0, c1 etc. to represent categories. This is done simply to conserve space as they are held on files as extended attributes and also in memory. So that these labels can be represented in human readable form, a translation service is provided via the [[PolicyConfigurationFiles#setrans.conf File | setrans.conf]] configuration file that is used by the '''mcstransd'''(8) daemon. For example s0 = Unclassified, s15 = Top Secret and c0 = Finance, c100 = Spy Stories. The '''semanage'''(8) command can be used to set up this translation and is shown in the [[PolicyConfigurationFiles#setrans.conf_File | setrans.conf]] configuration file section.<br />
<br />
== Managing Security Levels via Dominance Rules ==<br />
As stated earlier, allowing a process access to an object is managed by "dominance" rules applied to the security levels. These rules are as follows:<br />
<br />
: '''Security Level 1 dominates Security Level 2''' - If the sensitivity of Security Level 1 is equal to or higher than the sensitivity of Security Level 2 and the categories of Security Level 1 are the same or a superset of the categories of Security Level 2.<br />
<br />
: '''Security Level 1 is dominated by Security Level 2''' - If the sensitivity of Security Level 1 is equal to or lower than the sensitivity of Security Level 2 and the categories of Security Level 1 are a subset of the categories of Security Level 2.<br />
<br />
: '''Security Level 1 equals Security Level 2''' - If the sensitivity of Security Level 1 is equal to Security Level 2 and the categories of Security Level 1 and Security Level 2 are the same set (sometimes expressed as: both Security Levels dominate each other).<br />
<br />
: '''Security Level 1 is incomparable to Security Level 2''' - If the categories of Security Level 1 and Security Level 2 cannot be compared (i.e. neither Security Level dominates the other).<br />
<br />
To illustrate the usage of these rules, the [http://selinuxproject.org/~rhaines/diagrams/t2-MLS-Security-Levels.png MLS Security Levels example] table lists the security level attributes in a table to show example files (or documents) that have been allocated labels such as <tt>s3:c0</tt>. The process that accesses these files (e.g. an editor) is running with a range of <tt>s0 - s3:c1.c5</tt> and has access to the files highlighted within the grey box area.<br />
<br />
As the MLS <tt>dominance</tt> Statement is used to enforce the sensitivity hierarchy, the security levels now follow that sequence (lowest = <tt>s0</tt> to highest = <tt>s3</tt>) with the categories being unordered lists of "compartments". To allow the process access to files within its scope and within the dominance rules, the process will be constrained by using the <tt>mlsconstrain</tt> statement as illustrated in the [http://selinuxproject.org/~rhaines/diagrams/9-mls-constrain.png MLS constrain] diagram. <br />
<br />
So using the [http://selinuxproject.org/~rhaines/NB4-diagrams/9-mls-constrain.png MLS constrain] diagram:<br />
<br />
# To allow write-up, the source level (<tt>l1</tt>) must be '''dominated by''' the target level (<tt>l2</tt>):<br />
: Source level = <tt>s0:c3</tt> or <tt>s1:c1</tt><br />
: Target level = <tt>s2:c1.c4</tt><br />
<br />
As can be seen, either of the source levels are '''dominated by''' the target level.<br />
<br />
# To allow read-down, the source level (<tt>l1</tt>) must '''dominate''' the target level (<tt>l2</tt>):<br />
: Source level = <tt>s2:c1.c4</tt><br />
: Target level = <tt>s0:c3</tt><br />
<br />
As can be seen, the source level does '''dominate''' the target level.<br />
<br />
However in the real world the SELinux MLS Reference Policy does not allow the write-up unless the process has a special privilege (by having the domain type added to an attribute), although it does allow the read-down. The default is to use <tt>l1 eq l2</tt> (i.e. the levels are equal). The reference policy MLS source file (policy/mls) shows these mlsconstrain statements.<br />
<br />
== MLS Labeled Network and Database Support ==<br />
Networking for MLS is supported via the NetLabel CIPSO (commercial IP security option) service as discussed in the [[NB_Networking | SELinux Networking Support]] section.<br />
<br />
PostgreSQL supports labeling for MLS database services as discussed in the [[NB_SQL_9.3 | SE-PostgreSQL Support]] section.<br />
<br />
== Common Criteria Certification ==<br />
While the [http://www.commoncriteriaportal.org/ Common Criteria] certification process is beyond the scope of this Notebook, it is worth highlighting that specific Red Hat GNU / Linux versions of software, running on specific hardware platforms with SELinux / MLS policy enabled, have passed the Common Criteria evaluation process. Note, for the evaluation (and deployment) the software and hardware are tied together, therefore whenever an update is carried out, an updated certificate should be obtained.<br />
<br />
The Red Hat evaluation process cover the:<br />
* Labeled Security Protection Profile ([http://www.commoncriteriaportal.org/files/ppfiles/lspp.pdf LSPP] ) - This describes how systems that implement security labels (i.e. MLS) should function.<br />
* Controlled Access Protection Profile ([http://www.commoncriteriaportal.org/files/ppfiles/capp.pdf CAPP]) - This describes how systems that implement DAC should function.<br />
<br />
An interesting point:<br />
* Both Red Hat Linux 5.1 and Microsoft Server 2003 (with XP) have both been certified to EAL4+ , however while the evaluation levels may be the same the Protection Profiles that they were evaluated under were: Microsoft CAPP only, Red Hat CAPP and LSPP. Therefore always look at the protection profiles as they define what was actually evaluated.<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Domain_and_Object_Transitions | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_PolicyType | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_Domain_and_Object_TransitionsNB Domain and Object Transitions2015-09-25T13:41:17Z<p>RichardHaines: /* Domain Transition */</p>
<hr />
<div>= Domain and Object Transitions =<br />
This section discusses the type_transition statement that is used to:<br />
<br />
# Transition a process from one domain to another (a domain transition).<br />
# Transition an object from one type to another (an object transition).<br />
<br />
These transitions can also be achieved using the libselinux API functions for SELinux-aware applications.<br />
<br />
== Domain Transition ==<br />
A domain transition is where a process in one domain starts a new process in another domain under a different security context. There are two ways a process can define a domain transition:<br />
<br />
# Using a type_transition statement, where the exec system call will automatically perform a domain transition for programs that are not themselves SELinux-aware. This is the most common method and would be in the form of the following statement:<br />
<pre><br />
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br />
</pre><br />
<br />
# SELinux-aware applications can specify the domain of the new process using the libselinux API call '''setexeccon'''(3). To achieve this the SELinux-aware application must also have the setexec permission, for example:<br />
<pre><br />
allow crond_t self : process setexec;<br />
</pre><br />
<br />
However, before any domain transition can take place the policy must specify that:<br />
<br />
# The source ''domain ''has permission to ''transition'' into the target domain.<br />
# The application binary file needs to be ''executable'' in the source domain.<br />
# The application binary file needs an ''entry point'' into the target domain.<br />
<br />
The following is a type_transition statement taken from the example loadable module message filter <tt>ext_gateway.conf</tt> (described in the source tarball) that will be used to explain the transition process<ref name="ftn11"><sup>For reference, the external gateway uses a server application called secure_server that is transitioned to the ext_gateway_t domain from the unconfined_t domain. The secure_server executable is labeled secure_services_exec_t.</sup></ref>:<br />
<br />
<pre><br />
type_transition | source_domain | target_type : class | target_domain;<br />
---------------- â–¼ --------------- â–¼ ---------------------- â–¼ -------- â–¼ ------------------------<br />
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t<nowiki>;<br />
</pre><br />
<br />
This type_transition statement states that when a ''process'' running in the ''unconfined_t'' domain (the source domain) executes a file labeled ''secure_services_exec_t'', the ''process'' should be changed to ''ext_gateway_t'' (the target domain) if allowed by the policy (i.e. transition from the ''unconfined_t'' domain to the ''ext_gateway_t ''domain).<br />
<br />
However as stated above, to be able to ''transition'' to the ''ext_gateway_t'' domain, the following minimum permissions must be granted in the policy using allow rules, where (note that the bullet numbers correspond to the numbers shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram):<br />
<br />
# The ''domain'' needs permission to ''transition'' into the ''ext_gateway_t'' (target) domain:<br />
<pre><br />
allow unconfined_t ext_gateway_t : process transition;<br />
</pre><br />
<br />
# The executable file needs to be ''executable'' in the ''unconfined_t'' (source) domain, and therefore also requires that the file is readable:<br />
<pre><br />
allow unconfined_t secure_services_exec_t : file { execute read getattr };<br />
</pre><br />
<br />
# The executable file needs an ''entry point'' into the ''ext_gateway_t'' (target) domain:<br />
<pre><br />
allow ext_gateway_t secure_services_exec_t : file entrypoint;<br />
</pre><br />
<br />
These are shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram where unconfined_t forks a child process, that then exec's the new program into a new domain called ext_gateway_t. Note that because the type_transition statement is being used, the transition is automatically carried out by the SELinux enabled kernel.<br />
<br />
<br />
=== Type Enforcement Rules ===<br />
When building the ext_gateway.conf and int_gateway.conf modules the intention was to have both of these transition to their respective domains via type_transition statements. The ext_gateway_t statement would be:<br />
<pre><br />
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br />
</pre><br />
<br />
and the int_gateway_t statement would be:<br />
<pre><br />
type_transition unconfined_t secure_services_exec_t : process int_gateway_t;<br />
</pre><br />
<br />
However, when linking these two loadable modules into the policy, the following error was given:<br />
<pre><br />
semodule -v -s modular-test -i int_gateway.pp -i ext_gateway.pp<br />
Attempting to install module 'int_gateway.pp':<br />
Ok: return value of 0.<br />
Attempting to install module 'ext_gateway.pp':<br />
Ok: return value of 0.<br />
Committing changes:<br />
libsepol.expand_terule_helper: conflicting TE rule for (unconfined_t, secure_services_exec_t:process): old was ext_gateway_t, new is int_gateway_t<br />
libsepol.expand_module: Error during expand<br />
libsemanage.semanage_expand_sandbox: Expand module failed<br />
semodule: Failed!<br />
</pre><br />
<br />
This happened because the type enforcement rules will only allow a single 'default' type for a given source and target (see the Type Rules section). In the above case there were two type_transition statements with the same source and target, but different default domains. The ext_gateway.conf module had the following statements:<br />
<pre><br />
# Allow the client/server to transition for the gateways:<br />
allow unconfined_t ext_gateway_t : process { transition };<br />
allow unconfined_t secure_services_exec_t : file { read execute getattr };<br />
allow ext_gateway_t secure_services_exec_t : file { entrypoint };<br />
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br />
</pre><br />
<br />
And the int_gateway.conf module had the following statements:<br />
<pre><br />
# Allow the client/server to transition for the gateways:<br />
allow unconfined_t int_gateway_t : process { transition };<br />
allow unconfined_t secure_services_exec_t : file { read execute getattr };<br />
allow int_gateway_t secure_services_exec_t : file { entrypoint };<br />
type_transition unconfined_t secure_services_exec_t : process int_gateway_t;<br />
</pre><br />
<br />
While the allow rules are valid to enable the transitions to proceed, the two type_transition statements had different 'default' types (or target domains), that breaks the type enforcement rule.<br />
<br />
It was decided to resolve this by:<br />
<br />
1) Keeping the type_transition rule for the 'default' type of ext_gateway_t and allow the secure server process to be exec'd from unconfined_t as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram, by simply running the command from the prompt as follows:<br />
<pre><br />
# Run the external gateway 'secure server' application on port 9999 and<br />
# let the policy transition the process to the ext_gateway_t domain:<br />
<br />
secure_server 99999<br />
</pre><br />
<br />
2) Use the SELinux '''runcon'''(1) command to ensure that the internal gateway runs in the correct domain by running runcon from the prompt as follows:<br />
<pre><br />
# Run the internal gateway 'secure server' application on port 1111 and<br />
# use runcon to transition the process to the int_gateway_t domain:<br />
<br />
runcon -t int_gateway_t -r message_filter_r secure_server 1111<br />
<br />
# Note - The role is required as a role transition is defined in the policy.<br />
</pre><br />
<br />
The runcon command makes use of a number of libselinux API functions to check the current context and set up the new context (for example '''getfilecon'''(3) is used to get the executable files context and '''setexeccon'''(3) is used to set the new process context). If all contexts are correct, then the '''execvp'''(2) system call is executed that exec's the secure_server application with the argument of '1111' into the int_gateway_t domain with the message_filter_r role. The runcon source can be found in the coreutils package.<br />
<br />
Other ways to resolve this issue are:<br />
<br />
# Use the runcon command for both gateways to transition to their respective domains. The type_transition statements are therefore not required.<br />
# Use different names for the secure server executable files and ensure they have a different type (i.e. instead of secure_service_exec_t label the external gateway ext_gateway_exec_t and the internal gateway int_gateway_exec_t. This would involve making a copy of the application binary (which has already been done as part of the module testing by calling the server 'server' and labeling it unconfined_t and then making a copy called secure_server and labeling it secure_services_exec_t).<br />
# Implement the policy using the Reference Policy utilising the template interface principles discussed in the [[NB_RefPolicy#template Macro |Reference Policy Template Macro]] section.<br />
<br />
It was decided to use runcon as it demonstrates the command usage better than reading the man pages.<br />
<br />
== Object Transition ==<br />
An object transition is where a new object requires a different label to that of its parent. For example a file is being created that requires a different label to that of its parent directory. This can be achieved automatically using a type_transition statement as follows: <br />
<pre><br />
type_transition ext_gateway_t in_queue_t:file in_file_t;<br />
</pre<br />
<br />
The following details an object transition used in the ext_gateway.conf loadable module (see the source tarball) where by default, files would be labeled in_queue_t when created by the gateway application as this is the label attached to the parent directory as shown:<br />
<pre><br />
ls -Za /usr/message_queue/in_queue<br />
drwxr-xr-x root root unconfined_u:object_r:in_queue_t .<br />
drwxr-xr-x root root system_u:object_r:unconfined_t ..<br />
</pre><br />
<br />
However the requirement is that files in the in_queue directory must be labeled in_file_t. To achieve this the files created must be relabeled to in_file_t by using a type_transition rule as follows:<br />
<pre><br />
# type_transition | source_domain | target_type : object | default_type;<br />
----------------- â–¼ --------------- â–¼ -------------------- â–¼ ---------------<br />
type_transition ext_gateway_t in_queue_t : file in_file_t;<br />
</pre><br />
<br />
This type_transition statement states that when a ''process'' running in the ''ext_gateway_t'' domain (the source domain) wants to create a ''file'' object in the directory that is labeled ''in_queue_t'', the file should be relabeled ''in_file_t'' if allowed by the policy (i.e. label the file ''in_file_t'').<br />
<br />
However as stated abov,e to be able to create the file, the following minimum permissions need to be granted in the policy using allow rules, where:<br />
<pre><br />
# The source domain needs permission to add file entries into the directory:<br />
allow ext_gateway_t in_queue_t : dir { write search add_name };<br />
<br />
# The source domain needs permission to create file entries:<br />
allow ext_gateway_t in_file_t : file { write create getattr };<br />
<br />
# The policy can then ensure (via the SELinux kernel services) that files created in the <tt>in_queue</tt> are relabeled:<br />
type_transition ext_gateway_t in_queue_t : file in_file_t;<br />
</pre><br />
<br />
An example output from a directory listing shows the resulting file labels:<br />
<pre><br />
ls -Za /usr/message_queue/in_queue<br />
drwxr-xr-x root root unconfined_u:object_r:in_queue_t .<br />
drwxr-xr-x root root system_u:object_r:unconfined_t ..<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t Message-1<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t Message-2<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_ComputingAccessDecisions | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_MLS | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_Domain_and_Object_TransitionsNB Domain and Object Transitions2015-09-25T13:39:34Z<p>RichardHaines: /* Domain Transition */</p>
<hr />
<div>= Domain and Object Transitions =<br />
This section discusses the type_transition statement that is used to:<br />
<br />
# Transition a process from one domain to another (a domain transition).<br />
# Transition an object from one type to another (an object transition).<br />
<br />
These transitions can also be achieved using the libselinux API functions for SELinux-aware applications.<br />
<br />
== Domain Transition ==<br />
A domain transition is where a process in one domain starts a new process in another domain under a different security context. There are two ways a process can define a domain transition:<br />
<br />
# Using a type_transition statement, where the exec system call will automatically perform a domain transition for programs that are not themselves SELinux-aware. This is the most common method and would be in the form of the following statement:<br />
<pre><br />
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br />
</pre><br />
<br />
# SELinux-aware applications can specify the domain of the new process using the libselinux API call '''setexeccon'''(3). To achieve this the SELinux-aware application must also have the setexec permission, for example:<br />
<pre><br />
allow crond_t self : process setexec;<br />
</pre><br />
<br />
However, before any domain transition can take place the policy must specify that:<br />
<br />
# The source ''domain ''has permission to ''transition'' into the target domain.<br />
# The application binary file needs to be ''executable'' in the source domain.<br />
# The application binary file needs an ''entry point'' into the target domain.<br />
<br />
The following is a type_transition statement taken from the example loadable module message filter <tt>ext_gateway.conf</tt> (described in the source tarball) that will be used to explain the transition process<ref name="ftn11"><sup>For reference, the external gateway uses a server application called secure_server that is transitioned to the ext_gateway_t domain from the unconfined_t domain. The secure_server executable is labeled secure_services_exec_t.</sup></ref>:<br />
<br />
<pre><br />
type_transition | source_domain | target_type : class | target_domain;<br />
---------------- â–¼ --------------- â–¼ ---------------------- â–¼ -------- â–¼ ------------------------<br />
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t<nowiki>;<br />
</pre><br />
<br />
This type_transition statement states that when a ''process'' running in the ''unconfined_t'' domain (the source domain) executes a file labeled ''secure_services_exec_t'', the ''process'' should be changed to ''ext_gateway_t'' (the target domain) if allowed by the policy (i.e. transition from the ''unconfined_t'' domain to the ''ext_gateway_t ''domain).<br />
<br />
However as stated above, to be able to ''transition'' to the ''ext_gateway_t'' domain, the following minimum permissions must be granted in the policy using allow rules, where (note that the bullet numbers correspond to the numbers shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram):<br />
<br />
# The ''domain'' needs permission to ''transition'' into the ''ext_gateway_t'' (target) domain:<br />
<pre><br />
allow unconfined_t ext_gateway_t : process transition;<br />
</pre><br />
<br />
# The executable file needs to be ''executable'' in the ''unconfined_t'' (source) domain, and therefore also requires that the file is readable:<br />
<pre><br />
allow unconfined_t secure_services_exec_t : file { execute read getattr };<br />
</pre><br />
<br />
# The executable file needs an ''entry point'' into the ''ext_gateway_t'' (target) domain:<br />
<pre><br />
allow ext_gateway_t secure_services_exec_t : file entrypoint;<br />
</pre><br />
<br />
These are shown in the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram where unconfined_t forks a child process, that then exec's the new program into a new domain called ext_gateway_t. Note that because the type_transition statement is being used, the transition is automatically carried out by the SELinux enabled kernel.<br />
<br />
<br />
=== Type Enforcement Rules ===<br />
When building the ext_gateway.conf and int_gateway.conf modules the intention was to have both of these transition to their respective domains via type_transition statements. The ext_gateway_t statement would be:<br />
<pre><br />
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br />
</pre><br />
<br />
and the int_gateway_t statement would be:<br />
<pre><br />
type_transition unconfined_t secure_services_exec_t : process int_gateway_t;<br />
</pre><br />
<br />
However, when linking these two loadable modules into the policy, the following error was given:<br />
<pre><br />
semodule -v -s modular-test -i int_gateway.pp -i ext_gateway.pp<br />
Attempting to install module 'int_gateway.pp':<br />
Ok: return value of 0.<br />
Attempting to install module 'ext_gateway.pp':<br />
Ok: return value of 0.<br />
Committing changes:<br />
libsepol.expand_terule_helper: conflicting TE rule for (unconfined_t, secure_services_exec_t:process): old was ext_gateway_t, new is int_gateway_t<br />
libsepol.expand_module: Error during expand<br />
libsemanage.semanage_expand_sandbox: Expand module failed<br />
semodule: Failed!<br />
</pre><br />
<br />
This happened because the type enforcement rules will only allow a single 'default' type for a given source and target (see the Type Rules section). In the above case there were two type_transition statements with the same source and target, but different default domains. The ext_gateway.conf module had the following statements:<br />
<pre><br />
# Allow the client/server to transition for the gateways:<br />
allow unconfined_t ext_gateway_t : process { transition };<br />
allow unconfined_t secure_services_exec_t : file { read execute getattr };<br />
allow ext_gateway_t secure_services_exec_t : file { entrypoint };<br />
type_transition unconfined_t secure_services_exec_t : process ext_gateway_t;<br />
</pre><br />
<br />
And the int_gateway.conf module had the following statements:<br />
<pre><br />
# Allow the client/server to transition for the gateways:<br />
allow unconfined_t int_gateway_t : process { transition };<br />
allow unconfined_t secure_services_exec_t : file { read execute getattr };<br />
allow int_gateway_t secure_services_exec_t : file { entrypoint };<br />
type_transition unconfined_t secure_services_exec_t : process int_gateway_t;<br />
</pre><br />
<br />
While the allow rules are valid to enable the transitions to proceed, the two type_transition statements had different 'default' types (or target domains), that breaks the type enforcement rule.<br />
<br />
It was decided to resolve this by:<br />
<br />
1) Keeping the type_transition rule for the 'default' type of ext_gateway_t and allow the secure server process to be exec'd from unconfined_t as shown in the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/7-domain-transition.png domain transition] diagram, by simply running the command from the prompt as follows:<br />
<pre><br />
# Run the external gateway 'secure server' application on port 9999 and<br />
# let the policy transition the process to the ext_gateway_t domain:<br />
<br />
secure_server 99999<br />
</pre><br />
<br />
2) Use the SELinux '''runcon'''(1) command to ensure that the internal gateway runs in the correct domain by running runcon from the prompt as follows:<br />
<pre><br />
# Run the internal gateway 'secure server' application on port 1111 and<br />
# use runcon to transition the process to the int_gateway_t domain:<br />
<br />
runcon -t int_gateway_t -r message_filter_r secure_server 1111<br />
<br />
# Note - The role is required as a role transition is defined in the policy.<br />
</pre><br />
<br />
The runcon command makes use of a number of libselinux API functions to check the current context and set up the new context (for example '''getfilecon'''(3) is used to get the executable files context and '''setexeccon'''(3) is used to set the new process context). If all contexts are correct, then the '''execvp'''(2) system call is executed that exec's the secure_server application with the argument of '1111' into the int_gateway_t domain with the message_filter_r role. The runcon source can be found in the coreutils package.<br />
<br />
Other ways to resolve this issue are:<br />
<br />
# Use the runcon command for both gateways to transition to their respective domains. The type_transition statements are therefore not required.<br />
# Use different names for the secure server executable files and ensure they have a different type (i.e. instead of secure_service_exec_t label the external gateway ext_gateway_exec_t and the internal gateway int_gateway_exec_t. This would involve making a copy of the application binary (which has already been done as part of the module testing by calling the server 'server' and labeling it unconfined_t and then making a copy called secure_server and labeling it secure_services_exec_t).<br />
# Implement the policy using the Reference Policy utilising the template interface principles discussed in the [[NB_RefPolicy#template Macro |Reference Policy Template Macro]] section.<br />
<br />
It was decided to use runcon as it demonstrates the command usage better than reading the man pages.<br />
<br />
== Object Transition ==<br />
An object transition is where a new object requires a different label to that of its parent. For example a file is being created that requires a different label to that of its parent directory. This can be achieved automatically using a type_transition statement as follows: <br />
<pre><br />
type_transition ext_gateway_t in_queue_t:file in_file_t;<br />
</pre<br />
<br />
The following details an object transition used in the ext_gateway.conf loadable module (see the source tarball) where by default, files would be labeled in_queue_t when created by the gateway application as this is the label attached to the parent directory as shown:<br />
<pre><br />
ls -Za /usr/message_queue/in_queue<br />
drwxr-xr-x root root unconfined_u:object_r:in_queue_t .<br />
drwxr-xr-x root root system_u:object_r:unconfined_t ..<br />
</pre><br />
<br />
However the requirement is that files in the in_queue directory must be labeled in_file_t. To achieve this the files created must be relabeled to in_file_t by using a type_transition rule as follows:<br />
<pre><br />
# type_transition | source_domain | target_type : object | default_type;<br />
----------------- â–¼ --------------- â–¼ -------------------- â–¼ ---------------<br />
type_transition ext_gateway_t in_queue_t : file in_file_t;<br />
</pre><br />
<br />
This type_transition statement states that when a ''process'' running in the ''ext_gateway_t'' domain (the source domain) wants to create a ''file'' object in the directory that is labeled ''in_queue_t'', the file should be relabeled ''in_file_t'' if allowed by the policy (i.e. label the file ''in_file_t'').<br />
<br />
However as stated abov,e to be able to create the file, the following minimum permissions need to be granted in the policy using allow rules, where:<br />
<pre><br />
# The source domain needs permission to add file entries into the directory:<br />
allow ext_gateway_t in_queue_t : dir { write search add_name };<br />
<br />
# The source domain needs permission to create file entries:<br />
allow ext_gateway_t in_file_t : file { write create getattr };<br />
<br />
# The policy can then ensure (via the SELinux kernel services) that files created in the <tt>in_queue</tt> are relabeled:<br />
type_transition ext_gateway_t in_queue_t : file in_file_t;<br />
</pre><br />
<br />
An example output from a directory listing shows the resulting file labels:<br />
<pre><br />
ls -Za /usr/message_queue/in_queue<br />
drwxr-xr-x root root unconfined_u:object_r:in_queue_t .<br />
drwxr-xr-x root root system_u:object_r:unconfined_t ..<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t Message-1<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t Message-2<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_ComputingAccessDecisions | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_MLS | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_ObjectsNB Objects2015-09-25T13:36:54Z<p>RichardHaines: /* Allowing a Process Access to Resources */</p>
<hr />
<div>= Objects =<br />
Within SELinux an object is a resource such as files, sockets, pipes or network interfaces that are accessed via processes (also known as subjects). These objects are classified according to the resource they provide with access permissions relevant to their purpose (e.g. read, receive and write), and assigned a [[NB_SC | security context]] as described in the following sections.<br />
<br />
<br />
== Object Classes and Permissions ==<br />
Each object consists of a class identifier that defines its purpose (e.g. <tt>file</tt>, <tt>socket</tt>) along with a set of permissions<ref name="ftn5"><sup>Also known in SELinux as Access Vectors (AV).</sup></ref> that describe what services the object can handle (<tt>read</tt>, <tt>write</tt>, <tt>send</tt> etc.). When an object is instantiated it will be allocated a name (e.g. a file could be called config or a socket my_connection) and a security context (e.g. <tt>system_u:object_r:selinux_config_t</tt>) as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/5-object-class.png Object Class 'file' and permissions] diagram.<br />
<br />
The objective of the policy is to enable the user of the object (the subject) access to the minimum permissions needed to complete the task (i.e. do not allow write permission if only reading information).<br />
<br />
These object classes and their associated permissions are built into the GNU / Linux kernel and user space object managers by developers and are therefore not generally updated by policy writers. <br />
<br />
The object classes consist of kernel object classes (for handling files, sockets etc.) plus userspace object classes for userspace object managers (for services such as X-Windows or dbus). The number of object classes and their permissions can vary depending on the features configured in the GNU / Linux release. All the known object classes and permissions are described in [[NB_ObjectClassesPermissions | Object Classes and Permissions]].<br />
<br />
== Allowing a Process Access to Resources ==<br />
This is a simple example that attempts to explain two points:<br />
<br />
# How a process is given permission to use an objects resource.<br />
# By using the 'process' object class, show that a process can be described as a process or object.<br />
<br />
An SELinux policy contains many rules and statements, the majority of which are [[AVCRules#allow | allow]] rules that (simply) allows processes to be given access permissions to an objects resources.<br />
<br />
The following allow rule and [http://selinuxproject.org/~rhaines/NB4-diagrams/6-allow-rule.png "The allow rule"] diagram illustrates 'a process can also be an object' as it allows processes running in the unconfined_t domain, permission to 'transition' the external gateway application to the ext_gateway_t domain once it has been executed:<br />
<pre><br />
allow Rule | source_domain | target_type : class | permission<br />
-----------â–¼---------------â–¼--------------------------â–¼------------<br />
allow unconfined_t ext_gateway_t : process transition;<br />
</pre><br />
<br />
'''Where:'''<br />
{| border="1"<br />
| <tt>allow</tt><br />
| The SELinux language <tt>allow rule.<br />
<br />
|-<br />
| <tt>unconfined_t</tt><br />
| The source domain (or subject) identifier - in this case the shell that wants to exec the gateway application.<br />
<br />
|-<br />
| <tt>ext_gateway_t</tt><br />
| The target object identifier - the object instance of the gateway application process. <br />
<br />
|-<br />
| <tt>process</tt><br />
| The target object class - the <tt>process</tt> object class.<br />
<br />
|-<br />
| <tt>transition</tt><br />
| The permission granted to the source domain on the targets object - in this case the <tt>unconfined_t</tt> domain has <tt>transition</tt> permission on the <tt>ext_gateway_t</tt> <tt>process</tt> object.<br />
<br />
|}<br />
<br />
<br />
It should be noted that there is more to a domain transition than described above, for a more detailed explanation, see the [[NB_Domain_and_Object_Transitions#Domain_Transition | Domain Transition]] section.<br />
<br />
== Labeling Objects ==<br />
Within a running SELinux enabled GNU / Linux system the labeling of objects is managed by the system and generally unseen by the users (until labeling goes wrong !!). As processes and objects are created and destroyed, they either:<br />
<br />
# Inherit their labels from the parent process or object.<br />
# The policy type, role and range transition statements allow a different label to be assigned as discussed in the [[NB_Domain_and_Object_Transitions | Domain and Object Transitions]] section.<br />
# SELinux-aware applications can enforce a new label (with the policies approval of course) using the libselinux API functions.<br />
# An object manager (OM) can enforce a default label that can either be built into the OM or obtained via a configuration file (such as [[NB_XWIN#The x_contexts File | X-Windows]]).<br />
# Use an '[[PolicyLanguage#sid | initial security identifier]]' (or initial SID). These are defined in all base and monolithic policies and are used to either set an initial context during the boot process, or if an object requires a default (i.e. the object does not already have a valid context).<br />
<br />
The [[NB_ComputingSecurityContexts | Computing Security Contexts]] section gives detail on how some of the kernel based objects are computed.<br />
<br />
The SELinux policy language supports object labeling statements for file and network services that are defined in the [[PolicyLanguage#_File_System_Labeling_Statements | File System Labeling Statements]] and [[PolicyLanguage#Network_Labeling_Statements | Network Labeling Statements]] sections.<br />
<br />
An overview of the process required for labeling file systems that use extended attributes (such as <tt>ext3</tt> and <tt>ext4</tt>) is discussed in the [[NB_Objects#Labeling_Extended_Attribute_Filesystems | Labeling Extended Attribute Filesystems]] section. <br />
<br />
<br />
=== Labeling Extended Attribute Filesystems ===<br />
The labeling of file systems that implement extended attributes<ref name="ftn6"><sup>These file systems store the security context in an attribute associated with the file.</sup></ref> is supported by SELinux using:<br />
<br />
# The [[KernelPolicyLanguage#fs_use_xattr | fs_use_xattr]] statement within the policy to identify what file systems use extended attributes. This statement is used to inform the security server how to label the filesystem.<br />
# A 'file contexts' file that defines what the initial contexts should be for each file and directory within the filesystem. The format of this file is described in the [[PolicyStoreConfigurationFiles#/modules/active/file_contexts.template_File | modules/active/file_contexts.template File]]<ref name="ftn7"><sup>Note that this file contains the contexts of all files in all extended attribute filesystems for the policy. However within a modular policy each module describes its own file context information, that is then used to build this file.</sup></ref> section.<br />
# A method to initialise the filesystem with these extended attributes. This is achieved by SELinux utilities such as '''<tt>fixfiles</tt>'''<tt>(8)</tt> and '''<tt>setfiles</tt>'''<tt>(8)</tt>. There are also commands such as '''<tt>chcon</tt>'''<tt>(1)</tt>, '''<tt>restorecon</tt>'''<tt>(8)</tt> and '''<tt>restorecond</tt>'''<tt>(8)</tt> that can be used to relabel files.<br />
<br />
Extended attributes containing the SELinux context of a file can be viewed by the ls -Z or '''<tt>getfattr</tt?'''<tt>(1)</tt> commands as follows:<br />
<pre><br />
ls -Z myfile<br />
-rw-r--r-- root root unconfined_u:object_r:admin_home_t:s0 myfile<br />
</pre><br />
<pre><br />
getfattr -n security.selinux myfile<br />
#file_name: myfile<br />
security.selinux="unconfined_u:object_r:user_home:s0<br />
<br />
# Where -n security.selinux is the name of the extended attribute and<br />
# 'myfile' is the file name.<br />
# The security context (or label) held for the file is displayed.<br />
</pre><br />
<br />
==== Copying and Moving Files ====<br />
Assuming that the correct permissions have been granted by the policy, the effects on the security context of a file when copied or moved differ as follows:<br />
<br />
* copy a file - takes on label of new directory unless the -Z option is used.<br />
* move a file - retains the label of the file.<br />
<br />
However, if the restorecond daemon is running and the [[PolicyConfigurationFiles#_/etc/selinux/restorecond.conf_File | restorecond.conf]] file is correctly configured, then other security contexts can be associated to the file as it is moved or copied (provided it is a valid context and specified in the [[PolicyConfigurationFiles#_./contexts/files/file_contexts_File | file_contexts]] file).<br />
<br />
The examples below show the effects of copying and moving files:<br />
<pre><br />
# These are the test files in the /root directory and their current security</nowiki><br />
# context:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t moved-file<br />
<br />
# These are the commands used to copy / move the files:<br />
#<br />
# Standard copy file:<br />
cp copied-file /usr/message_queue/in_queue<br />
<br />
# Copy using -Z to set the files context:<br />
cp -Z unconfined_u:object_r:unconfined_t copied-file \ /usr/message_queue/in_queue/copied-file-with-Z<br />
<br />
# Standard move file:<br />
mv moved-file /usr/message_queue/in_queue<br />
<br />
# The target directory (/usr/message_queue/in_queue) is label "in_queue_t".<br />
# The results of "ls -Z" on target the directory are:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:in_queue_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t copied-file-with-Z<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t moved-file<br />
</pre><br />
However, if the restorecond daemon is running:<br />
<pre><br />
# If the restorecond daemon is running with a restorecond.conf file entry of:<br />
#<br />
/usr/message_queue/in_queue/*<br />
<br />
# AND the file_context file has an entry of:<br />
#<br />
/usr/message_queue/in_queue(/.*)? -- system_u:object_r:in_file_t<br />
# Then all the entries would be set as follows when the daemon detects the files<br />
# creation:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t copied-file-with-Z<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t moved-file<br />
<br />
# This is because the restorecond process will set the contexts defined in <br />
# the file_contexts file to the context specified as it is created in the <br />
# new directory.<br />
</pre><br />
This is because the restorecond process will set the contexts defined in the file_contexts file to the context specified as it is created in the new directory.<br />
<br />
<br />
=== Labeling Subjects ===<br />
On a running GNU / Linux system, processes inherit the security context of the parent process. If the new process being spawned has permission to change its context, then a 'type transition' is allowed that is discussed in the [[NB_Domain_and_Object_Transitions#Domain_Transition | Domain Transition]] section.<br />
<br />
The policy language supports a number of statements to assign components to security contexts such as:<br />
: <tt>user</tt>, <tt>role</tt> and <tt>type</tt> statements.<br />
<br />
and manage their scope:<br />
: <tt>role_allow</tt> and <tt>constrain</tt><br />
<br />
and manage their transition:<br />
: <tt>type_transition</tt>, <tt>role_transition</tt> and <tt>range_transition</tt><br />
<br />
<br />
== Object Reuse ==<br />
As GNU / Linux runs it creates instances of objects and manages the information they contain (read, write, modify etc.) under the control of processes, and at some stage these objects may be deleted or released allowing the resource (such as memory blocks and disk space) to be available for reuse.<br />
<br />
GNU / Linux handles object reuse by ensuring that when a resource is re-allocated it is cleared. This means that when a process releases an object instance (e.g. release allocated memory back to the pool, delete a directory entry or file), there may be information left behind that could prove useful if harvested. If this should be an issue, then the process itself should clear or shred the information before releasing the object (which can be difficult in some cases unless the source code is available).<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Subjects | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_ComputingSecurityContexts | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_ObjectsNB Objects2015-09-25T13:35:05Z<p>RichardHaines: /* Object Classes and Permissions */</p>
<hr />
<div>= Objects =<br />
Within SELinux an object is a resource such as files, sockets, pipes or network interfaces that are accessed via processes (also known as subjects). These objects are classified according to the resource they provide with access permissions relevant to their purpose (e.g. read, receive and write), and assigned a [[NB_SC | security context]] as described in the following sections.<br />
<br />
<br />
== Object Classes and Permissions ==<br />
Each object consists of a class identifier that defines its purpose (e.g. <tt>file</tt>, <tt>socket</tt>) along with a set of permissions<ref name="ftn5"><sup>Also known in SELinux as Access Vectors (AV).</sup></ref> that describe what services the object can handle (<tt>read</tt>, <tt>write</tt>, <tt>send</tt> etc.). When an object is instantiated it will be allocated a name (e.g. a file could be called config or a socket my_connection) and a security context (e.g. <tt>system_u:object_r:selinux_config_t</tt>) as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/5-object-class.png Object Class 'file' and permissions] diagram.<br />
<br />
The objective of the policy is to enable the user of the object (the subject) access to the minimum permissions needed to complete the task (i.e. do not allow write permission if only reading information).<br />
<br />
These object classes and their associated permissions are built into the GNU / Linux kernel and user space object managers by developers and are therefore not generally updated by policy writers. <br />
<br />
The object classes consist of kernel object classes (for handling files, sockets etc.) plus userspace object classes for userspace object managers (for services such as X-Windows or dbus). The number of object classes and their permissions can vary depending on the features configured in the GNU / Linux release. All the known object classes and permissions are described in [[NB_ObjectClassesPermissions | Object Classes and Permissions]].<br />
<br />
== Allowing a Process Access to Resources ==<br />
This is a simple example that attempts to explain two points:<br />
<br />
# How a process is given permission to use an objects resource.<br />
# By using the 'process' object class, show that a process can be described as a process or object.<br />
<br />
An SELinux policy contains many rules and statements, the majority of which are [[AVCRules#allow | allow]] rules that (simply) allows processes to be given access permissions to an objects resources.<br />
<br />
The following allow rule and [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/6-allow-rule.png "The allow rule"] diagram illustrates 'a process can also be an object' as it allows processes running in the unconfined_t domain, permission to 'transition' the external gateway application to the ext_gateway_t domain once it has been executed:<br />
<pre><br />
allow Rule | source_domain | target_type : class | permission<br />
-----------â–¼---------------â–¼--------------------------â–¼------------<br />
allow unconfined_t ext_gateway_t : process transition;<br />
</pre><br />
<br />
'''Where:'''<br />
{| border="1"<br />
| <tt>allow</tt><br />
| The SELinux language <tt>allow rule.<br />
<br />
|-<br />
| <tt>unconfined_t</tt><br />
| The source domain (or subject) identifier - in this case the shell that wants to exec the gateway application.<br />
<br />
|-<br />
| <tt>ext_gateway_t</tt><br />
| The target object identifier - the object instance of the gateway application process. <br />
<br />
|-<br />
| <tt>process</tt><br />
| The target object class - the <tt>process</tt> object class.<br />
<br />
|-<br />
| <tt>transition</tt><br />
| The permission granted to the source domain on the targets object - in this case the <tt>unconfined_t</tt> domain has <tt>transition</tt> permission on the <tt>ext_gateway_t</tt> <tt>process</tt> object.<br />
<br />
|}<br />
<br />
<br />
It should be noted that there is more to a domain transition than described above, for a more detailed explanation, see the [[NB_Domain_and_Object_Transitions#Domain_Transition | Domain Transition]] section.<br />
<br />
<br />
== Labeling Objects ==<br />
Within a running SELinux enabled GNU / Linux system the labeling of objects is managed by the system and generally unseen by the users (until labeling goes wrong !!). As processes and objects are created and destroyed, they either:<br />
<br />
# Inherit their labels from the parent process or object.<br />
# The policy type, role and range transition statements allow a different label to be assigned as discussed in the [[NB_Domain_and_Object_Transitions | Domain and Object Transitions]] section.<br />
# SELinux-aware applications can enforce a new label (with the policies approval of course) using the libselinux API functions.<br />
# An object manager (OM) can enforce a default label that can either be built into the OM or obtained via a configuration file (such as [[NB_XWIN#The x_contexts File | X-Windows]]).<br />
# Use an '[[PolicyLanguage#sid | initial security identifier]]' (or initial SID). These are defined in all base and monolithic policies and are used to either set an initial context during the boot process, or if an object requires a default (i.e. the object does not already have a valid context).<br />
<br />
The [[NB_ComputingSecurityContexts | Computing Security Contexts]] section gives detail on how some of the kernel based objects are computed.<br />
<br />
The SELinux policy language supports object labeling statements for file and network services that are defined in the [[PolicyLanguage#_File_System_Labeling_Statements | File System Labeling Statements]] and [[PolicyLanguage#Network_Labeling_Statements | Network Labeling Statements]] sections.<br />
<br />
An overview of the process required for labeling file systems that use extended attributes (such as <tt>ext3</tt> and <tt>ext4</tt>) is discussed in the [[NB_Objects#Labeling_Extended_Attribute_Filesystems | Labeling Extended Attribute Filesystems]] section. <br />
<br />
<br />
=== Labeling Extended Attribute Filesystems ===<br />
The labeling of file systems that implement extended attributes<ref name="ftn6"><sup>These file systems store the security context in an attribute associated with the file.</sup></ref> is supported by SELinux using:<br />
<br />
# The [[KernelPolicyLanguage#fs_use_xattr | fs_use_xattr]] statement within the policy to identify what file systems use extended attributes. This statement is used to inform the security server how to label the filesystem.<br />
# A 'file contexts' file that defines what the initial contexts should be for each file and directory within the filesystem. The format of this file is described in the [[PolicyStoreConfigurationFiles#/modules/active/file_contexts.template_File | modules/active/file_contexts.template File]]<ref name="ftn7"><sup>Note that this file contains the contexts of all files in all extended attribute filesystems for the policy. However within a modular policy each module describes its own file context information, that is then used to build this file.</sup></ref> section.<br />
# A method to initialise the filesystem with these extended attributes. This is achieved by SELinux utilities such as '''<tt>fixfiles</tt>'''<tt>(8)</tt> and '''<tt>setfiles</tt>'''<tt>(8)</tt>. There are also commands such as '''<tt>chcon</tt>'''<tt>(1)</tt>, '''<tt>restorecon</tt>'''<tt>(8)</tt> and '''<tt>restorecond</tt>'''<tt>(8)</tt> that can be used to relabel files.<br />
<br />
Extended attributes containing the SELinux context of a file can be viewed by the ls -Z or '''<tt>getfattr</tt?'''<tt>(1)</tt> commands as follows:<br />
<pre><br />
ls -Z myfile<br />
-rw-r--r-- root root unconfined_u:object_r:admin_home_t:s0 myfile<br />
</pre><br />
<pre><br />
getfattr -n security.selinux myfile<br />
#file_name: myfile<br />
security.selinux="unconfined_u:object_r:user_home:s0<br />
<br />
# Where -n security.selinux is the name of the extended attribute and<br />
# 'myfile' is the file name.<br />
# The security context (or label) held for the file is displayed.<br />
</pre><br />
<br />
==== Copying and Moving Files ====<br />
Assuming that the correct permissions have been granted by the policy, the effects on the security context of a file when copied or moved differ as follows:<br />
<br />
* copy a file - takes on label of new directory unless the -Z option is used.<br />
* move a file - retains the label of the file.<br />
<br />
However, if the restorecond daemon is running and the [[PolicyConfigurationFiles#_/etc/selinux/restorecond.conf_File | restorecond.conf]] file is correctly configured, then other security contexts can be associated to the file as it is moved or copied (provided it is a valid context and specified in the [[PolicyConfigurationFiles#_./contexts/files/file_contexts_File | file_contexts]] file).<br />
<br />
The examples below show the effects of copying and moving files:<br />
<pre><br />
# These are the test files in the /root directory and their current security</nowiki><br />
# context:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t moved-file<br />
<br />
# These are the commands used to copy / move the files:<br />
#<br />
# Standard copy file:<br />
cp copied-file /usr/message_queue/in_queue<br />
<br />
# Copy using -Z to set the files context:<br />
cp -Z unconfined_u:object_r:unconfined_t copied-file \ /usr/message_queue/in_queue/copied-file-with-Z<br />
<br />
# Standard move file:<br />
mv moved-file /usr/message_queue/in_queue<br />
<br />
# The target directory (/usr/message_queue/in_queue) is label "in_queue_t".<br />
# The results of "ls -Z" on target the directory are:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:in_queue_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t copied-file-with-Z<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t moved-file<br />
</pre><br />
However, if the restorecond daemon is running:<br />
<pre><br />
# If the restorecond daemon is running with a restorecond.conf file entry of:<br />
#<br />
/usr/message_queue/in_queue/*<br />
<br />
# AND the file_context file has an entry of:<br />
#<br />
/usr/message_queue/in_queue(/.*)? -- system_u:object_r:in_file_t<br />
# Then all the entries would be set as follows when the daemon detects the files<br />
# creation:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t copied-file-with-Z<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t moved-file<br />
<br />
# This is because the restorecond process will set the contexts defined in <br />
# the file_contexts file to the context specified as it is created in the <br />
# new directory.<br />
</pre><br />
This is because the restorecond process will set the contexts defined in the file_contexts file to the context specified as it is created in the new directory.<br />
<br />
<br />
=== Labeling Subjects ===<br />
On a running GNU / Linux system, processes inherit the security context of the parent process. If the new process being spawned has permission to change its context, then a 'type transition' is allowed that is discussed in the [[NB_Domain_and_Object_Transitions#Domain_Transition | Domain Transition]] section.<br />
<br />
The policy language supports a number of statements to assign components to security contexts such as:<br />
: <tt>user</tt>, <tt>role</tt> and <tt>type</tt> statements.<br />
<br />
and manage their scope:<br />
: <tt>role_allow</tt> and <tt>constrain</tt><br />
<br />
and manage their transition:<br />
: <tt>type_transition</tt>, <tt>role_transition</tt> and <tt>range_transition</tt><br />
<br />
<br />
== Object Reuse ==<br />
As GNU / Linux runs it creates instances of objects and manages the information they contain (read, write, modify etc.) under the control of processes, and at some stage these objects may be deleted or released allowing the resource (such as memory blocks and disk space) to be available for reuse.<br />
<br />
GNU / Linux handles object reuse by ensuring that when a resource is re-allocated it is cleared. This means that when a process releases an object instance (e.g. release allocated memory back to the pool, delete a directory entry or file), there may be information left behind that could prove useful if harvested. If this should be an issue, then the process itself should clear or shred the information before releasing the object (which can be difficult in some cases unless the source code is available).<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Subjects | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_ComputingSecurityContexts | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_ObjectsNB Objects2015-09-25T13:32:14Z<p>RichardHaines: /* Object Classes and Permissions */</p>
<hr />
<div>= Objects =<br />
Within SELinux an object is a resource such as files, sockets, pipes or network interfaces that are accessed via processes (also known as subjects). These objects are classified according to the resource they provide with access permissions relevant to their purpose (e.g. read, receive and write), and assigned a [[NB_SC | security context]] as described in the following sections.<br />
<br />
<br />
== Object Classes and Permissions ==<br />
Each object consists of a class identifier that defines its purpose (e.g. <tt>file</tt>, <tt>socket</tt>) along with a set of permissions<ref name="ftn5"><sup>Also known in SELinux as Access Vectors (AV).</sup></ref> that describe what services the object can handle (<tt>read</tt>, <tt>write</tt>, <tt>send</tt> etc.). When an object is instantiated it will be allocated a name (e.g. a file could be called config or a socket my_connection) and a security context (e.g. <tt>system_u:object_r:selinux_config_t</tt>) as shown in the [http://selinuxproject.org/~rhaines/Notebook-4/NB_5-object-class.png Object Class 'file' and permissions] diagram.<br />
<br />
The objective of the policy is to enable the user of the object (the subject) access to the minimum permissions needed to complete the task (i.e. do not allow write permission if only reading information).<br />
<br />
These object classes and their associated permissions are built into the GNU / Linux kernel and user space object managers by developers and are therefore not generally updated by policy writers. <br />
<br />
The object classes consist of kernel object classes (for handling files, sockets etc.) plus userspace object classes for userspace object managers (for services such as X-Windows or dbus). The number of object classes and their permissions can vary depending on the features configured in the GNU / Linux release. All the known object classes and permissions are described in [[NB_ObjectClassesPermissions | Object Classes and Permissions]].<br />
<br />
== Allowing a Process Access to Resources ==<br />
This is a simple example that attempts to explain two points:<br />
<br />
# How a process is given permission to use an objects resource.<br />
# By using the 'process' object class, show that a process can be described as a process or object.<br />
<br />
An SELinux policy contains many rules and statements, the majority of which are [[AVCRules#allow | allow]] rules that (simply) allows processes to be given access permissions to an objects resources.<br />
<br />
The following allow rule and [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/6-allow-rule.png "The allow rule"] diagram illustrates 'a process can also be an object' as it allows processes running in the unconfined_t domain, permission to 'transition' the external gateway application to the ext_gateway_t domain once it has been executed:<br />
<pre><br />
allow Rule | source_domain | target_type : class | permission<br />
-----------â–¼---------------â–¼--------------------------â–¼------------<br />
allow unconfined_t ext_gateway_t : process transition;<br />
</pre><br />
<br />
'''Where:'''<br />
{| border="1"<br />
| <tt>allow</tt><br />
| The SELinux language <tt>allow rule.<br />
<br />
|-<br />
| <tt>unconfined_t</tt><br />
| The source domain (or subject) identifier - in this case the shell that wants to exec the gateway application.<br />
<br />
|-<br />
| <tt>ext_gateway_t</tt><br />
| The target object identifier - the object instance of the gateway application process. <br />
<br />
|-<br />
| <tt>process</tt><br />
| The target object class - the <tt>process</tt> object class.<br />
<br />
|-<br />
| <tt>transition</tt><br />
| The permission granted to the source domain on the targets object - in this case the <tt>unconfined_t</tt> domain has <tt>transition</tt> permission on the <tt>ext_gateway_t</tt> <tt>process</tt> object.<br />
<br />
|}<br />
<br />
<br />
It should be noted that there is more to a domain transition than described above, for a more detailed explanation, see the [[NB_Domain_and_Object_Transitions#Domain_Transition | Domain Transition]] section.<br />
<br />
<br />
== Labeling Objects ==<br />
Within a running SELinux enabled GNU / Linux system the labeling of objects is managed by the system and generally unseen by the users (until labeling goes wrong !!). As processes and objects are created and destroyed, they either:<br />
<br />
# Inherit their labels from the parent process or object.<br />
# The policy type, role and range transition statements allow a different label to be assigned as discussed in the [[NB_Domain_and_Object_Transitions | Domain and Object Transitions]] section.<br />
# SELinux-aware applications can enforce a new label (with the policies approval of course) using the libselinux API functions.<br />
# An object manager (OM) can enforce a default label that can either be built into the OM or obtained via a configuration file (such as [[NB_XWIN#The x_contexts File | X-Windows]]).<br />
# Use an '[[PolicyLanguage#sid | initial security identifier]]' (or initial SID). These are defined in all base and monolithic policies and are used to either set an initial context during the boot process, or if an object requires a default (i.e. the object does not already have a valid context).<br />
<br />
The [[NB_ComputingSecurityContexts | Computing Security Contexts]] section gives detail on how some of the kernel based objects are computed.<br />
<br />
The SELinux policy language supports object labeling statements for file and network services that are defined in the [[PolicyLanguage#_File_System_Labeling_Statements | File System Labeling Statements]] and [[PolicyLanguage#Network_Labeling_Statements | Network Labeling Statements]] sections.<br />
<br />
An overview of the process required for labeling file systems that use extended attributes (such as <tt>ext3</tt> and <tt>ext4</tt>) is discussed in the [[NB_Objects#Labeling_Extended_Attribute_Filesystems | Labeling Extended Attribute Filesystems]] section. <br />
<br />
<br />
=== Labeling Extended Attribute Filesystems ===<br />
The labeling of file systems that implement extended attributes<ref name="ftn6"><sup>These file systems store the security context in an attribute associated with the file.</sup></ref> is supported by SELinux using:<br />
<br />
# The [[KernelPolicyLanguage#fs_use_xattr | fs_use_xattr]] statement within the policy to identify what file systems use extended attributes. This statement is used to inform the security server how to label the filesystem.<br />
# A 'file contexts' file that defines what the initial contexts should be for each file and directory within the filesystem. The format of this file is described in the [[PolicyStoreConfigurationFiles#/modules/active/file_contexts.template_File | modules/active/file_contexts.template File]]<ref name="ftn7"><sup>Note that this file contains the contexts of all files in all extended attribute filesystems for the policy. However within a modular policy each module describes its own file context information, that is then used to build this file.</sup></ref> section.<br />
# A method to initialise the filesystem with these extended attributes. This is achieved by SELinux utilities such as '''<tt>fixfiles</tt>'''<tt>(8)</tt> and '''<tt>setfiles</tt>'''<tt>(8)</tt>. There are also commands such as '''<tt>chcon</tt>'''<tt>(1)</tt>, '''<tt>restorecon</tt>'''<tt>(8)</tt> and '''<tt>restorecond</tt>'''<tt>(8)</tt> that can be used to relabel files.<br />
<br />
Extended attributes containing the SELinux context of a file can be viewed by the ls -Z or '''<tt>getfattr</tt?'''<tt>(1)</tt> commands as follows:<br />
<pre><br />
ls -Z myfile<br />
-rw-r--r-- root root unconfined_u:object_r:admin_home_t:s0 myfile<br />
</pre><br />
<pre><br />
getfattr -n security.selinux myfile<br />
#file_name: myfile<br />
security.selinux="unconfined_u:object_r:user_home:s0<br />
<br />
# Where -n security.selinux is the name of the extended attribute and<br />
# 'myfile' is the file name.<br />
# The security context (or label) held for the file is displayed.<br />
</pre><br />
<br />
==== Copying and Moving Files ====<br />
Assuming that the correct permissions have been granted by the policy, the effects on the security context of a file when copied or moved differ as follows:<br />
<br />
* copy a file - takes on label of new directory unless the -Z option is used.<br />
* move a file - retains the label of the file.<br />
<br />
However, if the restorecond daemon is running and the [[PolicyConfigurationFiles#_/etc/selinux/restorecond.conf_File | restorecond.conf]] file is correctly configured, then other security contexts can be associated to the file as it is moved or copied (provided it is a valid context and specified in the [[PolicyConfigurationFiles#_./contexts/files/file_contexts_File | file_contexts]] file).<br />
<br />
The examples below show the effects of copying and moving files:<br />
<pre><br />
# These are the test files in the /root directory and their current security</nowiki><br />
# context:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t moved-file<br />
<br />
# These are the commands used to copy / move the files:<br />
#<br />
# Standard copy file:<br />
cp copied-file /usr/message_queue/in_queue<br />
<br />
# Copy using -Z to set the files context:<br />
cp -Z unconfined_u:object_r:unconfined_t copied-file \ /usr/message_queue/in_queue/copied-file-with-Z<br />
<br />
# Standard move file:<br />
mv moved-file /usr/message_queue/in_queue<br />
<br />
# The target directory (/usr/message_queue/in_queue) is label "in_queue_t".<br />
# The results of "ls -Z" on target the directory are:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:in_queue_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t copied-file-with-Z<br />
-rw-r--r-- root root unconfined_u:object_r:unconfined_t moved-file<br />
</pre><br />
However, if the restorecond daemon is running:<br />
<pre><br />
# If the restorecond daemon is running with a restorecond.conf file entry of:<br />
#<br />
/usr/message_queue/in_queue/*<br />
<br />
# AND the file_context file has an entry of:<br />
#<br />
/usr/message_queue/in_queue(/.*)? -- system_u:object_r:in_file_t<br />
# Then all the entries would be set as follows when the daemon detects the files<br />
# creation:<br />
#<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t copied-file<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t copied-file-with-Z<br />
-rw-r--r-- root root unconfined_u:object_r:in_file_t moved-file<br />
<br />
# This is because the restorecond process will set the contexts defined in <br />
# the file_contexts file to the context specified as it is created in the <br />
# new directory.<br />
</pre><br />
This is because the restorecond process will set the contexts defined in the file_contexts file to the context specified as it is created in the new directory.<br />
<br />
<br />
=== Labeling Subjects ===<br />
On a running GNU / Linux system, processes inherit the security context of the parent process. If the new process being spawned has permission to change its context, then a 'type transition' is allowed that is discussed in the [[NB_Domain_and_Object_Transitions#Domain_Transition | Domain Transition]] section.<br />
<br />
The policy language supports a number of statements to assign components to security contexts such as:<br />
: <tt>user</tt>, <tt>role</tt> and <tt>type</tt> statements.<br />
<br />
and manage their scope:<br />
: <tt>role_allow</tt> and <tt>constrain</tt><br />
<br />
and manage their transition:<br />
: <tt>type_transition</tt>, <tt>role_transition</tt> and <tt>range_transition</tt><br />
<br />
<br />
== Object Reuse ==<br />
As GNU / Linux runs it creates instances of objects and manages the information they contain (read, write, modify etc.) under the control of processes, and at some stage these objects may be deleted or released allowing the resource (such as memory blocks and disk space) to be available for reuse.<br />
<br />
GNU / Linux handles object reuse by ensuring that when a resource is re-allocated it is cleared. This means that when a process releases an object instance (e.g. release allocated memory back to the pool, delete a directory entry or file), there may be information left behind that could prove useful if harvested. If this should be an issue, then the process itself should clear or shred the information before releasing the object (which can be difficult in some cases unless the source code is available).<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Subjects | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_ComputingSecurityContexts | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_TENB TE2015-09-25T13:30:31Z<p>RichardHaines: /* Type Enforcement (TE) */</p>
<hr />
<div>''See Also: [[TypeEnforcement]]''<br />
<br />
= Type Enforcement (TE) =<br />
SELinux makes use of a specific style of type enforcement<ref name="ftn2"><sup>There are various 'type enforcement' technologies. </sup></ref> (TE) to enforce mandatory access control. For SELinux it means that all [[NB_Subjects | subjects]] and [[NB_Objects | objects]] have a type identifier associated to them that can then be used to enforce rules laid down by policy. <br />
<br />
The SELinux type identifier is a simple variable-length string that is defined in the policy and then associated to a [[NB_SC | security context]]. It is also used in the majority of [[PolicyLanguage#Kernel_Policy_Language | SELinux language statements and rules]] used to build a policy that will, when loaded into the security server, enforce policy via the object managers.<br />
<br />
Because the type identifier (or just 'type') is associated to all subjects and objects, it can sometimes be difficult to distinguish what the type is actually associated with (it's not helped by the fact that by convention, type identifiers end in <tt>'_t'</tt>). In the end it comes down to understanding how they are allocated in the policy itself and how they are used by SELinux services (although CIL policies with namespaces do help in that a domain process 'type' could be declared as <tt>msg_filter.ext_gateway.process</tt> with object types being any others (such as <tt>msg_filter.ext_gateway.exec</tt>). <br />
<br />
Basically if the type identifier is used to reference a subject it is referring to a Linux process or collection of processes (a domain or domain type). If the type identifier is used to reference an object then it is specifying its object type (i.e. file type).<br />
<br />
While SELinux refers to a subject as being an active process that is associated to a domain type, the scope of an SELinux type enforcement domain can vary widely. For example in the simple policy built in the <tt>basic-selinux-policy</tt> directory of the source tarball, all the processes on the system run in the unconfined_t domain (or for the CIL version in the <tt>unconfined.process</tt> domain), therefore every process is 'of type unconfined_t' (that means it can do whatever it likes within the limits of the standard Linux DAC policy as all access is allowed by SELinux).<br />
<br />
It is only when additional policy statements are added to the simple policy that areas start to be confined. For example, an external gateway is run in its own isolated domain (ext_gateway_t) that cannot be 'interfered' with by any of the unconfined_t processes (except to run or transition the gateway process into its own domain). This scenario is similar to the 'targeted' policy delivered as standard in Red Hat Fedora where the majority of user space processes run under the unconfined_t domain (although don't think the simple policies implemented in source tarball are equivalent to the Reference Policy, they are not - so do not use them as live implementations).<br />
<br />
The SELinux type is the third component of a 'security context' and by convention SELinux types end in '<tt>_t</tt>', however this is not enforced by any SELinux service (i.e. it is only used to identify the type component), although as explained above CIL with namespaces does make identification of types easier.<br />
<br />
== Constraints ==<br />
It is possible to add constraints on users, roles, types and MLS ranges, for example within a TE environment, the way that subjects are allowed to access an object is via a TE [[AVCRules#allow | allow]] rule, for example:<br />
<pre><br />
allow unconfined_t ext_gateway_t : process transition;<br />
</pre><br />
<br />
This states that a process running in the unconfined_t domain has permission to transition a process to the ext_gateway_t domain. However it could be that the policy writer wants to constrain this further and state that this can only happen if the role of the source domain is the same as the role of the target domain. To achieve this a constraint can be imposed using a [[ConstraintStatements#constrain | constrain]] statement:<br />
<pre><br />
constrain process transition ( r1 == r2 );<br />
</pre><br />
<br />
This states that a process transition can only occur if the source role is the same as the target role, therefore a constraint is a condition that must be satisfied in order for one or more permissions to be granted (i.e. a constraint imposes additional restrictions on TE rules). Note that the constraint is based on an object class (<tt>process</tt> in this case) and one or more of its permissions.<br />
<br />
The kernel policy language constraints are defined in the [[ConstraintStatements | Constraint Statements]] section).<br />
<br />
== Bounds ==<br />
It is possible to add bounds to users, roles and types, however currently only types are enforced by the kernel using the [[Bounds_Rules#typebounds | typebounds]] rule as described in the [[NB_Apache#Bounds_Overview | Bounds Overview]] section (although user and role bounds may be declared using CIL, however they are validated at compile time).<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_RBAC | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_SC | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_RBACNB RBAC2015-09-25T13:04:09Z<p>RichardHaines: /* Role-Based Access Control (RBAC) */</p>
<hr />
<div>= Role-Based Access Control (RBAC) =<br />
To further control access to TE domains SELinux makes use of role-based access control (RBAC). This feature allows SELinux users to be associated to one or more roles, where each role is then associated to one or more domain types as shown in the [http://selinuxproject.org/~rhaines/NB4-diagrams/4-RBAC.png Role Based Access Control] diagram. <br />
<br />
The SELinux role name is the second component of a 'security context' and by convention SELinux roles end in '<tt>_r</tt>', however this is not enforced by any SELinux service (i.e. it is only used to identify the role component), although CIL with namespaces does make identification of a role easier for example a 'role' could be declared as <tt>unconfined.role</tt>.<br />
<br />
It is possible to add constraints and bounds on roles as discussed in the [[NB_TE | Type Enforcement]] section.<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_USERS | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_TE | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_CoreComponentsNB CoreComponents2015-09-25T12:58:00Z<p>RichardHaines: /* Core SELinux Components */</p>
<hr />
<div>= Core SELinux Components =<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/1-core.png High Level Core SELinux Components] diagram shows a high level view of the core SELinux components that manage enforcement of the policy and comprises of the following:<br />
<br />
# A [[NB_Subjects | subject]] that must be present to cause an action to be taken by an [[NB_Objects | object]] (such as read a file as information only flows when a subject is involved).<br />
# An Object Manager that knows the actions required of the particular resource (such as a file) and can enforce those actions (i.e. allow it to write to a file if permitted by the policy).<br />
# A Security Server that makes decisions regarding the subjects rights to perform the requested action on the object, based on the security policy rules.<br />
# A Security Policy that describes the rules using the SELinux [[PolicyLanguage | policy language]].<br />
# An Access Vector Cache (AVC) that improves system performance by caching security server decisions.<br />
<br />
Note that decisions by the Security Server are cached in the AVC to enhance performance of future requests, and that it is the kernel and userspace Object Managers that enforce the policy.<br />
<br />
The [http://arctic.selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows a more complex view of the kernel and userspace with a number of supporting services that are used to manage the SELinux environment. This diagram will be referenced a number of times to explain areas of SELinux, therefore starting from the bottom:<br />
<br />
* In the current implementation of SELinux the security server is embedded in the kernel with the policy being loaded from userspace via a series of functions contained in the libselinux library (see [[NB_Userspace_Libraries | SELinux Userspace Libraries]] for details).<br />
<br />
The object managers (OM) and access vector cache (AVC) can reside in:<br />
:: '''kernel space - '''These object manages are for the kernel services such as files, directory, socket, IPC etc. and are provided by hooks into the SELinux sub-system via the Linux Security Module (LSM) framework (shown as LSM Hooks in the [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram) that is discussed in the [[NB_LSM | Linux Security Module and SELinux]] section. The SELinux kernel AVC service is used to cache the security servers response to the kernel based object managers thus speeding up access decisions should the same request be asked in future.<br />
<br />
:: '''userspace''' - These object managers are provided with the application or service that requires support for MAC and are known as 'SELinux-aware' applications or services. Examples of these are: X-Windows, D-bus messaging (used by the Gnome desktop), PostgreSQL database, Name Service Cache Daemon (<tt>nscd</tt>), and the GNU / Linux passwd command. Generally, these OMs use the AVC services built into the SELinux library (libselinux), however they could, if required supply their own AVC or not use an AVC at all (see [[NB_Imp_SELinux-aware_Apps | Implementing SELinux-aware Applications]] for details). <br />
<br />
* The SELinux security policy (right hand side in the [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram) and its supporting configuration files are contained in the <tt>/etc/selinux</tt> directory. This directory contains the main SELinux configuration file (<tt>/etc/selinux/config</tt>) that has the name of the policy to be loaded (via the <tt>SELINUXTYPE</tt> entry) and the initial enforcement mode<ref name="ftn1"><sup>When SELinux is enabled, the policy can be running in 'permissive mode' (<tt>SELINUX=permissive</tt>), where all accesses are allowed. The policy can also be run in 'enforcing mode' (<tt>SELINUX=enforcing</tt>), where any access that is not defined in the policy is denied and an entry placed in the audit log. SELinux can also be disabled (at boot time only) by setting <tt>SELINUX=disabled</tt>. There is also support for the [[TypeStatements#permissive | permissive]] statement that allows a domain to run in permissive mode while the others are still confined (instead of the all or nothing set by <tt>SELINUX=</tt>).</sup></ref> of the policy at load time (via the <tt>SELINUX</tt> entry). The <tt>/etc/selinux/<nowiki><SELINUXTYPE></nowiki></tt> directories contain policies that can be activated along with their configuration files (e.g. '<tt>SELINUXTYPE=targeted</tt>' will have its policy and associated configuration files located at <tt>/etc/selinux/targeted</tt>). All known policy configuration files are shown in the [[PolicyConfigurationFiles | Policy Configuration Files]] section.<br />
<br />
* SELinux supports a 'modular policy', this means that a policy does not have to be one large source policy but can be built from modules. A modular policy consists of a base policy that contains the mandatory information (such as object classes, permissions etc.), and zero or more policy modules where generally each supports a particular application or service. These modules are compiled, linked, and held in a 'policy store' where they can be built into a binary format that is then loaded into the security server (in the [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram, the binary policy is located at <tt>/etc/selinux/targeted/policy/policy.29</tt>). The types of policy and their construction are covered in the [[NB_PolicyType | Types of SELinux Policy]] section.<br />
<br />
* To be able to build the policy in the first place, policy source is required (top left hand side of the [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram). This can be supplied in three basic ways: <br />
** as source code written using the [[PolicyLanguage#KernelPolicyLanguage | Kernel Policy Language]]. This is how the simple policies have been written to support the examples in this Notebook, however it is not recommended for large policy developments such as the [[NB_RefPolicy | Reference Policy]], although the smaller SE for Android policy is written this way with some m4 macro support.<br />
** using the [[NB_RefPolicy | Reference Policy]] that has high level macros to define policy rules. This is the standard way policies are now built for SELinux distributions such as Red Hat and Debian and is discussed in the [[NB_RefPolicy | Reference Policy]] section. Note that SE for Android also uses high level macros to define policy rules but the overall policy is much less complex.<br />
** using CIL (Common Intermediate Language). An overview can be found at [https://github.com/SELinuxProject/cil/wiki https://github.com/SELinuxProject/cil/wiki] and [[PolicyLanguage#CIL_Language | CIL Policy Language]].<br />
<br />
* To be able to compile and link the policy source then load it into the security server requires a number of tools (top of [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram).<br />
<br />
* To enable system administrators to manage policy, the SELinux environment and label file systems, tools and modified GNU / Linux commands are used. These are mentioned throughout the Notebook as needed. Note that there are many other applications to manage policy, however this Notebook only concentrates on the core services.<br />
<br />
* To ensure security events are logged, GNU / Linux has an audit service that captures policy violations. The [[NB_AL | Auditing SELinux Events]] section describes the format of these security events.<br />
<br />
* SELinux supports network services that are described in the [[NB_Networking | SELinux Networking Support]] section.<br />
<br />
The [[NB_LSM | Linux Security Module and SELinux]] section goes into greater detail of the LSM / SELinux modules with a walk-through of a <tt>fork</tt> and <tt>exec</tt> process.<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Overview | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_MAC | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_MACNB MAC2015-09-25T11:35:57Z<p>RichardHaines: /* Mandatory Access Control (MAC) */</p>
<hr />
<div>= Mandatory Access Control (MAC) =<br />
Mandatory Access Control (MAC) is a type of access control in which the operating system is used to constrain a user or process (the subject) from accessing or performing an operation on an object (such as a file, disk, memory etc.). <br />
<br />
Each of the subjects and objects have a set of security attributes that can be interrogated by the operating system to check if the requested operation can be performed or not. For SELinux the:<br />
<br />
* [[NB_Subjects | subjects]] are processes.<br />
* [[NB_Objects | objects]] are system resources such as files, sockets, etc.<br />
* security attributes are the [[NB_SC | security context]].<br />
* Security Server within the Linux kernel authorizes access (or not) using the security policy (or policy) that describes rules that must be enforced.<br />
<br />
Note that the subject (and therefore the user) cannot decide to bypass the policy rules being enforced by the MAC policy with SELinux enabled. Contrast this to standard Linux Discretionary Access Control (DAC), which also governs the ability of subjects to access objects, however it allows users to make policy decisions. The steps in the decision making chain for DAC and MAC are shown in the [http://arctic.selinuxproject.org/~rhaines/NB4-diagrams/3-processing-call.png Processing a System Call] diagram.<br />
<br />
SELinux supports two forms of MAC:<br />
<br />
# '''Type Enforcement''' - Where processes run in domains and the actions on objects are controlled by the policy. This is the implementation used for general purpose MAC within SELinux along with Role Based Access Control. The [[NB_TE | Type Enforcement]] and [[NB_RBAC | Role-Based Access Control (RBAC)]] sections covers these in more detail. <br />
#'''Multi-Level Security''' - This is an implementation based on the Bell-La Padula (BLP) model, and used by organizations where different levels of access are required so that restricted information is separated from classified information to maintain confidentiality. This allows enforcement rules such as 'no write down' and 'no read up' to be implemented in a policy by extending the security context to include security levels. The [[NB_MLS | Multi-Level Security and Multi-Category Security]] section covers this in more detail along with a variant called Multi-Category Security (MCS). <br />
<br />
The MLS / MCS services are now more generally used to maintain application separation, for example SELinux enabled:<br />
<br />
* virtual machines use MCS categories to allow each VM to run within its own domain to isolate VMs from each other (see the [[NB_VM | SELinux Virtual Machine Support]] section).<br />
* Android devices use dynamically generated MCS categories so that an app running on behalf of one user cannot read or write files created by the same app running on behalf of another user (see the [[NB_SEforAndroid_2#Computing a Process Context | Security Enhancements for Android - Computing a Process Context]] section).<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_CoreComponents | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_USERS | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_CoreComponentsNB CoreComponents2015-09-21T09:36:31Z<p>RichardHaines: /* Core SELinux Components */</p>
<hr />
<div>= Core SELinux Components =<br />
The [http://selinuxproject.org/~rhaines/NB4-diagrams/1-core.png High Level Core SELinux Components] diagram shows a high level view of the core SELinux components that manage enforcement of the policy and comprises of the following:<br />
<br />
# A [[NB_Subjects | subject]] that must be present to cause an action to be taken by an [[NB_Objects | object]] (such as read a file as information only flows when a subject is involved).<br />
# An Object Manager that knows the actions required of the particular resource (such as a file) and can enforce those actions (i.e. allow it to write to a file if permitted by the policy).<br />
# A Security Server that makes decisions regarding the subjects rights to perform the requested action on the object, based on the security policy rules.<br />
# A Security Policy that describes the rules using the SELinux [[PolicyLanguage | policy language]].<br />
# An Access Vector Cache (AVC) that improves system performance by caching security server decisions.<br />
<br />
Note that decisions by the Security Server are cached in the AVC to enhance performance of future requests, and that it is the kernel and userspace Object Managers that enforce the policy.<br />
<br />
The [http://arctic.selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows a more complex view of the kernel and userspace with a number of supporting services that are used to manage the SELinux environment. This diagram will be referenced a number of times to explain areas of SELinux, therefore starting from the bottom:<br />
<br />
* In the current implementation of SELinux the security server is embedded in the kernel with the policy being loaded from userspace via a series of functions contained in the libselinux library (see [[NB_Userspace_Libraries | SELinux Userspace Libraries]] for details).<br />
<br />
The object managers (OM) and access vector cache (AVC) can reside in:<br />
:: '''kernel space - '''These object manages are for the kernel services such as files, directory, socket, IPC etc. and are provided by hooks into the SELinux sub-system via the Linux Security Module (LSM) framework (shown as LSM Hooks in the [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram) that is discussed in the [[NB_LSM | Linux Security Module and SELinux]] section. The SELinux kernel AVC service is used to cache the security servers response to the kernel based object managers thus speeding up access decisions should the same request be asked in future.<br />
<br />
:: '''userspace''' - These object managers are provided with the application or service that requires support for MAC and are known as 'SELinux-aware' applications or services. Examples of these are: X-Windows, D-bus messaging (used by the Gnome desktop), PostgreSQL database, Name Service Cache Daemon (<tt>nscd</tt>), and the GNU / Linux passwd command. Generally, these OMs use the AVC services built into the SELinux library (libselinux), however they could, if required supply their own AVC or not use an AVC at all (see [[NB_Imp_SELinux-aware_Apps | Implementing SELinux-aware Applications]] for details). <br />
<br />
* The SELinux security policy (right hand side in the [http://selinuxproject.org/~rhaines/Notebook-4/NB_2-high-level-arch.png High Level SELinux Architecture] diagram) and its supporting configuration files are contained in the <tt>/etc/selinux</tt> directory. This directory contains the main SELinux configuration file (<tt>/etc/selinux/config</tt>) that has the name of the policy to be loaded (via the <tt>SELINUXTYPE</tt> entry) and the initial enforcement mode<ref name="ftn1"><sup>When SELinux is enabled, the policy can be running in 'permissive mode' (<tt>SELINUX=permissive</tt>), where all accesses are allowed. The policy can also be run in 'enforcing mode' (<tt>SELINUX=enforcing</tt>), where any access that is not defined in the policy is denied and an entry placed in the audit log. SELinux can also be disabled (at boot time only) by setting <tt>SELINUX=disabled</tt>. There is also support for the [[TypeStatements#permissive | permissive]] statement that allows a domain to run in permissive mode while the others are still confined (instead of the all or nothing set by <tt>SELINUX=</tt>).</sup></ref> of the policy at load time (via the <tt>SELINUX</tt> entry). The <tt>/etc/selinux/<nowiki><SELINUXTYPE></nowiki></tt> directories contain policies that can be activated along with their configuration files (e.g. '<tt>SELINUXTYPE=targeted</tt>' will have its policy and associated configuration files located at <tt>/etc/selinux/targeted</tt>). All known policy configuration files are shown in the [[PolicyConfigurationFiles | Policy Configuration Files]] section.<br />
<br />
* SELinux supports a 'modular policy', this means that a policy does not have to be one large source policy but can be built from modules. A modular policy consists of a base policy that contains the mandatory information (such as object classes, permissions etc.), and zero or more policy modules where generally each supports a particular application or service. These modules are compiled, linked, and held in a 'policy store' where they can be built into a binary format that is then loaded into the security server (in the [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram, the binary policy is located at <tt>/etc/selinux/targeted/policy/policy.29</tt>). The types of policy and their construction are covered in the [[NB_PolicyType | Types of SELinux Policy]] section.<br />
<br />
* To be able to build the policy in the first place, policy source is required (top left hand side of the [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram). This can be supplied in three basic ways: <br />
** as source code written using the [[PolicyLanguage#KernelPolicyLanguage | Kernel Policy Language]]. This is how the simple policies have been written to support the examples in this Notebook, however it is not recommended for large policy developments such as the [[NB_RefPolicy | Reference Policy]], although the smaller SE for Android policy is written this way with some m4 macro support.<br />
** using the [[NB_RefPolicy | Reference Policy]] that has high level macros to define policy rules. This is the standard way policies are now built for SELinux distributions such as Red Hat and Debian and is discussed in the [[NB_RefPolicy | Reference Policy]] section. Note that SE for Android also uses high level macros to define policy rules but the overall policy is much less complex.<br />
** using CIL (Common Intermediate Language). An overview can be found at [https://github.com/SELinuxProject/cil/wiki https://github.com/SELinuxProject/cil/wiki] and [[PolicyLanguage#CIL_Language | CIL Policy Language]].<br />
<br />
* To be able to compile and link the policy source then load it into the security server requires a number of tools (top of [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram).<br />
<br />
* To enable system administrators to manage policy, the SELinux environment and label file systems, tools and modified GNU / Linux commands are used. These are mentioned throughout the Notebook as needed. Note that there are many other applications to manage policy, however this Notebook only concentrates on the core services.<br />
<br />
* To ensure security events are logged, GNU / Linux has an audit service that captures policy violations. The [[NB_AL | Auditing SELinux Events]] section describes the format of these security events.<br />
<br />
* SELinux supports network services that are described in the [[NB_Networking | SELinux Networking Support]] section.<br />
<br />
The [[NB_LSM | Linux Security Module and SELinux]] section goes into greater detail of the LSM / SELinux modules with a walk-through of a <tt>fork</tt> and <tt>exec</tt> process.<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Overview | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_MAC | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XpermRulesXpermRules2015-07-24T13:15:54Z<p>RichardHaines: /* Extended Permission Access Vector Rules */</p>
<hr />
<div>= Extended Permission Access Vector Rules =<br />
There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments: <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt>.<br />
<br />
The rules for extended permissions are subject to the <tt>operation</tt> they perform with Policy version 30 supporting ioctl whitelisting.<br />
<br />
'''The common format for Extended Access Vector Rules are:'''<br />
<pre><br />
rule_name source_type target_type : class operation xperm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable <tt>allowxperm</tt>, <tt>dontauditxperm</tt> or <tt>auditallowxperm</tt> rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| operation<br />
| A key word defining the operation to be implemented by the rule. Currently only the ioctl operation is supported by the language and kernel as described in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|-<br />
| xperm_set<br />
| One or more extended permissions represented by numeric values (i.e. 0x8900 or 35072). The usage is dependant on the specified operation.<br />
<br />
Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed.<br />
<br />
The range operator (-) is used to specify all permissions within the low – high range.<br />
<br />
An example is shown in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
== ioctl Operation Rules ==<br />
Use cases and implementation details for ioctl command whitelisting are described in detail at [http://marc.info/?l=selinux&m=143336061925628&w=2 http://marc.info/?l=selinux&m=143336061925628&w=2], with the final policy format changes shown in the example below with a brief overview (also see [http://marc.info/?l=selinux&m=143412575302369&w=2 http://marc.info/?l=selinux&m=143412575302369&w=2]) that is the final upstream kernel patch).<br />
Ioctl calls are generally used to get or set device options. Policy versions < 30 only controls whether an ioctl permission is allowed or not, for example this rule allows the object class tcp_socket the ioctl permission:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
</pre><br />
<br />
<br />
From Policy version 30 it is possible to control <tt>'''ioctl'''(2)</tt> 'request' parameters provided the ioctl permission is also allowed, for example:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
<br />
allowxperm src_t tgt_t : tcp_socket ioctl ~0x8927;<br />
</pre><br />
<br />
The allowxperm rule states that all ioctl request parameters are allowed for the source/target/class with the exception of the value 0x8927 that (using <tt>include/linux/sockios.h</tt>) is <tt>SIOCGIFHWADDR</tt>, or 'get hardware address'.<br />
<br />
<br />
An example audit log entry denying an ioctl request to add a routing table entry (<tt>SIOCADDRT - ioctlcmd=890b</tt>) for goldfish_setup on a udp_socket is:<br />
<pre><br />
type=1400 audit(1437408413.860:6): avc: denied { ioctl } for pid=81 comm="route" path="socket:[1954]" dev="sockfs" ino=1954 ioctlcmd=890b<br />
scontext=u:r:goldfish_setup:s0 tcontext=u:r:goldfish_setup:s0 tclass=udp_socket permissive=0<br />
</pre><br />
<br />
<br />
Notes:<br />
** Important: The ioctl operation is not 'deny all' ioctl requests (hence whitelisting). It is targeted at the specific source/target/class set of ioctl commands. As no other allowxperm rules have been defined in the example, all other ioctl calls may continue to use any valid request parameters (provided there are allow rules for the ioctl permission).<br />
** As the <tt>'''ioctl'''(2)</tt> function requires a file descriptor, its context must match the process context otherwise the <tt>fd { use }</tt> class/permission is required.<br />
** To deny all ioctl requests for a specific source/target/class the xperm_set can be set to '0' or '0x0'.<br />
** This feature is implemented in Android kernels (e.g. android-goldfish-3.4) and is available in Linux kernels > 4.2-rc2.<br />
Note that Android M is built with an earlier version (see thread [http://marc.info/?l=seandroid-list&m=143436044512043&w=2 http://marc.info/?l=seandroid-list&m=143436044512043&w=2]) that uses the following rule format:<br />
<pre><br />
# Allow SIOCGIFNAME (get iface name) ioctl requests on udp_socket for untrusted_app<br />
allow untrusted_app self:udp_socket 0x8910;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[AVCRules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XpermRulesXpermRules2015-07-21T11:26:47Z<p>RichardHaines: /* ioctl Operation Rules */</p>
<hr />
<div>= Extended Permission Access Vector Rules =<br />
There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments: <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt>.<br />
<br />
The rules for extended permissions are subject to the <tt>operation</tt> they perform with Policy version 30 supporting ioctl whitelisting.<br />
<br />
'''The common format for Extended Access Vector Rules are:'''<br />
<pre><br />
rule_name source_type target_type : class operation xperm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable <tt>allowxperm</tt>, <tt>dontauditxperm</tt> or <tt>auditallowxperm</tt> rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| operation<br />
| A key word defining the operation to be implemented by the rule. Currently only the ioctl operation is supported by the language and kernel as described in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|-<br />
| xperm_set<br />
| One or more extended permissions represented by numeric values (i.e. 0x8900 or 35072). The usage is dependant on the specified operation.<br />
<br />
Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed.<br />
<br />
The range operator (-) is used to specify all permissions within the low – high range.<br />
<br />
An example is shown in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|}<br />
<br />
<br />
== ioctl Operation Rules ==<br />
Use cases and implementation details for ioctl command whitelisting are described in detail at [http://marc.info/?l=selinux&m=143336061925628&w=2 http://marc.info/?l=selinux&m=143336061925628&w=2], with the final policy format changes shown in the example below with a brief overview (also see [http://marc.info/?l=selinux&m=143412575302369&w=2 http://marc.info/?l=selinux&m=143412575302369&w=2]) that is the final upstream kernel patch).<br />
Ioctl calls are generally used to get or set device options. Policy versions < 30 only controls whether an ioctl permission is allowed or not, for example this rule allows the object class tcp_socket the ioctl permission:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
</pre><br />
<br />
<br />
From Policy version 30 it is possible to control <tt>'''ioctl'''(2)</tt> 'request' parameters provided the ioctl permission is also allowed, for example:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
<br />
allowxperm src_t tgt_t : tcp_socket ioctl ~0x8927;<br />
</pre><br />
<br />
The allowxperm rule states that all ioctl request parameters are allowed for the source/target/class with the exception of the value 0x8927 that (using <tt>include/linux/sockios.h</tt>) is <tt>SIOCGIFHWADDR</tt>, or 'get hardware address'.<br />
<br />
<br />
An example audit log entry denying an ioctl request to add a routing table entry (<tt>SIOCADDRT - ioctlcmd=890b</tt>) for goldfish_setup on a udp_socket is:<br />
<pre><br />
type=1400 audit(1437408413.860:6): avc: denied { ioctl } for pid=81 comm="route" path="socket:[1954]" dev="sockfs" ino=1954 ioctlcmd=890b<br />
scontext=u:r:goldfish_setup:s0 tcontext=u:r:goldfish_setup:s0 tclass=udp_socket permissive=0<br />
</pre><br />
<br />
<br />
Notes:<br />
** Important: The ioctl operation is not 'deny all' ioctl requests (hence whitelisting). It is targeted at the specific source/target/class set of ioctl commands. As no other allowxperm rules have been defined in the example, all other ioctl calls may continue to use any valid request parameters (provided there are allow rules for the ioctl permission).<br />
** As the <tt>'''ioctl'''(2)</tt> function requires a file descriptor, its context must match the process context otherwise the <tt>fd { use }</tt> class/permission is required.<br />
** To deny all ioctl requests for a specific source/target/class the xperm_set can be set to '0' or '0x0'.<br />
** This feature is implemented in Android kernels (e.g. android-goldfish-3.4) and is available in Linux kernels > 4.2-rc2.<br />
Note that Android M is built with an earlier version (see thread [http://marc.info/?l=seandroid-list&m=143436044512043&w=2 http://marc.info/?l=seandroid-list&m=143436044512043&w=2]) that uses the following rule format:<br />
<pre><br />
# Allow SIOCGIFNAME (get iface name) ioctl requests on udp_socket for untrusted_app<br />
allow untrusted_app self:udp_socket 0x8910;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[AVCRules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XpermRulesXpermRules2015-07-21T11:18:43Z<p>RichardHaines: /* ioctl Operation Rules */</p>
<hr />
<div>= Extended Permission Access Vector Rules =<br />
There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments: <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt>.<br />
<br />
The rules for extended permissions are subject to the <tt>operation</tt> they perform with Policy version 30 supporting ioctl whitelisting.<br />
<br />
'''The common format for Extended Access Vector Rules are:'''<br />
<pre><br />
rule_name source_type target_type : class operation xperm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable <tt>allowxperm</tt>, <tt>dontauditxperm</tt> or <tt>auditallowxperm</tt> rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| operation<br />
| A key word defining the operation to be implemented by the rule. Currently only the ioctl operation is supported by the language and kernel as described in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|-<br />
| xperm_set<br />
| One or more extended permissions represented by numeric values (i.e. 0x8900 or 35072). The usage is dependant on the specified operation.<br />
<br />
Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed.<br />
<br />
The range operator (-) is used to specify all permissions within the low – high range.<br />
<br />
An example is shown in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|}<br />
<br />
<br />
== ioctl Operation Rules ==<br />
Use cases and implementation details for ioctl command whitelisting are described in detail at [http://marc.info/?l=selinux&m=143336061925628&w=2 http://marc.info/?l=selinux&m=143336061925628&w=2], with the final policy format changes shown in the example below with a brief overview (also see [http://marc.info/?l=selinux&m=143412575302369&w=2 http://marc.info/?l=selinux&m=143412575302369&w=2]) that is the final upstream kernel patch).<br />
Ioctl calls are generally used to get or set device options. Policy versions < 30 only controls whether an ioctl permission is allowed or not, for example this rule allows the object class tcp_socket the ioctl permission:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
</pre><br />
<br />
<br />
From Policy version 30 it is possible to control <tt>'''ioctl'''(2)</tt> 'request' parameters provided the ioctl permission is also allowed, for example:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
<br />
allowxperm src_t tgt_t : tcp_socket ioctl ~0x8927;<br />
</pre><br />
<br />
The allowxperm rule states that all ioctl request parameters are allowed for the source/target/class with the exception of the value 0x8927 that (using <tt>include/linux/sockios.h</tt>) is <tt>SIOCGIFHWADDR</tt>, or 'get hardware address'.<br />
<br />
<br />
An example audit log entry denying an ioctl request to add a routing table entry (<tt>SIOCADDRT - ioctlcmd=890b</tt> - ) for goldfish_setup on a udp_socket is:<br />
<pre><br />
type=1400 audit(1437408413.860:6): avc: denied { ioctl } for pid=81 comm="route" path="socket:[1954]" dev="sockfs" ino=1954 ioctlcmd=890b<br />
scontext=u:r:goldfish_setup:s0 tcontext=u:r:goldfish_setup:s0 tclass=udp_socket permissive=0<br />
</pre><br />
<br />
<br />
Notes:<br />
** Important: The ioctl operation is not 'deny all' ioctl requests (hence whitelisting). It is targeted at the specific source/target/class set of ioctl commands. As no other allowxperm rules have been defined in the example, all other ioctl calls may continue to use any valid request parameters (provided there are allow rules for the ioctl permission).<br />
** As the <tt>'''ioctl'''(2)</tt> function requires a file descriptor, its context must match the process context otherwise the <tt>fd { use }</tt> class/permission is required.<br />
** To deny all ioctl requests for a specific source/target/class the xperm_set can be set to '0' or '0x0'.<br />
** This feature is implemented in Android kernels (e.g. android-goldfish-3.4) and is available in Linux kernels > 4.2-rc2.<br />
Note that Android M is built with an ealier version (see thread [http://marc.info/?l=seandroid-list&m=143436044512043&w=2 http://marc.info/?l=seandroid-list&m=143436044512043&w=2]) that uses the following rule format:<br />
<pre><br />
# Allow SIOCGIFNAME (get iface name) ioctl requests on udp_socket for untrusted_app<br />
allow untrusted_app self:udp_socket 0x8910;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[AVCRules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XpermRulesXpermRules2015-07-21T11:11:35Z<p>RichardHaines: /* ioctl Operation Rules */</p>
<hr />
<div>= Extended Permission Access Vector Rules =<br />
There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments: <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt>.<br />
<br />
The rules for extended permissions are subject to the <tt>operation</tt> they perform with Policy version 30 supporting ioctl whitelisting.<br />
<br />
'''The common format for Extended Access Vector Rules are:'''<br />
<pre><br />
rule_name source_type target_type : class operation xperm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable <tt>allowxperm</tt>, <tt>dontauditxperm</tt> or <tt>auditallowxperm</tt> rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| operation<br />
| A key word defining the operation to be implemented by the rule. Currently only the ioctl operation is supported by the language and kernel as described in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|-<br />
| xperm_set<br />
| One or more extended permissions represented by numeric values (i.e. 0x8900 or 35072). The usage is dependant on the specified operation.<br />
<br />
Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed.<br />
<br />
The range operator (-) is used to specify all permissions within the low – high range.<br />
<br />
An example is shown in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|}<br />
<br />
<br />
== ioctl Operation Rules ==<br />
Use cases and implementation details for ioctl command whitelisting are described in detail at [http://marc.info/?l=selinux&m=143336061925628&w=2 http://marc.info/?l=selinux&m=143336061925628&w=2], with the final policy format changes shown in the example below with a brief overview (also see [http://marc.info/?l=selinux&m=143412575302369&w=2 http://marc.info/?l=selinux&m=143412575302369&w=2]) that is the final upstream kernel patch).<br />
Ioctl calls are generally used to get or set device options. Policy versions < 30 only controls whether an ioctl permission is allowed or not, for example this rule allows the object class tcp_socket the ioctl permission:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
</pre><br />
<br />
<br />
From Policy version 30 it is possible to control <tt>'''ioctl'''(2)</tt> 'request' parameters provided the ioctl permission is also allowed, for example:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
<br />
allowxperm src_t tgt_t : tcp_socket ioctl ~0x8927;<br />
</pre><br />
<br />
The allowxperm rule states that all ioctl request parameters are allowed for the source/target/class with the exception of the value 0x8927 that (using <tt>include/linux/sockios.h</tt>) is <tt>SIOCGIFHWADDR</tt>, or 'get hardware address'.<br />
<br />
<br />
An example deny ioctl request SIOCADDRT (add routing table entry) for goldfish_setup on a udp_socket is:<br />
<pre><br />
type=1400 audit(1437408413.860:6): avc: denied { ioctl } for pid=81 comm="route" path="socket:[1954]" dev="sockfs" ino=1954 ioctlcmd=890b<br />
scontext=u:r:goldfish_setup:s0 tcontext=u:r:goldfish_setup:s0 tclass=udp_socket permissive=0<br />
</pre><br />
<br />
Notes:<br />
** Important: The ioctl operation is not 'deny all' ioctl requests (hence whitelisting). It is targeted at the specific source/target/class set of ioctl commands. As no other allowxperm rules have been defined in the example, all other ioctl calls may continue to use any valid request parameters (provided there are allow rules for the ioctl permission).<br />
** As the <tt>'''ioctl'''(2)</tt> function requires a file descriptor, its context must match the process context otherwise the <tt>fd { use }</tt> class/permission is required.<br />
** To deny all ioctl requests for a specific source/target/class the xperm_set can be set to '0' or '0x0'.<br />
** This feature is implemented in Android kernels (e.g. android-goldfish-3.4) and is available in Linux kernels > 4.2-rc2.<br />
Note that Android M is built with an ealier version (see thread [http://marc.info/?l=seandroid-list&m=143436044512043&w=2 http://marc.info/?l=seandroid-list&m=143436044512043&w=2]) that uses the following rule format:<br />
<pre><br />
# Allow SIOCGIFNAME (get iface name) ioctl requests on udp_socket for untrusted_app<br />
allow untrusted_app self:udp_socket 0x8910;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[AVCRules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/AVCRulesAVCRules2015-07-21T11:08:20Z<p>RichardHaines: /* neverallow */</p>
<hr />
<div>= Access Vector Rules =<br />
The AV rules define what access control privileges are allowed for processes. There are four types of AV rule: allow, dontaudit, auditallow, and neverallow as explained in the sections that follow with a number of examples to cover all the scenarios. There is also an auditdeny rule, however it is no longer used in the Reference Policy and has been replaced by the dontaudit rule.<br />
<br />
From Policy version 30 with the target platform <tt>selinux</tt>, the AVC rules have been extended to expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments. The format of the new <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt> rules are discussed in the [[XpermRules | Extended Permission Access Vector Rules]] section.<br />
<br />
The general format of an AV rule is that the source_type is the identifier of a process that is attempting to access an object identifier target_type, that has an object class of class, and perm_set defines the access permissions source_type is allowed.<br />
<br />
'''The common format of the Access Vector Rule is:'''<br />
<pre><br />
rule_name source_type target_type : class perm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable allow, dontaudit, auditallow, and neverallow rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
The neverallow rule also supports the wildcard operator (<nowiki>*</nowiki>) to specify that all types are to be included and the complement operator (~) to specify all types are to be included except those explicitly listed.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| perm_set<br />
| The access permissions the source is allowed to access for the target object (also known as the Acess Vector). Multiple entries consist of a space separated list enclosed in braces ({}). <br />
<br />
The optional wildcard operator (<nowiki>*</nowiki>) specifies that all permissions for the object class can be used. <br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed (although the compiler issues a warning if the dontaudit rule has '~').<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| '''allow = Yes'''<br />
<br />
'''auditallow = Yes'''<br />
<br />
'''dontaudit = Yes'''<br />
<br />
'''neverallow = No'''<br />
| '''allow = Yes'''<br />
<br />
'''auditallow = Yes'''<br />
<br />
'''dontaudit = Yes'''<br />
<br />
'''neverallow = Yes'''<br />
| '''allow = No'''<br />
<br />
'''auditallow = No'''<br />
<br />
'''dontaudit = No'''<br />
<br />
'''neverallow = No'''<br />
<br />
|}<br />
<br />
<br />
== allow ==<br />
The allow rule checks whether the operations between the source_type and target_type are allowed for the class and permissions defined. It is the most common statement that many of the Reference Policy helper macros and interface definitions expand into multiple allow rules.<br />
<br />
'''Examples:'''<br />
<pre><br />
# Using the allow rule to show that initrc_t is allowed access <br />
# to files of type acct_exec_t that have the getattr, read and <br />
# execute file permissions:<br />
<br />
allow initrc_t acct_exec_t:file { getattr read execute };<br />
</pre><br />
<pre><br />
# This rule includes an attribute filesystem_type and states <br />
# that kernel_t is allowed mount permissions on the filesystem<br />
# object for all types associated to the filesystem_type <br />
# attribute:<br />
<br />
allow kernel_t filesystem_type:filesystem mount;<br />
</pre><br />
<pre><br />
# This rule includes the self keyword in the target_type that<br />
# states that staff_t is allowed setgid, chown and fowner <br />
# permissions on the capability object:<br />
<br />
allow staff_t self:capability { setgid chown fowner };<br />
</pre><br />
<pre><br />
# This would be the same as the above:<br />
allow staff_t staff_t:capability { setgid chown fowner };<br />
</pre><br />
<pre><br />
# This rule includes the wildcard operator (*) on the perm_set<br />
# and states that bootloader_t is allowed to use all permissions<br />
# available on the dbus object that are type system_dbusd_t:<br />
<br />
allow bootloader_t system_dbusd_t:dbus *;<br />
</pre><br />
<pre><br />
# This would be the same as the above:<br />
allow bootloader_t system_dbusd_t:dbus { acquire_svc send_msg };<br />
</pre><br />
<pre><br />
# This rule includes the complement operator (~) on the perm_set<br />
# and two class entries file and chr_file.<br />
#<br />
# The allow rule states that all types associated with the <br />
# attribute files_unconfined_type are allowed to use all <br />
# permissions available on the file and chr_file objects '''except'''<br />
# the execmod permission when they are associated to the types <br />
# listed within the attribute file_type:<br />
<br />
allow files_unconfined_type file_type:{ file chr_file } ~execmod;<br />
</pre><br />
<br />
== dontaudit ==<br />
The dontaudit rule stops the auditing of denial messages as it is known that this event always happens and does not cause any real issues. This also helps to manage the audit log by excluding known events.<br />
<br />
'''Example:'''<br />
<pre><br />
# Using the dontaudit rule to stop auditing events that are <br />
# known to happen. The rule states that when the traceroute_t <br />
# process is denied access to the name_bind permission on a <br />
# tcp_socket for all types associated to the port_type <br />
# attribute (except port_t), then do not audit the event:<br />
<br />
dontaudit traceroute_t { port_type -port_t }:tcp_socket name_bind;<br />
</pre><br />
<br />
== auditallow ==<br />
Audit the event as a record as it is useful for auditing purposes. Note that this rule only audits the event, it still requires the allow rule to grant permission.<br />
<br />
'''Example:'''<br />
<pre><br />
# Using the auditallow rule to force an audit event to be <br />
# logged. The rule states that when the ada_t process has # permission to execstack, then that event must be audited:<br />
<br />
auditallow ada_t self:process execstack;<br />
</pre><br />
<br />
== neverallow ==<br />
This rule specifies that an <tt>allow</tt> rule must not be generated for the operation, even if it has been previously allowed. The neverallow statement is a compiler enforced action, where the checkpolicy or checkmodule<ref name="ftn46"><sup><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.'''</sup></ref> compiler checks if any allow rules have been generated in the policy source, if so it will issue a warning and stop.<br />
<br />
'''Examples''':<br />
<pre><br />
# Using the neverallow rule to state that no allow rule may ever<br />
# grant any file read access to type shadow_t except those <br />
# associated with the can_read_shadow_passwords attribute:<br />
<br />
neverallow ~can_read_shadow_passwords shadow_t:file read;<br />
</pre><br />
<pre><br />
# Using the neverallow rule to state that no allow rule may ever<br />
# grant mmap_zero permissions any type associated to the domain <br />
# attribute except those associated to the mmap_low_domain_type<br />
# attribute (as these have been excluded by the negative <br />
# operator (-)):<br />
<br />
neverallow { domain -mmap_low_domain_type } self:memprotect mmap_zero;<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[Bounds Rules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[XpermRules | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_PolicyTypeNB PolicyType2015-07-21T11:07:00Z<p>RichardHaines: </p>
<hr />
<div>= Types of SELinux Policy =<br />
This section describes the different type of policy descriptions and versions that can be found within SELinux.<br />
<br />
The type of SELinux policy can described in a number of ways:<br />
<br />
# Source code - These can be described as: [[#Example_Policy | Example]], [[#Reference_Policy | Reference Policy]] or [[#Custom_Policy | Custom]]. They are generally written using either [[KernelPolicyLanguage | kernel policy language]], [[NB_RefPolicy#Reference Policy Support Macros | m4 macro support with kernel policy language]], or [[CIL_Language | CIL]].<br />
# They can also be classified as: [[#Monolithic_Policy | Monolithic]], [[#Reference_Policy | Base Module or Loadable Module]].<br />
# Policies can also be described by the [[#Policy_Functionality_Type | type of policy functionality]] they provide such as: targeted, mls, mcs, standard, strict or minimum.<br />
# Classified using language statements - These can be described as [[#Reference_Policy | Modular, Optional]] or [[#Conditional_Policy | Conditional]].<br />
# Binary policy (or kernel policy) - These can be described as [[#Policy_Versions | Monolithic, Kernel Policy or Binary file]].<br />
# Classification can also be on the '[[#Policy_Versions | policy version]]' used (examples are version 27, 28 and 29).<br />
# Policy can also be generated depending on the target platform of either 'selinux' (the default) or 'xen' (see the SELinux policy generation tools <tt>'''checkpolicy'''(8)</tt> and <tt>'''secilc'''(8)</tt> <tt>target_platform</tt> option).<br />
<br />
As can be seen the description of a policy can vary depending on the context.<br />
<br />
== Example Policy ==<br />
The Example policy is the name used to describe the original SELinux policy source used to build a [[#Policy_Versions | monolithic]]<ref name="ftn12"><sup>The term 'monolithic' generally means a single policy source is used to create the binary policy file that is then loaded as the 'policy' using the '''checkpolicy'''(8) command. However the term is sometimes used to refer to the binary policy file (as it is one file that describes the policy).</sup></ref> policy produced by the NSA and is now superseded by the Reference Policy.<br />
<br />
== Reference Policy ==<br />
Note that this section only gives an introduction to the Reference Policy, the installation, configuration and building of a policy using this is contained in [[NB_RefPolicy | The Reference Policy]] section.<br />
<br />
The Reference Policy is now the standard policy source used to build Linux based SELinux policies, and its main aim is to provide a single source tree with supporting documentation that can be used to build policies for different purposes such as confining important daemons, supporting MLS / MCS and locking down systems so that all processes are under SELinux control. <br />
<br />
The Reference Policy is now used by all major distributions of Linux, however each distribution makes its own specific changes to support their 'version of the Reference Policy'. For example, the F-20 distribution is based on a specific build of the standard Reference Policy that is then modified and distributed by Red Hat as a number of RPMs.<br />
<br />
== Policy Functionality Based on Name or Type ==<br />
Generally a policy is installed with a given name such as <tt>targeted</tt>, <tt>mls</tt>, <tt>refpolicy</tt> or <tt>minimum</tt> that attempts to describes its functionality. This name then becomes the entry in: <br />
<br />
# The directory pointing to the policy location (e.g. if the name is <tt>targeted</tt>, then the policy will be installed in <tt>/etc/selinux/targeted</tt>).<br />
# The <tt>SELINUXTYPE</tt> entry in the <tt>/etc/selinux/config</tt> file when it is the active policy (e.g. if the name is <tt>targeted</tt>, then a <tt>SELINUXTYPE=targeted</tt> entry would be in the <tt>/etc/selinux/config</tt> file).<br />
<br />
This is how the reference policies distributed with F-20 are named, where:<br />
: minimum - supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space. Red Hat pre-configure MCS support within this policy.<br />
: targeted - supports a greater number of confined daemons and can also confine other areas and users. Red Hat pre-configure MCS support within this policy.<br />
: mls - supports server based MLS systems.<br />
<br />
The Reference Policy also has a <tt>TYPE</tt> description that describes the type of policy being built by the build process, these are:<br />
: standard - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older 'targeted' and 'strict' versions).<br />
: mcs - As standard but supports MCS labels.<br />
: mls - supports server based MLS systems.<br />
<br />
The <tt>NAME</tt> and <tt>TYPE</tt> entries are defined in the reference policy <tt>build.conf</tt> file that is described in the [[NB_RefPolicy#Source Configuration Files | Source Configuration Files]] section. <br />
<br />
== Custom Policy ==<br />
This generally refers to a policy source that is either:<br />
<br />
# A customised version of the Example policy.<br />
# A customised version of the Reference Policy (i.e. not the standard distribution version e.g. Red Hat policies).<br />
# A policy that has been built using policy language statements to build a specific policy such as the basic policy built in the Notebook source tarball.<br />
<br />
== Monolithic Policy ==<br />
A Monolithic policy is an SELinux policy that is compiled from one source file called (by convention) <tt>policy.conf</tt> (i.e. it does not use the Loadable Module Policy statements and infrastructure which therefore makes it suitable for embedded systems as there is no policy store overhead). <br />
<br />
An example monolithic policy is the NSAs original [[#Example_Policy | Example Policy]].<br />
<br />
Monolithic policies are compiled using the '''checkpolicy''' (8) SELinux command. <br />
<br />
The Reference Policy supports the building of monolithic policies.<br />
<br />
In some cases the kernel policy binary file (see the [[#Binary Policy | Binary Policy]] section) is also called a monolithic policy.<br />
<br />
== Loadable Module Policy ==<br />
The loadable module infrastructure allows policy to be managed on a modular basis, in that there is a base policy module that contains all the core components of the policy (i.e. the policy that should always be present), and zero or more modules that can be loaded and unloaded as required (for example if there is a module to enforce policy for ftp, but ftp is not used, then that module could be unloaded).<br />
<br />
There are number of components that form the infrastructure:<br />
<br />
# Policy source code that is constructed for a modular policy with a base module and optional loadable modules.<br />
# Utilities to compile and link modules and place them into a 'policy store'.<br />
# Utilities to manage the modules and associated configuration files within the 'policy store'.<br />
<br />
The [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows these components along the top of the diagram. The files contained in the policy store are detailed in the [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]] section.<br />
<br />
The policy language was extended to handle loadable modules as detailed in the [[KernelPolicyLanguage#Policy_Support_Statements | Policy Support Statements]] section. For a detailed overview on how the modular policy is built into the final binary policy for loading into the kernel, see "[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer].<br />
<br />
== Optional Policy ==<br />
The loadable module policy infrastructure supports an [[KernelPolicyLanguage#optional | optional policy statement]] that allows policy rules to be defined but only enabled in the binary policy once the conditions have been satisfied. <br />
<br />
== Conditional Policy ==<br />
Conditional policies can be implemented in monolithic or loadable module policies and allow parts of the policy to be enabled or not depending on the state of a boolean flag at run time. This is often used to enable or disable features within the policy (i.e. change the policy enforcement rules).<br />
<br />
The boolean flag status is held in kernel and can be changed using the '''setsebool'''(8) command either persistently across system re-boots or temporarily (i.e. only valid until a re-boot). The following example shows a persistent conditional policy change:<br />
<pre><br />
setsebool -P ext_gateway_audit false<br />
</pre><br />
<br />
The conditional policy language statements are the <tt>bool</tt> Statement that defines the boolean flag identifier and its initial status, and the <tt>if</tt> Statement that allows certain rules to be executed depending on the state of the boolean value or values.<br />
<br />
== Binary Policy ==<br />
This is also know as the kernel policy and is the policy file that is loaded into the kernel and is located at <nowiki>/etc/selinux/<SELINUXTYPE>/policy/policy.<version></nowiki>. Where <tt><nowiki><SELINUXTYPE</nowiki>></tt> is the policy name specified in the SELinux configuration file /etc/selinux/config and <nowiki><version></nowiki> is the SELinux [[#Policy_Versions | policy version]].<br />
<br />
The binary policy can be built from source files supplied by the Reference Policy or custom built source files.<br />
<br />
An example /etc/selinux/config file is shown below where the <tt>SELINUXTYPE=targeted</tt> entry identifies the policy name that will be used to locate and load the active policy:<br />
<pre><br />
SELINUX=permissive<br />
SELINUXTYPE=targeted<br />
</pre><br />
<br />
From the above example, the actual binary policy file would be located at /etc/selinux/targeted/policy and be called policy.29 (as version 29 is supported by F-20):<br />
<pre><br />
/etc/selinux/targeted/policy/policy.29<br />
</pre><br />
<br />
== Policy Versions ==<br />
SELinux has a policy database (defined in the libsepol library) that describes the format of data held within a [[#Binary_Policy | binary policy]], however, if any new features are added to SELinux (generally language extensions) this can result in a change to the policy database. Whenever the policy database is updated, the policy version is incremented. <br />
<br />
The '''sestatus'''(8) command will show the maximum policy version supported by the kernel in its output as follows:<br />
<pre><br />
SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
Loaded policy name targeted<br />
Current mode: enforcing<br />
Mode from config file: permissive<br />
Policy MLS status: enabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 29<br />
</pre><br />
<br />
The following table describes the different versions, although note that there is also another version that applies to the modular policy, however the main policy database version is the one that is generally quoted (some SELinux utilities give both version numbers).<br />
<br />
{| border="1"<br />
! policy db Version<br />
! modular db Version<br />
! Description<br />
<br />
|-<br />
| <center>15</center><br />
| <center>4</center><br />
| The base version when SELinux was merged into the kernel.<br />
<br />
|-<br />
| <center>16</center><br />
| <center>-</center><br />
| Added [[#Conditional_Policy | Conditional Policy]] support (the bool feature).<br />
<br />
|-<br />
| <center>17</center><br />
| <center>-</center><br />
| Added support for IPv6.<br />
<br />
|-<br />
| <center>18</center><br />
| <center>-</center><br />
| Added Netlink support.<br />
<br />
|-<br />
| <center>19</center><br />
| <center>5</center><br />
| Added MLS support, plus the validatetrans Statement.<br />
<br />
|-<br />
| <center>20</center><br />
| <center>-</center><br />
| Reduced the size of the access vector table.<br />
<br />
|-<br />
| <center>21</center><br />
| <center>6</center><br />
| Added support for the MLS range_transition Statement.<br />
<br />
|-<br />
| <center>22</center><br />
| <center>7</center><br />
| Added [[KernelPolicyLanguage#policycap | policy capabilities]] that allows various kernel options to be enabled as described in the [[NB_LSM#SELinux Filesystem | SELinux Filesystem]] section.<br />
<br />
|-<br />
| <center>23</center><br />
| <center>8</center><br />
| Added support for the permissive statement. This allows a domain to run in permissive mode while the others are still confined (instead of the all or nothing set by the <tt>SELINUX</tt> entry in the <tt>/etc/selinux/config</tt> file).<br />
<br />
|-<br />
| <center>24</center><br />
| <center>9 / 10</center><br />
| Add support for the <tt>typebounds</tt> statement. This was added to support a hierarchical relationship between two domains in multi-threaded web servers as described in "[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]".<br />
|-<br />
| <center>25</center><br />
| <center>11</center><br />
| Add support for file name transition in the <tt>type_transition</tt> rule. Requires kernel 2.6.39 minimum.<br />
<br />
|-<br />
| <center>26</center><br />
| <center>12/13</center><br />
| Add support for a class parameter in the <tt>role_transition</tt> rule.<br />
<br />
Add support for the <tt>attribute_role</tt> and <tt>roleattribute</tt> statements.<br />
<br />
These require kernel 2.6.39 minimum.<br />
<br />
|-<br />
| <center>-</center><br />
| <center>14</center><br />
| Separate tunables.<br />
<br />
|-<br />
| <center>27</center><br />
| <center>15</center><br />
| Support setting object defaults for the user, role and range components when computing a new context. Requires kernel 3.5 minimum.<br />
<br />
|-<br />
| <center>28</center><br />
| <center>16</center><br />
| Support setting object defaults for the type component when computing a new context. Requires kernel 3.5 minimum.<br />
<br />
|-<br />
| <center>29</center><br />
| <center>17</center><br />
| Support attribute names within constraints. This allows attributes as well as the types to be retrieved from a kernel policy to assist <tt>'''audit2allow'''(8)</tt> etc. to determine what attribute needs to be updated. Note that the attribute does not determine the constraint outcome, it is still the list of types associated to the constraint. Requires kernel 3.14 minimum.<br />
<br />
|-<br />
| <center>30</center><br />
|<br />
| There are two version 30 enhancements that depend on the policy being built:<br />
# For the 'selinux' target platform adds new 'xperm' rules and extends the permission sets as explained in the [[XpermRules | Extended Permission Access Vector Rules]] section. This is to support 'ioctl whitelisting' as explained in the [[XpermRules#ioctl_Operation_Rules | ioctl Operation Rules]] section.<br />
# For the 'xen' target platform support the <tt>devicetreecon</tt> statement and also expand the existing I/O memory range to 64 bits as explained in the [[XENStatements | XEN Statements]] section.<br />
<br />
|}<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_MLS | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_PandE | '''Next''']]</center><br />
|}<br />
<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XpermRulesXpermRules2015-07-21T11:04:23Z<p>RichardHaines: /* ioctl Operation Rules */</p>
<hr />
<div>= Extended Permission Access Vector Rules =<br />
There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments: <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt>.<br />
<br />
The rules for extended permissions are subject to the <tt>operation</tt> they perform with Policy version 30 supporting ioctl whitelisting.<br />
<br />
'''The common format for Extended Access Vector Rules are:'''<br />
<pre><br />
rule_name source_type target_type : class operation xperm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable <tt>allowxperm</tt>, <tt>dontauditxperm</tt> or <tt>auditallowxperm</tt> rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| operation<br />
| A key word defining the operation to be implemented by the rule. Currently only the ioctl operation is supported by the language and kernel as described in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|-<br />
| xperm_set<br />
| One or more extended permissions represented by numeric values (i.e. 0x8900 or 35072). The usage is dependant on the specified operation.<br />
<br />
Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed.<br />
<br />
The range operator (-) is used to specify all permissions within the low – high range.<br />
<br />
An example is shown in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|}<br />
<br />
<br />
== ioctl Operation Rules ==<br />
Use cases and implementation details for ioctl command whitelisting are described in detail at [http://marc.info/?l=selinux&m=143336061925628&w=2 http://marc.info/?l=selinux&m=143336061925628&w=2], with the final policy format changes shown in the example below with a brief overview (also see [http://marc.info/?l=selinux&m=143412575302369&w=2 http://marc.info/?l=selinux&m=143412575302369&w=2]) that is the final upstream kernel patch).<br />
Ioctl calls are generally used to get or set device options. Policy versions < 30 only controls whether an ioctl permission is allowed or not, for example this rule allows the object class tcp_socket the ioctl permission:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
</pre><br />
<br />
From Policy version 30 it is possible to control <tt>'''ioctl'''(2)</tt> 'request' parameters provided the ioctl permission is also allowed, for example:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
<br />
allowxperm src_t tgt_t : tcp_socket ioctl ~0x8927;<br />
</pre><br />
<br />
The allowxperm rule states that all ioctl request parameters are allowed for the source/target/class with the exception of the value 0x8927 that (using <tt>include/linux/sockios.h</tt>) is <tt>SIOCGIFHWADDR</tt>, or 'get hardware address'.<br />
<br />
An example deny ioctl request SIOCADDRT (add routing table entry) for goldfish_setup on a udp_socket is:<br />
<pre><br />
type=1400 audit(1437408413.860:6): avc: denied { ioctl } for pid=81 comm="route" path="socket:[1954]" dev="sockfs" ino=1954 ioctlcmd=890b scontext=u:r:goldfish_setup:s0 tcontext=u:r:goldfish_setup:s0 tclass=udp_socket permissive=0<br />
</pre><br />
<br />
Notes:<br />
** Important: The ioctl operation is not 'deny all' ioctl requests (hence whitelisting). It is targeted at the specific source/target/class set of ioctl commands. As no other allowxperm rules have been defined in the example, all other ioctl calls may continue to use any valid request parameters (provided there are allow rules for the ioctl permission).<br />
** As the <tt>'''ioctl'''(2)</tt> function requires a file descriptor, its context must match the process context otherwise the <tt>fd { use }</tt> class/permission is required.<br />
** To deny all ioctl requests for a specific source/target/class the xperm_set can be set to '0' or '0x0'.<br />
** This feature is implemented in Android kernels (e.g. android-goldfish-3.4) and is available in Linux kernels > 4.2-rc2.<br />
Note that Android M is built with an ealier version (see thread [http://marc.info/?l=seandroid-list&m=143436044512043&w=2 http://marc.info/?l=seandroid-list&m=143436044512043&w=2]) that uses the following rule format:<br />
<pre><br />
# Allow SIOCGIFNAME (get iface name) ioctl requests on udp_socket for untrusted_app<br />
allow untrusted_app self:udp_socket 0x8910;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[AVCRules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XpermRulesXpermRules2015-07-21T11:02:39Z<p>RichardHaines: /* ioctl Operation Rules */</p>
<hr />
<div>= Extended Permission Access Vector Rules =<br />
There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments: <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt>.<br />
<br />
The rules for extended permissions are subject to the <tt>operation</tt> they perform with Policy version 30 supporting ioctl whitelisting.<br />
<br />
'''The common format for Extended Access Vector Rules are:'''<br />
<pre><br />
rule_name source_type target_type : class operation xperm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable <tt>allowxperm</tt>, <tt>dontauditxperm</tt> or <tt>auditallowxperm</tt> rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| operation<br />
| A key word defining the operation to be implemented by the rule. Currently only the ioctl operation is supported by the language and kernel as described in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|-<br />
| xperm_set<br />
| One or more extended permissions represented by numeric values (i.e. 0x8900 or 35072). The usage is dependant on the specified operation.<br />
<br />
Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed.<br />
<br />
The range operator (-) is used to specify all permissions within the low – high range.<br />
<br />
An example is shown in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|}<br />
<br />
<br />
== ioctl Operation Rules ==<br />
Use cases and implementation details for ioctl command whitelisting are described in detail at [http://marc.info/?l=selinux&m=143336061925628&w=2 http://marc.info/?l=selinux&m=143336061925628&w=2], with the final policy format changes shown in the example below with a brief overview (also see [http://marc.info/?l=selinux&m=143412575302369&w=2 http://marc.info/?l=selinux&m=143412575302369&w=2]) that is the final upstream kernel patch).<br />
Ioctl calls are generally used to get or set device options. Policy versions < 30 only controls whether an ioctl permission is allowed or not, for example this rule allows the object class tcp_socket the ioctl permission:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
</pre><br />
<br />
From Policy version 30 it is possible to control <tt>'''ioctl'''(2)</tt> 'request' parameters provided the ioctl permission is also allowed, for example:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
<br />
allowxperm src_t tgt_t : tcp_socket ioctl ~0x8927;<br />
</pre><br />
<br />
The allowxperm rule states that all ioctl request parameters are allowed for the source/target/class with the exception of the value 0x8927 that (using <tt>include/linux/sockios.h</tt>) is <tt>SIOCGIFHWADDR</tt>, or 'get hardware address'.<br />
<br />
An example deny ioctl request SIOCADDRT (add routing table entry) for goldfish_setup on a udp_socket is:<br />
<pre><br />
type=1400 audit(1437408413.860:6): avc: denied { ioctl } for pid=81 comm="route" path="socket:[1954]" dev="sockfs" ino=1954 ioctlcmd=890b scontext=u:r:goldfish_setup:s0 tcontext=u:r:goldfish_setup:s0 tclass=udp_socket permissive=0<br />
</pre><br />
<br />
Notes:<br />
** The ioctl operation is not 'deny all' ioctl requests (hence whitelisting). It is targeted at the specific source/target/class set of ioctl commands. As no other allowxperm rules have been defined in the example, all other ioctl calls may continue to use any valid request parameters (provided there are allow rules for the ioctl permission).<br />
** As the <tt>'''ioctl'''(2)</tt> function requires a file descriptor, its context must match the process context otherwise the <tt>fd { use }</tt> class/permission is required.<br />
** To deny all ioctl requests for a specific source/target/class the xperm_set can be set to '0' or '0x0'.<br />
** This feature is implemented in Android kernels (e.g. android-goldfish-3.4) and is available in Linux kernels > 4.2-rc2.<br />
Note that Android M is built with an ealier version (see thread [http://marc.info/?l=seandroid-list&m=143436044512043&w=2 http://marc.info/?l=seandroid-list&m=143436044512043&w=2]) that uses the following rule format:<br />
<pre><br />
# Allow SIOCGIFNAME (get iface name) ioctl requests on udp_socket for untrusted_app<br />
allow untrusted_app self:udp_socket 0x8910;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[AVCRules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/AVCRulesAVCRules2015-07-21T11:01:24Z<p>RichardHaines: /* Access Vector Rules */</p>
<hr />
<div>= Access Vector Rules =<br />
The AV rules define what access control privileges are allowed for processes. There are four types of AV rule: allow, dontaudit, auditallow, and neverallow as explained in the sections that follow with a number of examples to cover all the scenarios. There is also an auditdeny rule, however it is no longer used in the Reference Policy and has been replaced by the dontaudit rule.<br />
<br />
From Policy version 30 with the target platform <tt>selinux</tt>, the AVC rules have been extended to expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments. The format of the new <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt> rules are discussed in the [[XpermRules | Extended Permission Access Vector Rules]] section.<br />
<br />
The general format of an AV rule is that the source_type is the identifier of a process that is attempting to access an object identifier target_type, that has an object class of class, and perm_set defines the access permissions source_type is allowed.<br />
<br />
'''The common format of the Access Vector Rule is:'''<br />
<pre><br />
rule_name source_type target_type : class perm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable allow, dontaudit, auditallow, and neverallow rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
The neverallow rule also supports the wildcard operator (<nowiki>*</nowiki>) to specify that all types are to be included and the complement operator (~) to specify all types are to be included except those explicitly listed.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| perm_set<br />
| The access permissions the source is allowed to access for the target object (also known as the Acess Vector). Multiple entries consist of a space separated list enclosed in braces ({}). <br />
<br />
The optional wildcard operator (<nowiki>*</nowiki>) specifies that all permissions for the object class can be used. <br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed (although the compiler issues a warning if the dontaudit rule has '~').<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| '''allow = Yes'''<br />
<br />
'''auditallow = Yes'''<br />
<br />
'''dontaudit = Yes'''<br />
<br />
'''neverallow = No'''<br />
| '''allow = Yes'''<br />
<br />
'''auditallow = Yes'''<br />
<br />
'''dontaudit = Yes'''<br />
<br />
'''neverallow = Yes'''<br />
| '''allow = No'''<br />
<br />
'''auditallow = No'''<br />
<br />
'''dontaudit = No'''<br />
<br />
'''neverallow = No'''<br />
<br />
|}<br />
<br />
<br />
== allow ==<br />
The allow rule checks whether the operations between the source_type and target_type are allowed for the class and permissions defined. It is the most common statement that many of the Reference Policy helper macros and interface definitions expand into multiple allow rules.<br />
<br />
'''Examples:'''<br />
<pre><br />
# Using the allow rule to show that initrc_t is allowed access <br />
# to files of type acct_exec_t that have the getattr, read and <br />
# execute file permissions:<br />
<br />
allow initrc_t acct_exec_t:file { getattr read execute };<br />
</pre><br />
<pre><br />
# This rule includes an attribute filesystem_type and states <br />
# that kernel_t is allowed mount permissions on the filesystem<br />
# object for all types associated to the filesystem_type <br />
# attribute:<br />
<br />
allow kernel_t filesystem_type:filesystem mount;<br />
</pre><br />
<pre><br />
# This rule includes the self keyword in the target_type that<br />
# states that staff_t is allowed setgid, chown and fowner <br />
# permissions on the capability object:<br />
<br />
allow staff_t self:capability { setgid chown fowner };<br />
</pre><br />
<pre><br />
# This would be the same as the above:<br />
allow staff_t staff_t:capability { setgid chown fowner };<br />
</pre><br />
<pre><br />
# This rule includes the wildcard operator (*) on the perm_set<br />
# and states that bootloader_t is allowed to use all permissions<br />
# available on the dbus object that are type system_dbusd_t:<br />
<br />
allow bootloader_t system_dbusd_t:dbus *;<br />
</pre><br />
<pre><br />
# This would be the same as the above:<br />
allow bootloader_t system_dbusd_t:dbus { acquire_svc send_msg };<br />
</pre><br />
<pre><br />
# This rule includes the complement operator (~) on the perm_set<br />
# and two class entries file and chr_file.<br />
#<br />
# The allow rule states that all types associated with the <br />
# attribute files_unconfined_type are allowed to use all <br />
# permissions available on the file and chr_file objects '''except'''<br />
# the execmod permission when they are associated to the types <br />
# listed within the attribute file_type:<br />
<br />
allow files_unconfined_type file_type:{ file chr_file } ~execmod;<br />
</pre><br />
<br />
== dontaudit ==<br />
The dontaudit rule stops the auditing of denial messages as it is known that this event always happens and does not cause any real issues. This also helps to manage the audit log by excluding known events.<br />
<br />
'''Example:'''<br />
<pre><br />
# Using the dontaudit rule to stop auditing events that are <br />
# known to happen. The rule states that when the traceroute_t <br />
# process is denied access to the name_bind permission on a <br />
# tcp_socket for all types associated to the port_type <br />
# attribute (except port_t), then do not audit the event:<br />
<br />
dontaudit traceroute_t { port_type -port_t }:tcp_socket name_bind;<br />
</pre><br />
<br />
== auditallow ==<br />
Audit the event as a record as it is useful for auditing purposes. Note that this rule only audits the event, it still requires the allow rule to grant permission.<br />
<br />
'''Example:'''<br />
<pre><br />
# Using the auditallow rule to force an audit event to be <br />
# logged. The rule states that when the ada_t process has # permission to execstack, then that event must be audited:<br />
<br />
auditallow ada_t self:process execstack;<br />
</pre><br />
<br />
== neverallow ==<br />
This rule specifies that an <tt>allow</tt> rule must not be generated for the operation, even if it has been previously allowed. The neverallow statement is a compiler enforced action, where the checkpolicy or checkmodule<ref name="ftn46"><sup><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.'''</sup></ref> compiler checks if any allow rules have been generated in the policy source, if so it will issue a warning and stop.<br />
<br />
'''Examples''':<br />
<pre><br />
# Using the neverallow rule to state that no allow rule may ever<br />
# grant any file read access to type shadow_t except those <br />
# associated with the can_read_shadow_passwords attribute:<br />
<br />
neverallow ~can_read_shadow_passwords shadow_t:file read;<br />
</pre><br />
<pre><br />
# Using the neverallow rule to state that no allow rule may ever<br />
# grant mmap_zero permissions any type associated to the domain <br />
# attribute except those associated to the mmap_low_domain_type<br />
# attribute (as these have been excluded by the negative <br />
# operator (-)):<br />
<br />
neverallow { domain -mmap_low_domain_type } self:memprotect mmap_zero;<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[Bounds Rules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XpermRulesXpermRules2015-07-21T10:58:48Z<p>RichardHaines: New page: = Extended Permission Access Vector Rules = There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permis...</p>
<hr />
<div>= Extended Permission Access Vector Rules =<br />
There are three extended permission AV rules implemented from Policy version 30 with the target platform <tt>selinux</tt> that expand the permission sets from a fixed 32 bits to permission sets in 256 bit increments: <tt>allowxperm</tt>, <tt>dontauditxperm</tt> and <tt>auditallowxperm</tt>.<br />
<br />
The rules for extended permissions are subject to the <tt>operation</tt> they perform with Policy version 30 supporting ioctl whitelisting.<br />
<br />
'''The common format for Extended Access Vector Rules are:'''<br />
<pre><br />
rule_name source_type target_type : class operation xperm_set;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| rule_name<br />
| The applicable <tt>allowxperm</tt>, <tt>dontauditxperm</tt> or <tt>auditallowxperm</tt> rule keyword.<br />
<br />
|-<br />
| source_type<br />
<br />
target_type<br />
| One or more source / target type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).<br />
<br />
The target_type can have the self keyword instead of type, typealias or attribute identifiers. This means that the target_type is the same as the source_type.<br />
<br />
|-<br />
| class<br />
| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
|-<br />
| operation<br />
| A key word defining the operation to be implemented by the rule. Currently only the ioctl operation is supported by the language and kernel as described in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|-<br />
| xperm_set<br />
| One or more extended permissions represented by numeric values (i.e. 0x8900 or 35072). The usage is dependant on the specified operation.<br />
<br />
Multiple entries consist of a space separated list enclosed in braces ({}).<br />
<br />
The complement operator (~) is used to specify all permissions except those explicitly listed.<br />
<br />
The range operator (-) is used to specify all permissions within the low – high range.<br />
<br />
An example is shown in the [[#ioctl Operation Rules | ioctl Operation Rules]] section.<br />
<br />
|}<br />
<br />
<br />
'''The statements are valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
<br />
|}<br />
<br />
<br />
== ioctl Operation Rules ==<br />
Use cases and implementation details for ioctl command whitelisting are described in detail at [http://marc.info/?l=selinux&m=143336061925628&w=2 http://marc.info/?l=selinux&m=143336061925628&w=2], with the final policy format changes shown in the example below with a brief overview (also see [http://marc.info/?l=selinux&m=143412575302369&w=2 http://marc.info/?l=selinux&m=143412575302369&w=2]) that is the final upstream kernel patch).<br />
Ioctl calls are generally used to get or set device options. Policy versions < 30 only controls whether an ioctl permission is allowed or not, for example this rule allows the object class tcp_socket the ioctl permission:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
</pre><br />
<br />
From Policy version 30 it is possible to control <tt>'''ioctl'''(2)</tt> 'request' parameters provided the ioctl permission is also allowed, for example:<br />
<pre><br />
allow src_t tgt_t : tcp_socket ioctl;<br />
<br />
allowxperm src_t tgt_t : tcp_socket ioctl ~0x8927;<br />
</pre><br />
<br />
The allowxperm rule states that all ioctl request parameters are allowed for the source/target/class with the exception of the value 0x8927 that (using <tt>include/linux/sockios.h</tt>) is <tt>SIOCGIFHWADDR</tt>, or 'get hardware address'.<br />
<br />
An example deny ioctl request SIOCADDRT (add routing table entry) for goldfish_setup on a udp_socket is:<br />
<pre><br />
type=1400 audit(1437408413.860:6): avc: denied { ioctl } for pid=81 comm="route" path="socket:[1954]" dev="sockfs" ino=1954 ioctlcmd=890b scontext=u:r:goldfish_setup:s0 tcontext=u:r:goldfish_setup:s0 tclass=udp_socket permissive=0<br />
</pre><br />
<br />
Notes:<br />
** Important: The ioctl operation is not 'deny all' ioctl requests (hence whitelisting). It is targeted at the specific source/target/class set of ioctl commands. As no other allowxperm rules have been defined in the example, all other ioctl calls may continue to use any valid request parameters (provided there are allow rules for the ioctl permission).<br />
** As the <tt>'''ioctl'''(2)</tt> function requires a file descriptor, its context must match the process context otherwise the <tt>fd { use }</tt> class/permission is required.<br />
** To deny all ioctl requests for a specific source/target/class the xperm_set can be set to '0' or '0x0'.<br />
** This feature is implemented in Android kernels (e.g. android-goldfish-3.4) and is available in Linux kernels > 4.2-rc2.<br />
Note that Android M is built with an ealier version (see thread [http://marc.info/?l=seandroid-list&m=143436044512043&w=2 http://marc.info/?l=seandroid-list&m=143436044512043&w=2]) that uses the following rule format:<br />
<pre><br />
# Allow SIOCGIFNAME (get iface name) ioctl requests on udp_socket for untrusted_app<br />
allow untrusted_app self:udp_socket 0x8910;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[AVCRules | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[ObjectClassStatements | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NewUsersNewUsers2015-07-21T10:56:11Z<p>RichardHaines: /* Notebook Sections */</p>
<hr />
<div>This is a resource for new users, it explains in very broad terms what SELinux does, how to get it and so on.<br />
<br />
= What does SELinux do? =<br />
<br />
SELinux controls access between applications and resources. By using a [[Mandatory Access Control|mandatory]] security policy SELinux enforces the security goals of the system regardless of whether applications misbehave or users act carelessly.<br />
SELinux is capable of enforcing a wide range of security goals, from simply sandboxing applications to locking down network facing daemons and restricting users to only the resources they need to work.<br />
<br />
= How do I know if SELinux is on? =<br />
If you use Red Hat Enterprise Linux or Fedora it is enabled by default. To see whether it is actively enforcing the policy you can run getenforce:<br />
<br />
[root@localhost ~]# getenforce<br />
Enforcing<br />
<br />
If it says Enforcing (as above) your system is being protected by SELinux. If it says permissive SELinux is enabled but is only logging failed accesses, not denying them. If it says Disabled then SELinux is not enabled on your system.<br />
<br />
=How do I get it? =<br />
SELinux isn't a distribution by itself but a security enhancement to Linux that can be enabled by your distribution or vendor (or yourself if you are very motivated). <br />
<br />
{|<br />
! Distribution<br />
! How to get it<br />
|-<br />
||Red Hat Enterprise Linux (4+)<br />
||Default<br />
|-<br />
||Fedora (2+)<br />
||Default<br />
|-<br />
||Ubuntu<br />
||Hardened Ubuntu<br />
|-<br />
||Debian<br />
||add-on<br />
|-<br />
||Gentoo<br />
||Hardened Gentoo<br />
|}<br />
<br />
<br />
= Why do I have it? =<br />
<br />
Your distribution or vendor may have chosen to enable SELinux by default. They are doing this because they want added security protections on the versions of Linux they ship. A huge amount of effort has gone in to creating security policies that protect your system from intrusions while at the same time allowing users to behave the way they normally do. Leaving SELinux enabled on these systems is a good idea because it can protect you from zero-day and known vulnerabilities while balancing your need to use your system the way you need to.<br />
<br />
= Where can I find help? =<br />
<br />
There are several mailing lists and IRC channels depending on what distribution you are running and what you need help with. See the [[User_Help | Mailing lists and IRC channels]] page for a full list.<br />
<br />
This site has additional documentation that can help you use SELinux. You can start with the [[AdminDocs | administrators and users]] page.<br />
<br />
<br />
= The SELinux Notebook =<br />
Some of the sections from [http://freecomputerbooks.com/The-SELinux-Notebook-The-Foundations.html The SELinux Notebook - 4th Edition] are available on this site. There is also a supporting source tarball (notebook-source-4.0.tar.gz) available to download that demonstrates some of the SELinux capabilities. <br />
<br />
== Notebook Sections ==<br />
The major sections are:<br />
* [[NB_Overview | SELinux Overview]]<br />
* [[NB_CoreComponents | Core Components]]<br />
* [[NB_MAC | Mandatory Access Control (MAC)]]<br />
* [[NB_USERS | SELinux Users]]<br />
* [[NB_RBAC | Role-Based Access Control (RBAC)]]<br />
* [[NB_TE | Type Enforcement (TE)]]<br />
* [[NB_SC | Security Context]]<br />
* [[NB_Subjects | Subjects]]<br />
* [[NB_Objects | Objects]]<br />
* [[NB_ComputingSecurityContexts | Computing Security Contexts]]<br />
* [[NB_ComputingAccessDecisions | Computing Access Decisions]]<br />
* [[NB_Domain_and_Object_Transitions | Domain and Object Transitions]]<br />
* [[NB_MLS | Multi-Level Security and Multi-Category Security]]<br />
* [[NB_PolicyType | Types of SELinux Policy]]<br />
* [[NB_PandE | Permissive and Enforcing Modes]]<br />
* [[NB_AL | Auditing Events]]<br />
* [[NB_Poly | Polyinstantiation Support]]<br />
* [[NB_PAM | PAM Login Process]]<br />
* [[NB_LSM | Linux Security Module and SELinux]]<br />
* [[NB_Userspace_Libraries | SELinux Userspace Libraries]]<br />
* [[NB_Networking | SELinux Networking Support]]<br />
* [[NB_VM | SELinux Virtual Machine Support]]<br />
* [[NB_XWIN | SELinux X-Windows Support]]<br />
* [[NB_SandBox | Sandbox Services]]<br />
* [[NB_SQL_9.3 | SE-PostgreSQL Support]]<br />
* [[NB_Apache | Apache-Plus Support]]<br />
* [[ConfigurationFiles | SELinux Configuration Files]]<br />
** [[GlobalConfigurationFiles | Global Configuration Files]]<br />
** [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]]<br />
** [[PolicyConfigurationFiles | Policy Configuration Files]]<br />
* [[PolicyLanguage | The SELinux Policy Languages]]<br />
** [[PolicyLanguage#CIL_Policy_Language | CIL Policy Language]]<br />
** [[PolicyLanguage#Kernel_Policy_Language | Kernel Policy Language]]<br />
*** [[Policy Configuration Statements | Policy Configuration Statements]]<br />
*** [[DefaultRules | Default Rules]]<br />
*** [[UserStatements | User Statements]]<br />
*** [[RoleStatements | Role Statements]]<br />
*** [[TypeStatements | Type Statements]]<br />
*** [[Bounds Rules | Bounds Rules]]<br />
*** [[AVCRules | Access Vector Rules]]<br />
*** [[XpermRules | Extended Permission Access Vector Rules]]<br />
*** [[ObjectClassStatements | Object Class and Permission Statements]]<br />
*** [[ConditionalStatements | Conditional Policy Statements]]<br />
*** [[ConstraintStatements | Constraint Statements]]<br />
*** [[MLSStatements | MLS Statements]]<br />
*** [[SIDStatements | Security ID (SID) Statement]]<br />
*** [[FileStatements | File System Labeling Statements]]<br />
*** [[NetworkStatements | Network Labeling Statements]]<br />
*** [[PolicyStatements | Modular Policy Support Statements]]<br />
*** [[XENStatements | XEN Statements]]<br />
* [[NB_RefPolicy | The Reference Policy]]<br />
* [[NB_Imp_SELinux-aware_Apps | Implementing SELinux-aware Applications]]<br />
* [[NB_SEforAndroid_1 | SE for Android]]<br />
* [[LibselinuxAPISummary | <tt>libselinux</tt> API Summary]]<br />
* [[NB_ObjectClassesPermissions | Object Classes and Permissions]]</div>RichardHaineshttp://selinuxproject.org/page/XENStatementsXENStatements2015-03-19T15:31:50Z<p>RichardHaines: /* Xen Statements */</p>
<hr />
<div>= Xen Statements =<br />
Xen policy supports additional policy language statements: <tt>iomemcon</tt>, <tt>ioportcon</tt>, <tt>pcidevicecon</tt>, <tt>pirqcon</tt> and <tt>devicetreecon</tt> that are discussed in the sections that follow, also the [http://xenbits.xen.org/docs/4.2-testing/misc/xsm-flask.txt XSM/FLASK Configuration] document contains further information.<br />
<br />
Policy version 30 introduced the <tt>[[#devicetreecon | devicetreecon]]</tt> statement and also expanded the existing I/O memory range to 64 bits in order to support hardware with more than 44 bits of physical address space (32-bit count of 4K pages).<br />
<br />
To compile these additional statements using <tt>'''semodule'''(8)</tt>, ensure that the <tt>'''semanage.conf'''(5)</tt> file has the <tt>policy-target=xen</tt> entry.<br />
<br />
== iomemcon ==<br />
Label i/o memory. This may be a single memory location or a range.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
iomemcon addr context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| iomemcon<br />
| The iomemcon keyword.<br />
<br />
|-<br />
| addr<br />
| The memory address to apply the context. This may also be a range that consists of a start and end address separated by a hypen (<tt>-</tt>).<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
iomemcon 0xfebd9 system_u:object_r:nicP_t<br />
iomemcon 0xfebe0-0xfebff system_u:object_r:nicP_t<br />
</pre><br />
<br />
<br />
== ioportcon ==<br />
Label i/o ports. This may be a single port or a range.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
ioportcon port context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| ioportcon<br />
| The ioportcon keyword.<br />
<br />
|-<br />
| port<br />
| The port to apply the context. This may also be a range that consists of a start and end port number separated by a hypen (<tt>-</tt>).<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
ioportcon 0xeac0 system_u:object_r:nicP_t<br />
ioportcon 0xecc0-0xecdf system_u:object_r:nicP_t<br />
</pre><br />
<br />
<br />
== pcidevicecon ==<br />
Label a PCI device.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
pcidevicecon pci_id context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pcidevicecon<br />
| The pcidevicecon keyword.<br />
<br />
|-<br />
| pci_id<br />
| The PCI indentifer.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
pcidevicecon 0xc800 system_u:object_r:nicP_t<br />
</pre><br />
<br />
<br />
== pirqcon ==<br />
Label an interrupt level.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
pirqcon irq context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pirqcon<br />
| The pirqcon keyword.<br />
<br />
|-<br />
| irq<br />
| The interrupt request number.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
pirqcon 33 system_u:object_r:nicP_t<br />
</pre><br />
<br />
== devicetreecon ==<br />
Label device tree nodes.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
devicetreecon path context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| devicetreecon<br />
| The devicetreecon keyword.<br />
<br />
|-<br />
| path<br />
| the device tree path. If this contains spaces enclose within "".<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
devicetreecon "/this is/a/path" system_u:object_r:arm_path<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[PolicyStatements | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_RefPolicy | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XENStatementsXENStatements2015-03-19T15:25:27Z<p>RichardHaines: </p>
<hr />
<div>= Xen Statements =<br />
Xen policy supports additional policy language statements: <tt>iomemcon</tt>, <tt>ioportcon</tt>, <tt>pcidevicecon</tt> and <tt>pirqcon</tt> that are discussed in the sections that follow.<br />
<br />
Policy version 30 introduced the <tt>[[#devicetreecon | devicetreecon]]</tt> statement and also expanded the existing I/O memory range to 64 bits in order to support hardware with more than 44 bits of physical address space (32-bit count of 4K pages).<br />
<br />
To compile these additional statements using <tt>'''semodule'''(8)</tt>, ensure that the <tt>'''semanage.conf'''(5)</tt> file has the <tt>policy-target=xen</tt> entry.<br />
<br />
== iomemcon ==<br />
Label i/o memory. This may be a single memory location or a range.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
iomemcon addr context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| iomemcon<br />
| The iomemcon keyword.<br />
<br />
|-<br />
| addr<br />
| The memory address to apply the context. This may also be a range that consists of a start and end address separated by a hypen (<tt>-</tt>).<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
iomemcon 0xfebd9 system_u:object_r:nicP_t<br />
iomemcon 0xfebe0-0xfebff system_u:object_r:nicP_t<br />
</pre><br />
<br />
<br />
== ioportcon ==<br />
Label i/o ports. This may be a single port or a range.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
ioportcon port context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| ioportcon<br />
| The ioportcon keyword.<br />
<br />
|-<br />
| port<br />
| The port to apply the context. This may also be a range that consists of a start and end port number separated by a hypen (<tt>-</tt>).<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
ioportcon 0xeac0 system_u:object_r:nicP_t<br />
ioportcon 0xecc0-0xecdf system_u:object_r:nicP_t<br />
</pre><br />
<br />
<br />
== pcidevicecon ==<br />
Label a PCI device.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
pcidevicecon pci_id context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pcidevicecon<br />
| The pcidevicecon keyword.<br />
<br />
|-<br />
| pci_id<br />
| The PCI indentifer.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
pcidevicecon 0xc800 system_u:object_r:nicP_t<br />
</pre><br />
<br />
<br />
== pirqcon ==<br />
Label an interrupt level.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
pirqcon irq context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pirqcon<br />
| The pirqcon keyword.<br />
<br />
|-<br />
| irq<br />
| The interrupt request number.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
pirqcon 33 system_u:object_r:nicP_t<br />
</pre><br />
<br />
== devicetreecon ==<br />
Label device tree nodes.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
devicetreecon path context<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| devicetreecon<br />
| The devicetreecon keyword.<br />
<br />
|-<br />
| path<br />
| the device tree path. If this contains spaces enclose within "".<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
devicetreecon "/this is/a/path" system_u:object_r:arm_path<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[PolicyStatements | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_RefPolicy | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XENStatementsXENStatements2015-03-18T17:26:08Z<p>RichardHaines: </p>
<hr />
<div>= Xen Statements =<br />
Xen policy supports additional policy language statements: <tt>iomemcon</tt>, <tt>ioportcon</tt>, <tt>pcidevicecon</tt> and <tt>pirqcon</tt> that are discussed in the sections that follow.<br />
<br />
Policy version 30 introduced the <tt>[[#devicetreecon | devicetreecon]]</tt> statement and also expanded the existing I/O memory range to 64 bits in order to support hardware with more than 44 bits of physical address space (32-bit count of 4K pages).<br />
<br />
To compile these additional statements using <tt>'''semodule'''(8)</tt>, ensure that the <tt>'''semanage.conf'''(5)</tt> file has the <tt>policy-target=xen</tt> entry.<br />
<br />
== iomemcon ==<br />
Label i/o memory. This may be a single memory location or a range.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
iomemcon addr context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| iomemcon<br />
| The iomemcon keyword.<br />
<br />
|-<br />
| addr<br />
| The memory address to apply the context. This may also be a range that consists of a start and end address separated by a hypen (<tt>-</tt>).<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
iomemcon 0xfebd9 system_u:object_r:nicP_t;<br />
<br />
iomemcon 0xfebe0-0xfebff system_u:object_r:nicP_t;<br />
</pre><br />
<br />
<br />
== ioportcon ==<br />
Label i/o ports. This may be a single port or a range.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
ioportcon port context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| ioportcon<br />
| The ioportcon keyword.<br />
<br />
|-<br />
| port<br />
| The port to apply the context. This may also be a range that consists of a start and end port number separated by a hypen (<tt>-</tt>).<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
ioportcon 0xeac0 system_u:object_r:nicP_t;<br />
<br />
ioportcon 0xecc0-0xecdf system_u:object_r:nicP_t;<br />
</pre><br />
<br />
<br />
== pcidevicecon ==<br />
Label a PCI device.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
pcidevicecon pci_id context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pcidevicecon<br />
| The pcidevicecon keyword.<br />
<br />
|-<br />
| pci_id<br />
| The PCI indentifer.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
pcidevicecon 0xc800 system_u:object_r:nicP_t;<br />
</pre><br />
<br />
<br />
== pirqcon ==<br />
Label an interrupt level.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
pirqcon irq context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pirqcon<br />
| The pirqcon keyword.<br />
<br />
|-<br />
| irq<br />
| The interrupt request number.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
pirqcon 33 system_u:object_r:nicP_t;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[PolicyStatements | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_RefPolicy | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/XENStatementsXENStatements2015-03-18T16:32:45Z<p>RichardHaines: </p>
<hr />
<div>= Xen Statements =<br />
Xen policy supports additional policy language statements: <tt>iomemcon</tt>, <tt>ioportcon</tt>, <tt>pcidevicecon</tt> and <tt>pirqcon</tt> that are discussed in the sections that follow.<br />
<br />
Policy version 30 introduced the <tt>[[#devicetreecon | devicetreecon]]</tt> statement and also expanded the existing I/O memory range to 64 bits in order to support hardware with more than 44 bits of physical address space (32-bit count of 4K pages).<br />
<br />
To compile these additional statements using <tt>'''semodule'''(8)</tt>, ensure that the <tt>'''semanage.conf'''(5)</tt> file has the <tt>policy-target=xen</tt> entry.<br />
<br />
== iomemcon ==<br />
Label i/o memory. This may be a single memory location or a range.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
iomemcon addr context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| iomemcon<br />
| The iomemcon keyword.<br />
<br />
|-<br />
| addr<br />
| The memory address to apply the context. This may also be a range that consists of a start and end address separated by a hypen (<tt>-</tt>).<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
iomemcon 0xfebd9 system_u:object_r:nicP_t;<br />
<br />
iomemcon 0xfebe0-0xfebff system_u:object_r:nicP_t;<br />
</pre><br />
<br />
<br />
== ioportcon ==<br />
Label i/o ports. This may be a single port or a range.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
ioportcon port context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| ioportcon<br />
| The ioportcon keyword.<br />
<br />
|-<br />
| port<br />
| The port to apply the context. This may also be a range that consists of a start and end port number separated by a hypen (<tt>-</tt>).<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
ioportcon 0xeac0 system_u:object_r:nicP_t;<br />
<br />
ioportcon 0xecc0-0xecdf system_u:object_r:nicP_t;<br />
</pre><br />
<br />
<br />
== pcidevicecon ==<br />
Label a PCI device.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
pcidevicecon pci_id context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pcidevicecon<br />
| The pcidevicecon keyword.<br />
<br />
|-<br />
| pci_id<br />
| The PCI indentifer.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
pcidevicecon 0xc800 system_u:object_r:nicP_t;<br />
</pre><br />
<br />
<br />
== pirqcon ==<br />
Label an interrupt level.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
pirqcon irq context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| pirqcon<br />
| The pirqcon keyword.<br />
<br />
|-<br />
| irq<br />
| The interrupt request number.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
pirqcon 33 system_u:object_r:nicP_t;<br />
</pre><br />
<br />
== devicetreecon ==<br />
Label device tree nodes.<br />
<br />
'''The statement definition is:'''<br />
<pre><br />
devicetreecon path context;<br />
</pre><br />
<br />
'''Where:'''<br />
<br />
{| border="1"<br />
| devicetreecon<br />
| The devicetreecon keyword.<br />
<br />
|-<br />
| path<br />
| the device tree path.<br />
<br />
|-<br />
| context<br />
| The security context to be applied.<br />
<br />
|}<br />
<br />
<br />
'''The statement is valid in:'''<br />
<br />
{| border="1"<br />
|<center>'''Monolithic Policy'''</center><br />
|<center>'''Base Policy'''</center><br />
|<center>'''Module Policy'''</center><br />
<br />
|-<br />
| <center>'''Yes'''</center><br />
| <center>'''Yes'''</center><br />
| <center>'''No'''</center><br />
<br />
|-<br />
| <center>[[ConditionalStatements#if | if Statement]]</center><br />
| <center>[[PolicyStatements#optional | optional Statement]] </center><br />
| <center>[[PolicyStatements#require | require Statement]] </center><br />
<br />
|-<br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
| <center>'''No'''</center><br />
<br />
|}<br />
<br />
<br />
'''Example:'''<br />
<pre><br />
devicetreecon "/this is/a/path" system_u:object_r:arm_path;<br />
</pre><br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[PolicyStatements | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_RefPolicy | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_SEforAndroid_2NB SEforAndroid 22015-03-17T11:41:31Z<p>RichardHaines: </p>
<hr />
<div>= Policy Configuration File Formats =<br />
This section details the Android policy configuration file formats with worked examples.<br />
<br />
The following files are described:<br />
* <tt>file_contexts<br />
* seapp_contexts<br />
* service_contexts<br />
* property_contexts<br />
* mac_permissions.xml<br />
* eops.xml<br />
* ifw.xml</tt><br />
<br />
== file_contexts ==<br />
This file is used to associate default contexts to files for file systems that support extended file attributes. It is used by the file labeling commands such as <tt>restorecon</tt>.<br />
<br />
The [[NB_SEforAndroid_1#Checking File Labels | Checking File Labels]] section describes how changes in this file are detected.<br />
<br />
The build process supports additional <tt>file_contexts</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Processing Device Policy | Processing Device Policy]] section.<br />
<br />
Each line within the file consists of the following:<br />
<pre><br />
pathname_regexp [file_type] security_context<br />
</pre><br />
<br />
'''Where:'''<br />
{| border="1"<br />
| <tt>pathname_regexp</tt><br />
| An entry that defines the pathname that may be in the form of a regular expression (see the example file_contexts file below). <br />
<br />
|-<br />
| <tt>file_type</tt><br />
| One of the following optional file_type entries (note if blank means "match all file types"):<br />
: '<tt>-b</tt>' - Block Device '<tt>-c</tt>' - Character Device<br />
: '<tt>-d</tt>' - Directory '<tt>-p</tt>' - Named Pipe (FIFO)<br />
: '<tt>-l</tt>' - Symbolic Link '<tt>-s</tt>' - Socket File<br />
: '<tt>--</tt>' - Ordinary file<br />
<br />
This entry equates to the file mode and also the file related object class (e.g. <tt>S_IFSOCK</tt> = <tt>sock_file</tt> class).<br />
<br />
|-<br />
| security_context<br />
| This entry can be either:<br />
* The security context that will be assigned to the file.<br />
* A value of <tt><nowiki><<none>></nowiki></tt> that states matching files should not be re-labeled. <br />
<br />
<br />
|}<br />
<br />
Example entries:<br />
<pre><br />
###########################################<br />
# Root<br />
/u:object_r:rootfs:s0<br />
<br />
# Data files<br />
/adb_keys u:object_r:adb_keys_file:s0<br />
/default\.prop u:object_r:rootfs:s0<br />
/fstab\..* u:object_r:rootfs:s0<br />
/init\..* u:object_r:rootfs:s0<br />
/res(/.*)? u:object_r:rootfs:s0<br />
/ueventd\..* u:object_r:rootfs:s0<br />
...<br />
##########################<br />
# Devices<br />
#<br />
/dev(/.*)? u:object_r:device:s0<br />
/dev/akm8973.* u:object_r:sensors_device:s0<br />
/dev/accelerometer u:object_r:sensors_device:s0<br />
/dev/adf[0-9]* u:object_r:graphics_device:s0<br />
/dev/adf-interface[0-9]*\.[0-9]* u:object_r:graphics_device:s0<br />
/dev/adf-overlay-engine[0-9]*\.[0-9]* u:object_r:graphics_device:s0<br />
...<br />
/dev/socket/adbd u:object_r:adbd_socket:s0<br />
/dev/socket/dnsproxyd u:object_r:dnsproxyd_socket:s0<br />
/dev/socket/dumpstate u:object_r:dumpstate_socket:s0<br />
...<br />
#############################<br />
# System files<br />
#<br />
/system(/.*)? u:object_r:system_file:s0<br />
/system/bin/sh -- u:object_r:shell_exec:s0<br />
/system/bin/run-as -- u:object_r:runas_exec:s0<br />
<br />
#############################<br />
# asec containers<br />
/mnt/asec(/.*)? u:object_r:asec_apk_file:s0<br />
/mnt/asec/[^/]+/res\.zip u:object_r:asec_public_file:s0<br />
/mnt/asec/[^/]+/lib(/.*)? u:object_r:asec_public_file:s0<br />
/data/app-asec(/.*)? u:object_r:asec_image_file:s0<br />
</pre><br />
<br />
These are example entries from <tt>device/asus/flo/sepolicy/file_contexts</tt>, note the '<tt>'''by-name'''</tt>' entry. This is resolved by <tt>ueventd</tt> as explained in the following commit:<br />
: [https://android.googlesource.com/platform/system/core/+/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a https://android.googlesource.com/platform/system/core/][https://android.googlesource.com/platform/system/core/+/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a +/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a]<br />
<pre><br />
# efs block labeling<br />
/dev/block/platform/msm_sdcc\.1/by-name/m9kefs[123c] u:object_r:efs_block_device:s0<br />
# Root block labeling<br />
/dev/block/mmcblk0 u:object_r:root_block_device:s0<br />
# modemst1, modemst2, fsg, ssd labeling<br />
/dev/block/platform/msm_sdcc\.1/by-name/modemst[12] u:object_r:modem_block_device:s0<br />
/dev/block/platform/msm_sdcc\.1/by-name/fsg u:object_r:modem_block_device:s0<br />
/dev/block/platform/msm_sdcc\.1/by-name/ssd u:object_r:modem_block_device:s0<br />
</pre><br />
<br />
It is also worth noting that the '<tt>'''by-name'''</tt>' (or '<tt>'''by-num'''</tt>') entry can exist in fstab files as shown in this example taken from <tt>device/asus/flo/fstab.flo</tt>:<br />
<pre><br />
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait<br />
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4<br />
</pre><br />
<br />
== seapp_contexts ==<br />
This file is loaded and sorted into memory using the precedence rules explained below on first use by of one of the following Android <tt>libselinux</tt> functions:<br />
* <tt>selinux_android_setcontext</tt> - Computes process security contexts.<br />
* <tt>selinux_android_setfilecon</tt> - Computes file/directory security contexts.<br />
<br />
The [[NB_SEforAndroid_1#Checking File Labels | Checking File Labels]] section describes how changes in this file are detected.<br />
<br />
The build process supports additional <tt>seapp_contexts</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Processing Device Policy | Processing Device Policy]] section.<br />
<br />
The following sections will show:<br />
# The default <tt>external/sepolicy/seapp_contexts</tt> file entries.<br />
# A description of the <tt>seapp_contexts</tt> entries and their usage.<br />
# A brief description of how a context is computed using either the <tt>selinux_android_setcontext</tt> or <tt>selinux_android_ setfilecon</tt> function using the <tt>seapp_contexts</tt> file entries.<br />
# Examples of computed domain and directory contexts for various apps.<br />
<br />
=== Default Entries ===<br />
The default Android <tt>external/sepolicy/seapp_contexts</tt> file contains the following entries:<br />
<pre><br />
isSystemServer=true domain=system_server<br />
user=system domain=system_app type=system_app_data_file<br />
user=bluetooth domain=bluetooth type=bluetooth_data_file<br />
user=nfc domain=nfc type=nfc_data_file<br />
user=radio domain=radio type=radio_data_file<br />
user=shared_relro domain=shared_relro<br />
user=shell domain=shell type=shell_data_file<br />
user=_isolated domain=isolated_app levelFrom=user<br />
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
</pre><br />
<br />
=== Entry Definitions ===<br />
The following has been extracted from the default file with some additional comments that describe the parameters and how they are used to compute a context:<br />
<br />
Input selectors from <tt>seapp_contexts</tt> file: <br />
: <tt>isSystemServer (boolean)</tt><br />
: <tt>isOwner (boolean)</tt><br />
: <tt>user (string)</tt><br />
: <tt>seinfo (string)</tt><br />
: <tt>name (string)</tt> - A package name e.g. <tt>com.example.demo</tt><br />
: <tt>path (string)</tt> - A path name (added to ensure correct labeling of some files).<br />
<br />
Notes:<br />
: <tt>isSystemServer=true</tt> can only be used once.<br />
: An unspecified <tt>isSystemServer</tt> defaults to false.<br />
: <tt>isOwner=true</tt> will only match for owner/primary user.<br />
: <tt>isOwner=false</tt> will only match for secondary users.<br />
: If unspecified, the entry can match either case.<br />
: An unspecified string selector will match any value.<br />
: A <tt>user</tt> string selector that ends in <tt><nowiki>*</nowiki></tt> will perform a prefix match.<br />
: <tt>user=_app</tt> will match any regular app UID.<br />
: <tt>user=_isolated</tt> will match any isolated service UID.<br />
: All specified input selectors in an entry must match (i.e. logical AND).<br />
: Matching is case-insensitive.<br />
<br />
Precedence rules:<br />
: 1) <tt>isSystemServer=true</tt> before <tt>isSystemServer=false</tt>.<br />
: 2) Specified <tt>isOwner=</tt> before unspecified <tt>isOwner=boolean</tt>. <br />
: 3) Specified <tt>user= string</tt> before unspecified <tt>user= string</tt>.<br />
: 4) Fixed <tt>user= string</tt> before <tt>user= prefix</tt> (i.e. ending in <tt><nowiki>*</nowiki></tt>).<br />
: 5) Longer <tt>user= prefix</tt> before shorter <tt>user= prefix</tt>. <br />
: 6) Specified <tt>seinfo= string</tt> before unspecified <tt>seinfo= string</tt>.<br />
: 7) Specified <tt>name= string</tt> before unspecified <tt>name= string</tt>.<br />
: 8) Specified <tt>path= string</tt> before unspecified <tt>path= string</tt>.<br />
<br />
Outputs:<br />
: <tt>domain (string)</tt> - The <tt>type</tt> component of a process context.<br />
: <tt>type (string)</tt> - The <tt>type</tt> component of a file/directory context.<br />
: <tt>levelFrom</tt> (<tt>string</tt><nowiki>; one of </nowiki><tt>none</tt>, <tt>all</tt>, <tt>app</tt>, or <tt>user</tt>) - A level that will be automatically computed based on the parameter.<br />
: <tt>level (string)</tt> - A predefined level (e.g. <tt>s0:c1022.c1023</tt>)<br />
<br />
Notes:<br />
: Only entries that specify <tt>domain=</tt> will be used for app process labeling.<br />
: Only entries that specify <tt>type=</tt> will be used for app directory labeling.<br />
: <tt>levelFrom=user</tt> is only supported for <tt>_app</tt> or <tt>_isolated</tt> UIDs.<br />
: <tt>levelFrom=app</tt> or <tt>levelFrom=all</tt> is only supported for <tt>_app</tt> UIDs.<br />
: <tt>level</tt> may be used to specify a fixed level for any UID. <br />
<br />
=== Computing a Context ===<br />
This section explains the process to compute a context using parameters supplied by the <tt>selinux_android_setcontext</tt>, <tt>selinux_android_setfilecon</tt>,<tt> selinux_android_restorecon</tt> and<tt> selinux_android_restorecon_pkgdir</tt> functions plus the precedence sorted contents of the <tt>seapp_contexts</tt> file, some examples are then shown.<br />
<br />
The context is computed first by converting the <tt>uid</tt> parameter to a string that is used to match the <tt>user</tt> component in the <tt>seapp_contexts</tt> entry as follows:<br />
# If an Android system service, the <tt>uid</tt> parameter is converted to a <tt>username</tt> string via an internal Android table (e.g. "radio", "system").<br />
# If an isolated service the <tt>_isolated</tt> string is used as the <tt>username</tt>.<br />
# For any other app or service <tt>_app</tt> string is used as the <tt>username</tt>.<br />
<br />
Then cycling through each precedence sorted <tt>seapp_contexts</tt> entry, check each component as follows until a match is found or generate an error log entry:<br />
<br />
* The <tt>isSystemServer</tt> component is matched against the <tt>isSystemServer</tt> parameter. If a match or <tt>isSystemServer</tt> not present check remaining components, else skip entry.<br />
* The <tt>isOwner</tt> boolean determines whether the remaining components should be checked or skip this entry. The rules are:<br />
** If <tt>isOwner</tt> not present then check remaining components.<br />
** If set <tt>true</tt> and the <tt>uid</tt> computes to the owner or primary user then check remaining components, else skip this entry.<br />
** If set <tt>false</tt> and the <tt>uid</tt> computes to a secondary user then check remaining components, else skip this entry.<br />
* The computed <tt>username</tt> is matched against the <tt>user</tt> component. If a match or <tt>user</tt> not present check remaining components, else skip entry. <br />
* The <tt>seinfo</tt> component is matched against the <tt>seinfo</tt> parameter. If a match or <tt>seinfo</tt> not present check remaining components, else skip entry.<br />
* The <tt>name</tt> component is matched against the <tt>pkgname</tt> parameter. If a match or <tt>name</tt> not present check remaining components, else skip entry. <br />
* The <tt>path</tt> component is matched against a computed path of a file having its context restored via one of the restorecon functions. If a match or <tt>path</tt> not present check remaining components, else skip entry. <br />
* The <tt>domain</tt> component is used to set the process context for the <tt>selinux_android_setcontext</tt> function and must match a type declared in the policy. If <tt>domain</tt> not present skip this entry.<br />
* The <tt>type</tt> component is used to set the file context for the <tt>selinux_android_setfilecon</tt> function and must match a type declared in the policy. If <tt>type</tt> not present skip this entry.<br />
* The <tt>levelFrom</tt> and <tt>level</tt> components if present will be used to determine the <tt>level</tt> component of the security context as follows:<br />
** if <tt>levelFrom=none</tt> then use current level.<br />
** else if <tt>levelFrom=app</tt> then compute a category pair based on a derived app id with a starting base of <tt>c512,c768</tt> base.<br />
** else if <tt>levelFrom=user</tt> then compute a category pair based on a derived user id with a starting base of <tt>c0,c256</tt> base.<br />
** else if <tt>levelFrom=all</tt> then compute a category pair based on a derived app id with a starting base of <tt>c512,c768</tt> base, and also compute another category pair based on a derived user id with a starting base of <tt>c0,c256</tt> base.<br />
** else if <tt>level</tt> has a value use this as the context level.<br />
<br />
The overall objective is that the computed levels should never be the same for different apps, users, or a combination of both. By encoding each ID as a category pair, up to 2^16 app IDs and up to 2^16 user IDs within the 1024 categories can be represented, including the <tt>levelFrom=all</tt> or mixed usage of <tt>levelFrom=app</tt> and <tt>levelFrom=user</tt>.<br />
<br />
If a valid entry is found, then:<br />
# If a context for the <tt>selinux_android_setcontext</tt> function has been computed, it is validated against policy, if correct <tt>'''setcon'''(3)</tt> is used to set the process context.<br />
# If a context for <tt>selinux_android_setfilecon</tt>, <tt>selinux_android_restorecon</tt> or<tt> selinux_android_restorecon_pkgdir</tt> functions have been computed, it is validated against policy, if correct <tt>'''setfilecon'''(3)</tt> or <tt>'''lsetfilecon'''(3)</tt> are used to set the context for labeling the file.<br />
<br />
If a valid entry is not found an error is generated in the log currently formatted as follows:<br />
: <tt>seapp_context_lookup: No match for app with uid uid, seinfo seinfo, name pkgname</tt><br />
<br />
==== Computing Process Context Examples ====<br />
The following is an example taken as the system server is loaded:<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 1000<br />
isSystemServer true<br />
seinfo null<br />
pkgname null<br />
<br />
seapp_contexts lookup parameters:<br />
uid 1000<br />
isSystemServer true<br />
seinfo null<br />
pkgname null<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
isSystemServer=true domain=system_server<br />
<br />
Outputs:<br />
domain system_server<br />
level s0<br />
<br />
Computed context = u:r:system_server:s0<br />
username computed from uid = system<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:system_server:s0 system 836 63 system_server<br />
</pre><br />
<br />
This is the ’radio’ application that is part of the platform:<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 1001<br />
isSystemServer false<br />
seinfo platform<br />
pkgname com.android.phone<br />
<br />
seapp_contexts lookup parameters:<br />
uid 1001 (computes user=radio entry)<br />
isSystemServer false<br />
seinfo platform<br />
pkgname com.android.phone<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=radio domain=radio type=radio_data_file<br />
<br />
Outputs:<br />
domain radio<br />
level s0<br />
<br />
Computed context = u:r:radio:s0<br />
username computed from uid = radio<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:radio:s0 radio 619 62 com.android.phone<br />
</pre><br />
<br />
This is the 'SEAndroid Admin Manager' application that is part of the SEAndroid release, however it is treated as an untrusted app (it is installed as a privileged app):<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 10013<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.android.seandroid_admin<br />
<br />
seapp_contexts lookup parameters:<br />
isSystemServer false<br />
uid 10013 (computes user=_app entry) <br />
seinfo default<br />
pkgname com.android.seandroid_admin<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
<br />
Outputs:<br />
domain untrusted_app<br />
level s0:c512,c768<br />
<br />
Computed context = u:r:untrusted_app:s0:c512,c768<br />
username computed from uid = u0_a13<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:untrusted_app:s0:c512,c768 u0_a13 827 45 com.android.seandroid_admin<br />
</pre><br />
<br />
This is a third party app (<tt>com.example.runisolatedservice</tt>) to run an isolated service that has been installed as a privileged app (<tt>com.se4android.isolatedservice</tt>):<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 10054<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.example.runisolatedservice<br />
<br />
seapp_contexts lookup parameters:<br />
uid 10054 (computes user=_app entry)<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.example.runisolatedservice<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
<br />
Outputs:<br />
domain untrusted_app<br />
level s0:c512,c768<br />
<br />
Computed context = u:r:untrusted_app:s0:c512,c768<br />
username computed from uid = u0_a54<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:untrusted_app:s0:c512,c768 u0_a54 1138 64 com.example.runisolatedservice<br />
</pre><br />
<br />
This is the isolated service installed as a privileged app (<tt>com.se4android.isolatedservice</tt>):<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 99000<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.se4android.isolatedservice<br />
<br />
seapp_contexts lookup parameters:<br />
uid 99000 (computes user=_isolated entry)<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.se4android.isolatedservice<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=_isolated domain=isolated_app levelFrom=user<br />
Note that uid's 99000-99999 are reserved for isolated services - see:<br />
system/core/include/private/android_filesystem_config.h<br />
<br />
Outputs:<br />
domain isolated_app<br />
level s0:c512,c768<br />
<br />
Computed context = u:r:isolated_app:s0:c512,c768<br />
username computed from uid = u0_i0<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:isolated_app:s0:c512,c768 u0_i0 1140 62 com.se4android.isolatedservice<br />
</pre><br />
<br />
==== Computing File Context Example ====<br />
The following example is from the third party isolated app:<br />
<pre><br />
selinux_android_setfilecon() parameters:<br />
pkgdir /data/data/com.example.runisolatedservice<br />
pkgname com.example.runisolatedservice<br />
seinfo default<br />
uid 10046<br />
<br />
seapp_contexts lookup parameters:<br />
uid 10046 (computes user=_app entry)<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.example.runisolatedservice<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
<br />
Outputs:<br />
type app_data_file<br />
level s0:c512,c768<br />
<br />
Computed context = u:object_r:app_data_file:s0:c512,c768<br />
username computed from uid = u0_a46<br />
<br />
Result from /data/data directory using ls -Z command:<br />
drwxr-x--x u0_a46 u0_a46 u:object_r:app_data_file:s0:c512,c768 com.example.runisolatedservice<br />
</pre><br />
<br />
== property_contexts ==<br />
This file holds property service keys and their contexts that are matched against property names using <tt>'''selabel_lookup'''(3)</tt>. The returned context will then be used as the target context as described in the example below to determine whether the property is allowed or denied (see <tt>system/core/init/property_service.c</tt> and <tt>init.c</tt>).<br />
<br />
The build process supports additional <tt>property_contexts</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Processing Device Policy | Processing Device Policy]] section.<br />
<br />
When <tt>'''selabel_open'''(3)</tt> is called specifying this file it will be read into memory and sorted using <tt>'''qsort'''(3)</tt>, subsequent calls using <tt>'''selabel_lookup'''(3)</tt> will then retrieve the appropriate context based on matching the <tt>property_key</tt>. <br />
<br />
'''Example:'''<br />
<br />
Use <tt>adb</tt> to reload the SELinux policy:<br />
<pre><br />
adb shell su 0 setprop selinux.reload_policy 1<br />
</pre><br />
<br />
Sample <tt>property_contexts</tt> file entries are:<br />
<pre><br />
# property_key context to be applied on match<br />
net.rmnet u:object_r:net_radio_prop:s0<br />
net.gprs u:object_r:net_radio_prop:s0<br />
net.ppp u:object_r:net_radio_prop:s0<br />
net.qmi u:object_r:net_radio_prop:s0<br />
net.lte u:object_r:net_radio_prop:s0<br />
net.cdma u:object_r:net_radio_prop:s0<br />
net.dns u:object_r:net_radio_prop:s0<br />
sys.usb.config u:object_r:system_radio_prop:s0<br />
ril. u:object_r:radio_prop:s0<br />
gsm. u:object_r:radio_prop:s0<br />
persist.radio u:object_r:radio_prop:s0<br />
<br />
debug. u:object_r:debug_prop:s0<br />
debug.db. u:object_r:debuggerd_prop:s0<br />
log. u:object_r:shell_prop:s0<br />
service.adb.root u:object_r:shell_prop:s0<br />
service.adb.tcp.port u:object_r:shell_prop:s0<br />
<br />
persist.audio. u:object_r:audio_prop:s0<br />
persist.logd. u:object_r:logd_prop:s0<br />
persist.sys. u:object_r:system_prop:s0<br />
persist.service. u:object_r:system_prop:s0<br />
persist.service.bdroid. u:object_r:bluetooth_prop:s0<br />
persist.security. u:object_r:system_prop:s0<br />
<br />
# selinux non-persistent properties<br />
selinux. u:object_r:security_prop:s0<br />
<br />
# default property context (* is wild card match)<br />
* u:object_r:default_prop:s0<br />
</pre><br />
<br />
The property service will call <tt>selabel_lookup</tt> with parameters consisting of the handle passed from <tt>selabel_open</tt>, a buffer to hold the returned context, and the object name "<tt>selinux.reload_policy</tt>" to look-up (the final parameter is not used):<br />
<pre><br />
selabel_lookup(handle, &context, "selinux.reload_policy", 1);<br />
</pre><br />
<br />
The following context will be returned as the look-up process will search for a match based on the length of the <tt>property_key</tt> (and will therefore match against "<tt>selinux.</tt>"):<br />
<pre><br />
u:object_r:security_prop:s0<br />
</pre><br />
<br />
The property service will then validate whether the service has permission by issuing an <tt>'''selinux_check_access'''(3)</tt> call with the following parameters:<br />
<pre><br />
source context: u:r:su:s0<br />
target context: u:object_r:security_prop:s0<br />
class: property_service<br />
permission: set<br />
</pre><br />
<br />
The policy would then decide whether to allow or deny the property request. Using the [[#sepolicy_check | sepolicy-check]] tool will show that this will be denied by the current policy (a <tt>dontaudit</tt> rule is in the policy, however <tt>su</tt> runs permissive anyway):<br />
<pre><br />
sepolicy-check -s su -t security_prop -c property_service -p set -P out/target/product/generic/root/sepolicy<br />
echo $?<br />
1<br />
</pre><br />
<br />
== service_contexts ==<br />
This file holds binder service keys and their contexts that are matched against binder object names using <tt>'''selabel_lookup'''(3)</tt>. The returned context will then be used as the target context as described in the example below to determine whether the binder service is allowed or denied (see <tt>frameworks/native/cmds/servicemanager/servicemanager.c</tt>).<br />
<br />
The build process supports additional <tt>service_contexts</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Building the Policy | Building the Policy]] section.<br />
<br />
When <tt>'''selabel_open'''(3)</tt> is called specifying this file it will be read into memory and sorted using <tt>'''qsort'''(3)</tt>, subsequent calls using <tt>'''selabel_lookup'''(3)</tt> will then retrieve the appropriate context based on matching the <tt>service_key</tt>. <br />
<br />
'''Example:'''<br />
<br />
The <tt>healthd</tt> process wants to start a binder service "<tt>batterypropreg</tt>" (see <tt>frameworks/base/services/java/com/android/server/BatteryService.java</tt>).<br />
<br />
Sample <tt>service_contexts</tt> file entries are:<br />
<pre><br />
# service_key context to be applied on match<br />
batteryproperties u:object_r:healthd_service:s0<br />
batterystats u:object_r:system_server_service:s0<br />
battery u:object_r:system_server_service:s0<br />
<br />
# default service context (* is wild card match)<br />
* u:object_r:default_android_service:s0<br />
</pre><br />
<br />
The service manager will call <tt>selabel_lookup</tt> with parameters consisting of the handle passed from <tt>selabel_open</tt>, a buffer to hold the returned context, and the object name "<tt>batterypropreg</tt>" to look-up (the final parameter is not used):<br />
<pre><br />
selabel_lookup(handle, &context, "batterypropreg", 1);<br />
</pre><br />
<br />
The following context will be returned as the look-up process will search for a match based on the length of the <tt>service_key</tt> (and will therefore match against "<tt>battery</tt>"):<br />
<pre><br />
u:object_r:system_server_service:s0<br />
</pre><br />
<br />
The service manager will then validate whether the service has permission by issuing an <tt>'''selinux_check_access'''(3)</tt> call with the following parameters:<br />
<pre><br />
source context: u:r:healthd:s0<br />
target context: u:object_r:system_server_service:s0<br />
class: service_manager<br />
permission: add<br />
</pre><br />
<br />
The policy would then decide whether to allow or deny the service. Using the [[#sepolicy_check|sepolicy-check]] tool will show that this will be allowed by the current policy:<br />
<pre><br />
sepolicy-check -s healthd -t system_server_service \<br />
-c service_manager -p add \<br />
-P out/target/product/generic/root/sepolicy<br />
Match found!<br />
</pre><br />
<br />
== mac_permissions.xml ==<br />
The <tt>mac_permissions.xml</tt> file is used to configure Run/Install-time MMAC policy and provides x.509 certificate to <tt>seinfo</tt> string mapping so that Zygote spawns an app in the correct domain. See the [[#Computing a Context| Computing a Context]] section for how this is achieved using information also contained in the <tt>seapp_contexts</tt> file (AOSP and SEAndroid).<br />
<br />
An example AOSP <tt>mac_permissions.xml</tt> file that shows the <tt><nowiki><default></nowiki></tt> entry is:<br />
<pre><br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<policy><br />
<!-- Platform dev key in AOSP --><br />
<br />
<signer signature="@PLATFORM" ><br />
<seinfo value="platform" /><br />
</signer><br />
<br />
<!-- All other keys --><br />
<default><br />
<seinfo value="default" /><br />
</default><br />
<br />
</policy><br />
</pre><br />
<br />
<br />
The <tt><nowiki><signer signature=</nowiki></tt> entry may have the public base16 signing key present in the string or it may have an entry starting with <tt>@</tt>, then a keyword as shown that allows the key to be extracted from a <tt>pem</tt> file as discussed in the [[#insertkeys.py | insertkeys.py]] section. If a base16 key is required, it can be extracted from a package using the [[#post_process_mac_perms | post_process_mac_perms]] and [[#setool | setool]] utilities. <br />
<br />
The build process supports additional <tt>mac_permissions.xml</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Processing Device Policy|Processing Device Policy]] section. An example SEAndroid test device <tt>mac_permissions.xml</tt> file is:<br />
<pre><br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<policy><br />
<br />
<!-- NET_APPS key and seinfo for SE4A-NetClient & SE4A-NetServer apps. --><br />
<signer signature="@NET_APPS" ><br />
<package name="com.se4android.netclient" ><br />
<seinfo value="netclient" /><br />
</package><br />
<package name="com.se4android.netserver" ><br />
<seinfo value="netserver" /><br />
</package><br />
</signer><br />
<br />
</policy><br />
</pre><br />
<br />
==== Policy Rules ====<br />
The following rules have been extracted from the AOSP <tt>mac_permissions.xml</tt> file with the one SEAndroid addition noted:<br />
<br />
* A signature is a hex encoded X.509 certificate or a tag defined in <tt>keys.conf</tt> and is required for each <tt>signer</tt> tag.<br />
* A <tt>signer</tt> tag may contain a <tt>seinfo</tt> tag and multiple package stanzas.<br />
* A <tt>default</tt> tag is allowed that can contain policy for all apps not signed with a previously listed cert. It may not contain any inner <tt>package</tt> stanzas.<br />
* Each <tt>signer</tt>/<tt>default</tt>/<tt>package</tt> tag is allowed to contain one <tt>seinfo</tt> tag. This tag represents additional info that each app can use in setting a SELinux security context on the eventual process.<br />
* When a package is installed the following logic is used to determine what <tt>seinfo</tt> value, if any, is assigned:<br />
** All signatures used to sign the app are checked first.<br />
** If a <tt>signer</tt> stanza has inner <tt>package</tt> stanzas, those stanza will be checked to try and match the package name of the app. If the package name matches then that <tt>seinfo</tt> tag is used. If no inner package matches then the outer <tt>seinfo</tt> tag is assigned.<br />
** The <tt>default</tt> tag is consulted last if needed.<br />
** If none of the cases apply then the app is denied install on the device. '''NOTE:''' This case only applies to SEAndroid.<br />
<br />
== eops.xml ==<br />
The following text has been taken from the SEAndroid <tt>/external/sepolicy/eops.xml</tt> file (so check if any changes) with a few minor additions (there is also a simple example in the [[#Eops Example | EOps Example]] section section).<br />
<br />
EOps (enterprise operations) is a security extension to the App Operations (AppOps) feature already present on Android 4.3+ devices. AppOps lets users fine tune certain functionality requested by apps by allowing the user to toggle these access rights.<br />
<br />
EOps seeks to provide an extension whereby a hard coded set of rules explicitly denies certain access rights to groups of installed apps. This feature will allow an enterprise like control over certain operations. EOps is not a front-end for SELinux which somehow ties app permissions to SELinux contexts. Rather, it is an extension of the middleware MAC (MMAC) controls that currently exist on Android 4.3+ devices. EOps uses the <tt>seinfo</tt> labels that are already assigned to apps upon install.<br />
<br />
The list of viable op tag names can be found in <tt>frameworks/base/core/java/android/app/AppOpsManager.java</tt>. Just use the string version of each op without the <tt>OP_</tt> prefix in your policy tags. These are the current 48 entries (March '15):<br />
<br />
<tt><br />
{| border="1"<br />
| COARSE_LOCATION<br />
| FINE_LOCATION<br />
| GPS<br />
<br />
|-<br />
| VIBRATE<br />
| READ_CONTACTS<br />
| WRITE_CONTACTS<br />
<br />
|-<br />
| READ_CALL_LOG<br />
| WRITE_CALL_LOG<br />
| READ_CALENDAR<br />
<br />
|-<br />
| WRITE_CALENDAR<br />
| WIFI_SCAN<br />
| POST_NOTIFICATION<br />
<br />
|-<br />
| NEIGHBORING_CELLS<br />
| CALL_PHONE<br />
| READ_SMS<br />
<br />
|-<br />
| WRITE_SMS<br />
| RECEIVE_SMS<br />
| RECEIVE_EMERGECY_SMS<br />
<br />
|-<br />
| RECEIVE_MMS<br />
| RECEIVE_WAP_PUSH<br />
| SEND_SMS<br />
<br />
|-<br />
| READ_ICC_SMS<br />
| WRITE_ICC_SMS<br />
| WRITE_SETTINGS<br />
<br />
|-<br />
| SYSTEM_ALERT_WINDOW<br />
| ACCESS_NOTIFICATIONS<br />
| CAMERA<br />
<br />
|-<br />
| RECORD_AUDIO<br />
| PLAY_AUDIO<br />
| READ_CLIPBOARD<br />
<br />
|-<br />
| WRITE_CLIPBOARD<br />
| TAKE_MEDIA_BUTTONS<br />
| TAKE_AUDIO_FOCUS<br />
<br />
|-<br />
| AUDIO_MASTER_VOLUME<br />
| AUDIO_VOICE_VOLUME<br />
| AUDIO_RING_VOLUME<br />
<br />
|-<br />
| AUDIO_MEDIA_VOLUME<br />
| AUDIO_ALARM_VOLUME<br />
| AUDIO_NOTIFICATION_VOLUME<br />
<br />
|-<br />
| AUDIO_BLUETOOTH_VOLUME<br />
| WAKE_LOCK<br />
| MONITOR_LOCATION<br />
<br />
|-<br />
| MONITOR_HIGH_POWER_LOCATION<br />
| GET_USAGE_STATS<br />
| MUTE_MICROPHONE<br />
<br />
|-<br />
| TOAST_WINDOW<br />
| PROJECT_MEDIA<br />
| ACTIVATE_VPN<br />
<br />
|}<br />
</tt><br />
<br />
All operations listed in the policy will have a mode of ignored. This means that empty data sets are returned to the caller when an operation is requested. This shadow data will then allow certain apps to presumably still operate. However, AOSP currently is not constructed to return these empty data sets and therefore acts as if ignored operations are completely denied (blocked). Because of this some apps might crash or behave oddly if you apply certain eops policy. In addition, while AOSP seems to have hooked the proper places to check operations against policy some of those hooks fail to follow through with the denial and still allow the operation to occur. Because of this, EOps will also fail to make those distinctions and likewise fail to enforce certain operations. Once the AOSP pieces are in place to return legitimate fake data and enforce all operations then of course eops, by its design, will also do the same.<br />
<br />
So, as long as AppOps is beta so too will EOps.<br />
<br />
A <tt>debug</tt> tag is also allowed which flips on the global debugging log functionality inside AppOps.<br />
<br />
Each stanza is grouped according to the <tt>seinfo</tt> tag that is assigned during install and thus creates a dependency with the <tt>mac_permissions.xml</tt> file. Each <tt>seinfo</tt> tag can then include any number of op tags. By including the op(s) you are simply removing that operation from working for all apps that have been installed with the listed <tt>seinfo</tt> label. These operations are restricted regardless of what any user controlled app ops policy may say. Any op not listed is therefore still subject to user control as normal.<br />
<br />
Lastly, there is no permissive mode for EOps. Once a policy is in place all ops listed are enforced.<br />
<br />
The following is an example <tt>eops.xml</tt> policy file that will stop the camera being used by any system or default app. The file installation is shown in the [[#buildeopbundle | Build Bundle Tools - buildeopbundle]] section:<br />
<pre><br />
<?xml version="1.0"?><br />
<app-ops><br />
<br />
<debug/><br />
<br />
<seinfo name="default"><br />
<op name="CAMERA"/><br />
</seinfo><br />
<br />
<seinfo name="system"><br />
<op name="CAMERA"/><br />
</seinfo><br />
<br />
</app-ops><br />
</pre><br />
<br />
== ifw.xml ==<br />
The example <tt>external/sepolicy/ifw.xml</tt> file has some comments regarding the tags, there is also an overview at [http://www.cis.syr.edu/~wedu/android/IntentFirewall/ http://www.cis.syr.edu/~wedu/android/IntentFirewall/]. <br />
<br />
The following is an example <tt>ifw.xml</tt> policy file that will stop the <tt>DemoIsolatedService</tt> being used by any app other than system apps or apps with the same signature. The file installation is shown in the [[#buildifwbundle | Build Bundle Tools - buildifwbundle]] section:<br />
<pre><br />
<?xml version="1.0"?><br />
<br />
<rules><br />
<br />
<!-- This will stop any app that is not a system app or<br />
does not have a matching signature from running the<br />
DemoIsolatedService service<br />
--><br />
<br />
<service log="true" block="true"><br />
<not><sender type="system|signature"/></not><<br />
<intent-filter /><br />
<component-filter name="com.se4android.isolatedservice/.DemoIsolatedService"/><br />
</service><br />
<br />
</rules><br />
</pre><br />
<br />
The events will be in the event log under the '<tt>ifw_intent_matched</tt>' tag, for example:<br />
<pre><br />
adb logcat -b events<br />
...<br />
...<br />
I/ifw_intent_matched( 390):[2,com.se4android.isolatedservice/.DemoIsolatedService,10058,1,NULL,NULL,NULL,NULL,0]<br />
...<br />
</pre><br />
<br />
= Policy Build Tools =<br />
This section covers the policy build tools located at <tt>external/sepolicy/tools</tt>. They are <tt>checkfc</tt>, <tt>checkseapp</tt> and <tt>insertkeys.py</tt>. There is also <tt>setool</tt> that is not used as part of the build process but generates <tt>mac_permissions.xml</tt> entries from packages.<br />
<br />
== checkfc ==<br />
The <tt>checkfc</tt> utility is used during the build process to validate the <tt>file_contexts</tt>, <tt>property_contexts</tt> and <tt>service_contexts</tt> files against policy. If validation fails <tt>checkfc</tt> will exit with an error.<br />
<br />
Usage:<br />
<pre><br />
usage: checkfc [OPTIONS] sepolicy context_file<br />
<br />
Parses a context file and checks for syntax errors.<br />
The context_file is assumed to be a file_contexts file<br />
unless explicitly switched by an option.<br />
<br />
OPTIONS:<br />
-p : context file represents a property_context file.<br />
</pre><br />
<br />
Example validating <tt>file_contexts</tt> file (note: no <tt>-p</tt> parameter):<br />
<pre><br />
checkfc out/target/product/generic/root/sepolicy out/target/product/generic/root/file_contexts<br />
</pre><br />
<br />
Example validating <tt>property_contexts</tt> file:<br />
<pre><br />
checkfc -p out/target/product/generic/root/sepolicy out/target/product/generic/root/property_contexts<br />
</pre><br />
<br />
== checkseapp ==<br />
The <tt>checkseapp</tt> utility is used during the build process to validate the <tt>seapp_contexts</tt> file against policy. If validation fails <tt>checkseapp</tt> will exit with an error. <tt>checkseapp</tt> also consolidates matching entries and outputs the valid file stripped of comments.<br />
<br />
Usage:<br />
<pre><br />
checkseapp [options] <input file><br />
<br />
Processes an seapp_contexts file specified by argument <input file> (default stdin) and allows later declarations to override previous ones on a match.<br />
<br />
Options:<br />
-h - print this help message<br />
-s - enable strict checking of duplicates. This causes the program to exit on a duplicate entry with a non-zero exit status<br />
-v - enable verbose debugging informations<br />
-p policy file - specify policy file for strict checking of output selectors against the policy<br />
-o output file - specify output file, default is stdout<br />
</pre><br />
<br />
An example command with output to <tt>stdout</tt> is:<br />
<pre><br />
checkseapp -p out/target/product/se4a_device/root/sepolicy out/target/product/se4a_device/root/seapp_contexts<br />
<br />
isSystemServer=true domain=system_server<br />
user=system domain=system_app type=system_app_data_file<br />
user=bluetooth domain=bluetooth type=bluetooth_data_file<br />
user=nfc domain=nfc type=nfc_data_file<br />
user=radio domain=radio type=radio_data_file<br />
user=shared_relro domain=shared_relro<br />
user=shell domain=shell type=shell_data_file<br />
user=_isolated domain=isolated_app levelFrom=user<br />
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
user=_app seinfo=netclient domain=netclient_app type=net_apps_log_file levelFrom=app<br />
user=_app seinfo=netserver domain=netserver_app type=net_apps_log_file levelFrom=app<br />
</pre><br />
<br />
== insertkeys.py ==<br />
The <tt>insertkeys.py</tt> utility is used during the build process to insert signing keys into the <tt>mac_permissions.xml</tt> file. The keys are obtained from <tt>pem</tt> files and the entries to be replaced start with an <tt>@</tt> followed by a keyword. The <tt>external/sepolicy/keys.conf</tt> file contains corresponding entries that allow mapping of <tt>pem</tt> files to signatures as discussed in the [[#keys.conf File | keys.conf File]] section.<br />
<br />
<tt>insertkeys.py</tt> generates base16 encodings from the base64 <tt>pem</tt> files as this is required by the Android Package Manager Service. The resulting <tt>mac_permissions.xml</tt> file will also be stripped of comments and whitespace.<br />
<br />
Usage:<br />
<pre><br />
Usage: insertkeys.py [options] CONFIG_FILE MAC_PERMISSIONS_FILE [MAC_PERMISSIONS_FILE...]<br />
<br />
This tool allows one to configure an automatic inclusion of signing keys into the mac_permission.xml file(s) from the pem files. If multiple mac_permission.xml files are included then they are unioned to produce a final version.<br />
<br />
Options:<br />
--version show program's version number and exit<br />
-h, --help show this help message and exit<br />
-v, --verbose Print internal operations to stdout<br />
-o FILE, --output=FILE Specify an output file, default is stdout<br />
-c DIR, --cwd=DIR Specify a root (CWD) directory to run this from, itchdirs' AFTER loading the config file<br />
-t TARGET_BUILD_VARIANT, --target-build-variant=TARGET_BUILD_VARIANT Specify the TARGET_BUILD_VARIANT, defaults to eng<br />
-d KEY_DIRECTORY, --key-directory Specify a parent directory for keys<br />
</pre><br />
<br />
=== keys.conf File ===<br />
The <tt>keys.conf</tt> file is used by <tt>insertkeys.py</tt> for mapping the "<tt>@...</tt>" tags in <tt>mac_permissions.xml</tt>, <tt>mmac_types.xml</tt> and <tt>content_provider.xml</tt> signature entries with public keys found in <tt>pem</tt> files. The configuration file can be used in the <tt>BOARD_SEPOLICY_UNION</tt> variable and is processed via <tt>m4</tt> macros.<br />
<br />
<tt>insertkeys.py</tt> allows for mapping any string contained in <tt>TARGET_BUILD_VARIANT</tt> with a specific path to a <tt>pem</tt> file. Typically <tt>TARGET_BUILD_VARIANT</tt> is either <tt>user</tt>, <tt>eng</tt> or <tt>userdebug</tt>. Additionally "<tt>ALL</tt>" may be specified to map a path to any string specified in <tt>TARGET_BUILD_VARIANT</tt>. All tags are matched verbatim and all options are matched lowercase. The options are "<tt>tolowered</tt>" automatically for the user, it is convention to specify tags and options in all uppercase and tags start with <tt>@</tt>.<br />
<br />
An example <tt>keys.conf</tt> file is as follows:<br />
<pre><br />
#<br />
# Maps an arbitrary tag [TAGNAME] with the string contents found in<br />
# TARGET_BUILD_VARIANT. Common convention is to start TAGNAME with an @ and<br />
# name it after the base file name of the pem file.<br />
#<br />
# Each tag (section) then allows one to specify any string found in<br />
# TARGET_BUILD_VARIANT. Typcially this is user, eng, and userdebug. Another<br />
# option is to use ALL which will match ANY TARGET_BUILD_VARIANT string.<br />
#<br />
<br />
[@PLATFORM]<br />
ALL : $DEFAULT_SYSTEM_DEV_CERTIFICATE/platform.x509.pem<br />
<br />
[@MEDIA]<br />
ALL : $DEFAULT_SYSTEM_DEV_CERTIFICATE/media.x509.pem<br />
<br />
[@SHARED]<br />
ALL : $DEFAULT_SYSTEM_DEV_CERTIFICATE/shared.x509.pem<br />
<br />
# Example of ALL TARGET_BUILD_VARIANTS<br />
[@RELEASE]<br />
ENG : $DEFAULT_SYSTEM_DEV_CERTIFICATE/testkey.x509.pem<br />
USER : $DEFAULT_SYSTEM_DEV_CERTIFICATE/testkey.x509.pem<br />
USERDEBUG : $DEFAULT_SYSTEM_DEV_CERTIFICATE/testkey.x509.pem<br />
</pre><br />
<br />
The following is an example entry that will use a device specific key during the build process:<br />
<pre><br />
[@NET_APPS]<br />
ALL : $ANDROID_BUILD_TOP/device/demo_vendor/se4a_device/security/net_apps.x509.pem<br />
</pre><br />
<br />
== Build Bundle Tools ==<br />
The following tools will produce an Android "bundle" for updating MAC/MMAC policy within a zip file suitable for installation by the SEAdmin app. SEAdmin is currently hard-coded to look for these zip files in the SD Card device (<tt>/sdcard/</tt>).<br />
<br />
The [[#Using an Intent Example | buildsebundle]] section also shows how a policy can be updated by broadcasting an intent instead of using SEAdmin.<br />
<br />
=== buildsebundle ===<br />
The <tt>buildsebundle</tt> tool will produce an Android "bundle" for updating the core SE for Android policy within an <tt>selinux_bundle.zip</tt> file, suitable for installation by the SEAdmin app, although it is possible to update using an intent as described in the [[#Using an Intent Example | Using an Intent Example]] section.<br />
<br />
To be able to build the bundle the following mandatory files are required:<br />
: <tt>selinux_version</tt>, <tt>sepolicy</tt>, <tt>file_contexts</tt>, <tt>seapp_contexts</tt>, <tt>property_contexts</tt>, <tt>service_contexts</tt>, <tt>mac_permissions.xml</tt><br />
<br />
Usage:<br />
<pre><br />
usage: buildsebundle -k <private key.pk8> [-v <version>] [-r <previous hash>] \<br />
[-h] -- <selinux_version> <file_contexts> <property_contexts> \<br />
<sepolicy> <seapp_contexts> <service_contexts> <mac_permissions.xml><br />
<br />
This script builds a selinux policy bundle and supporting metadata file capable of being loaded via the ConfigUpdate mechanism. It takes a pkcs8 DER encoded RSA private key that is then used to sign the bundle. For AOSP development you'll typically want to use the key from the source tree at:<br />
build/target/product/security/testkey.pk8<br />
<br />
The built bundle will be written to selinux_bundle.zip which will include the signature metadata file of the bundle.<br />
<br />
OPTIONS:<br />
-h Show this message.<br />
-v Version of the built bundle. Defaults to 1.<br />
-r SHA-512 hash of the bundle to replace. Defaults to 'NONE'.<br />
</pre><br />
<br />
The following is an example where a new policy has been built with all required files. The wildcard can be used as <tt>buildsebundle</tt> will always use the mandatory list:<br />
<pre><br />
buildsebundle -k $ANDROID_BUILD_TOP/build/target/product/security/testkey.pk8 \<br />
-v 3 -- $ANDROID_BUILD_TOP/device/demo_device/se4a_device/new_sepolicy/*<br />
<br />
adb push selinux_bundle.zip /sdcard/<br />
</pre><br />
<br />
Once built, the bundle is pushed to the SD card and SEAdmin is used to update the policy (note that SEAdmin only reads the bundle from <tt>/sdcard</tt>).<br />
<br />
==== Using an Intent Example ====<br />
This example shows how to update a policy by broadcasting an intent in the same way as SEAdmin.<br />
<br />
Extract the <tt>selinux_bundle</tt> files from the <tt>selinux_bundle.zip</tt> file:<br />
<pre><br />
unzip selinux_bundle.zip<br />
Archive: selinux_bundle.zip<br />
inflating: update_bundle <br />
inflating: update_bundle_metadata<br />
</pre><br />
<br />
The two files contain:<br />
<br />
: <tt>'''update_bundle'''</tt> - Contains hex encoded policy files to be installed.<br />
: <tt>'''update_bundle_metadata'''</tt> - This is used by SEAdmin to form the intent and contains a hash of the bundle to replace or "<tt>NONE</tt>", the signature of the <tt>update_bundle</tt> and the bundle version (in this case "<tt>3</tt>"). Example contents are:<br />
<pre><br />
NONE:I6E0cZ8WbF6kJWkDozJCfckw5xuZhXuE0iqrbszsxhi7S4Z3DrR7RiH/aomRQxeskvMv9B/+G7JXfxFAQlV1CWZihnefkHGnei4atKnBLPK/g3gmf0Wb0jjizc4yb4uvu/XQAZvybKcsTvTiegfqTHMFWPGKgoq97RKAjk2kT2fa3liArylTrLl7OfRtKq6mNjQNnfVrte9e/aJptiAmOwDNdQydfRwhewrKPE6rM+YNuHJaJ+h28dNecQtCn9TabTxn8I1G+10d5/wmjjgXq6MdfEMQZ++H4ZIaL4bTdUOQVdFeMsnFLA3hjLGf3BXpHmG84s7iDO158V0kbXikzA==:3<br />
</pre><br />
<br />
Push the <tt>update_bundle</tt> to the device:<br />
<pre><br />
adb push update_bundle /data/update_bundle<br />
</pre><br />
<br />
Build an intent to broadcast via <tt>adb</tt> by including the bundle location, with the hash, signature and version from the <tt>update_bundle_metadata</tt> as follows:<br />
<pre><br />
adb shell am broadcast -a android.intent.action.UPDATE_SEPOLICY -e "CONTENT_PATH" "/data/update_bundle" -e "REQUIRED_HASH" "NONE" -e "SIGNATURE" "I6E0cZ8WbF6kJWkDozJCfckw5xuZhXuE0iqrbszsxhi7S4Z3DrR7RiH/aomRQxeskvMv9B/+G7JXfxFAQlV1CWZihnefkHGnei4atKnBLPK/g3gmf0Wb0jjizc4yb4uvu/XQAZvybKcsTvTiegfqTHMFWPGKgoq97RKAjk2kT2fa3liArylTrLl7OfRtKq6mNjQNnfVrte9e/aJptiAmOwDNdQydfRwhewrKPE6rM+YNuHJaJ+h28dNecQtCn9TabTxn8I1G+10d5/wmjjgXq6MdfEMQZ++H4ZIaL4bTdUOQVdFeMsnFLA3hjLGf3BXpHmG84s7iDO158V0kbXikzA==" -e "VERSION" "3"<br />
</pre><br />
<br />
When the intent has been broadcast there will be a response, however that does not indicate that the policy was updated, just that the intent was broadcast:<br />
<pre><br />
Broadcasting: Intent { act=android.intent.action.UPDATE_SEPOLICY (has extras) }<br />
Broadcast completed: result=0<br />
</pre><br />
<br />
<tt>logcat</tt> should show whether it was successful:<br />
<pre><br />
I/ConfigUpdateInstallReceiver( 908): Found new update, installing...<br />
I/ConfigUpdateInstallReceiver( 908): Installation successful<br />
I/SELinuxPolicyInstallReceiver( 908): Applying SELinux policy<br />
</pre><br />
If the update failed because of versioning then an error is given (however if signature incorrect fails silently).<br />
<br />
The following show various policy information after the third update:<br />
<pre><br />
adb shell ls -l /data/security/current<br />
lrwxrwxrwx system system 2014-07-19 10:41 current -> /data/security/contexts<br />
</pre><br />
<pre><br />
adb shell ls -l /data/security/contexts<br />
<br />
-rw-r--r-- system system 10512 2014-07-19 10:41 file_contexts<br />
-rw-r--r-- system system 10656 2014-07-19 09:01 file_contexts_backup<br />
-rw-r--r-- system system 4203 2014-07-19 10:41 mac_permissions.xml<br />
-rw-r--r-- system system 4203 2014-07-19 09:01 mac_permissions.xml_backup<br />
-rw-r--r-- system system 2549 2014-07-19 10:41 property_contexts<br />
-rw-r--r-- system system 2549 2014-07-19 09:01 property_contexts_backup<br />
-rw-r--r-- system system 641 2014-07-19 10:41 seapp_contexts<br />
-rw-r--r-- system system 641 2014-07-19 09:01 seapp_contexts_backup<br />
-rw-r--r-- system system 78 2014-07-19 10:41 selinux_version<br />
-rw-r--r-- system system 78 2014-07-19 09:01 selinux_version_backup<br />
-rw-r--r-- system system 115831 2014-07-19 10:41 sepolicy<br />
-rw-r--r-- system system 116438 2014-07-19 09:01 sepolicy_backup<br />
-rw-r--r-- system system 7748 2014-07-19 10:41 service_contexts<br />
-rw-r--r-- system system 7748 2014-07-19 09:01 service_contexts_backup<br />
</pre><br />
<pre><br />
adb shell ls -l /data/security<br />
<br />
drwx------ system system 2014-07-19 10:41 bundle<br />
drwx------ system system 2014-07-19 10:41 contexts<br />
lrwxrwxrwx system system 2014-07-19 10:41 current ->/data/security/contexts<br />
drwx------ system system 2014-07-19 10:37 eops<br />
</pre><br />
<pre><br />
adb shell ls -l /data/security/bundle<br />
<br />
drwx------ system system 2014-07-19 10:41 metadata<br />
-rw-r--r-- system system 191271 2014-07-19 10:41 sepolicy_bundle<br />
</pre><br />
<pre><br />
adb shell ls -l /data/security/bundle/metadata<br />
<br />
-rw-r--r-- system system 1 2014-07-19 10:41 version<br />
</pre><br />
<pre><br />
adb shell cat /data/security/bundle/metadata/version<br />
3<br />
</pre><br />
<br />
The loaded policy can be extracted from the device if required by:<br />
<pre><br />
adb pull /sys/fs/selinux/policy sepolicy-v3<br />
</pre><br />
<br />
=== buildeopbundle ===<br />
The <tt>buildeopbundle</tt> tool will produce an Android "bundle" for updating the Enterprise Operations policy within an <tt>eops_bundle.zip</tt> file suitable for installation by the SEAdmin app, although it is possible to update using an intent as described in the [[#Using an Intent Example | Using an Intent Example]] section.<br />
<br />
To be able to build the bundle an <tt>eops.xml</tt> file is required.<br />
<br />
Usage:<br />
<pre><br />
usage: buildeopbundle -k <private key.pk8> [-v <version>] [-r <previous hash>] \<br />
[-h] -- <eops.xml><br />
<br />
This script builds a eops policy bundle and supporting metadata file capable of being loaded via the ConfigUpdate mechanism. It takes a pkcs8 DER encoded RSA private key that is then used to sign the bundle. For AOSP development you'll typically want to use the key from the source tree at:<br />
build/target/product/security/testkey.pk8<br />
<br />
If building your own cert you should probably use a key size of at least 1024 or greater. The bundle requires that the eops.xml file be included and with that exact basename. The built bundle will be written to eop_bundle.zip which will include the signature metadata file of the bundle.<br />
<br />
OPTIONS:<br />
-h Show this message.<br />
-v Version of the built bundle. Defaults to 1.<br />
-r SHA-512 hash of the bundle to replace. Defaults to 'NONE'.<br />
</pre><br />
<br />
==== Eops Example ====<br />
The following is an example where a new <tt>eops.xml</tt> file has been produced, bundled, then pushed to the SD card. SEAdmin is then used to update the policy (note that SEAdmin only reads the bundle from <tt>/sdcard</tt>):<br />
<pre><br />
buildeopbundle -k $ANDROID_BUILD_TOP/build/target/product/security/testkey.pk8 -v 1 -- eops.xml<br />
<br />
adb push eops_bundle.zip /sdcard/<br />
</pre><br />
<br />
<tt>logcat</tt> should show if it was successful:<br />
<pre><br />
D/SEAdminConfigUpdateFragment( 904): android.intent.action.UPDATE_EOPS intent being broadcast. Bundle[{CONTENT_PATH=/cache/eops_bundle, SIGNATURE=qZJ8I07MHFTXaII2jhPMooRLzejArUI0qsvkteG9nzEzgzjwyh8RWUaaRil6xrQsPb5g+qWj+nfQCkH7DIEow/WF8S1sTeReS8G/z+hPQi0MHgWGKH0kCIfXn6yqqEri3+Dnolb1vHVuM7t/0mszCvtjqfq5GWbHZc1xYSgMQJXqrhfzSqa2zvO4+7zE0GszfuZXwt9QHci9C1IJ5B50URmmg4TDIuhfISWW9vYkEctwARIyCLhfYiZzIQOwzPj3oSHI1AUWMHxbbpADFzCumZ1WdfpA0txow8rDM+01qkKGtcAsNs8me2FAPz28tckQ9ea6QwAzDCSP3PzQC1Horg==, REQUIRED_HASH=NONE, VERSION=1}]<br />
I/ConfigUpdateInstallReceiver( 395): Couldn't find current metadata, assuming first update<br />
I/ConfigUpdateInstallReceiver( 395): Failed to read current content, assuming first update!<br />
I/ConfigUpdateInstallReceiver( 395): Found new update, installing...<br />
I/ConfigUpdateInstallReceiver( 395): Installation successful<br />
D/AppOps ( 381): Eops policy: system [ CAMERA]<br />
D/AppOps ( 381): Eops policy: default [ CAMERA]<br />
</pre><br />
<br />
The new file and its supporting metadata are:<br />
<pre><br />
adb shell su 0 ls -lR /data/security/eops<br />
<br />
/data/security/eops:<br />
-rw-r--r-- system system 189 2014-07-20 14:15 eops.xml<br />
drwx------ system system 2014-07-20 14:15 eops_metadata<br />
<br />
/data/security/eops/eops_metadata:<br />
-rw-r--r-- system system 1 2014-07-20 14:15 version<br />
</pre><br />
<br />
The version number after the update is:<br />
<pre><br />
adb shell su 0 cat /data/security/eops/eops_metadata/version<br />
1<br />
</pre><br />
<br />
Because the Eops policy specified an <tt>seinfo</tt> of <tt>system</tt> and the operation <tt>CAMERA</tt>, if the Camera app is now started it will load however, it will not be possible to take pictures as <tt>logcat</tt> will show:<br />
<pre><br />
D/AppOps ( 381): startOperation: reject #1 for code 26 (26) uid 10026 package com.android.camera2<br />
I/CameraService( 60): Camera 0: Access for "com.android.camera2" has been revoked<br />
</pre><br />
<br />
=== buildifwbundle ===<br />
The <tt>buildifwbundle</tt> tool will produce an Android "bundle" for updating the Intent Firewall policy within an <tt>ifw_bundle.zip</tt> file suitable for installation by the SEAdmin app, although it is possible to update using an intent as described in the [[#Using an Intent Example | Using an Intent Example]] section.<br />
<br />
To be able to build the bundle an <tt>ifw.xml</tt> file is required, although note that the Intent Firewall service will read any file so long as it has the <tt>.xml</tt> extension.<br />
<br />
Usage:<br />
<pre><br />
usage: buildifwbundle -k <private key.pk8> [-v <version>] [-r <previous hash>] \<br />
[-h] -- <ifw.xml><br />
<br />
This script builds an intent firewall policy bundle and supporting metadata file capable of being loaded via the ConfigUpdate mechanism. It takes a pkcs8 DER encoded RSA private key that is then used to sign the bundle. For AOSP development you'll typically want to use the key from the source tree at:<br />
build/target/product/security/testkey.pk8<br />
<br />
If building your own cert you should probably use a key size of at least 1024 or greater. The bundle requires that the ifw.xml file be included and with that exact basename. The built bundle will be written to ifw_bundle.zip which will include the signature metadata file of the bundle.<br />
<br />
OPTIONS:<br />
-h Show this message.<br />
-v Version of the built bundle. Defaults to 1.<br />
-r SHA-512 hash of the bundle to replace. Defaults to 'NONE'.<br />
</pre><br />
<br />
==== IFW Example ====<br />
The following is an example where a new <tt>ifw.xml</tt> file has been produced, bundled, and then pushed to the SD card. SEAdmin is then used to update the policy (note that SEAdmin only reads the bundle from <tt>/sdcard</tt>):<br />
<pre><br />
buildsifwbundle -k $ANDROID_BUILD_TOP/build/target/product/security/testkey.pk8 -v 1 -- eops.xml<br />
<br />
adb push ifw_bundle.zip /sdcard/<br />
</pre><br />
<br />
<tt>logcat</tt> should show whether it was successful:<br />
<pre><br />
D/SEAdminConfigUpdateFragment( 904): android.intent.action.UPDATE_INTENT_FIREWALL intent being broadcast. Bundle[{CONTENT_PATH=/cache/ifw_bundle, SIGNATURE=tfQONpEZbL1Y6sXj1BY98TO4izK2IyeqO9Hko5tZygE77zry98RGmU5BAAIFs21G9G7WpAcPTR7TGe4LRMpB7SKeZ1Xh+4B+U+30TnHkwXp9HRIgIJcN5Kqiyp/UPAjEJjYmBZk+yM5FLYcMCQS082wfpC9c+gRQcl6AYuSmiynvjgc1d33rtfB7Hd40LF30mBZyyiUJc5YF1ddaITBbL/CCKmFblfBqadZtmCN7xGUIJEHqWPnuEvscatkOLgZa+35ZXfl2WkD/DsGkwocXM9akjD0NJY9WZJpzwAHQPdQFXN6nthrsV8kiC7OUFvK/PKll9oetiyTSEEVH5JlMnA==, REQUIRED_HASH=NONE, VERSION=1}]<br />
I/ConfigUpdateInstallReceiver( 395): Couldn't find current metadata, assuming first update<br />
I/ConfigUpdateInstallReceiver( 395): Failed to read current content, assuming first update!<br />
I/ConfigUpdateInstallReceiver( 395): Found new update, installing...<br />
I/ConfigUpdateInstallReceiver( 395): Installation successful<br />
I/IntentFirewall( 395): Read new rules (A:0 B:0 S:1)<br />
</pre><br />
<br />
The new file and its supporting metadata are:<br />
<pre><br />
adb shell su 0 ls -lR /data/system/ifw<br />
<br />
/data/system/ifw:<br />
-rw-r--r-- system system 454 2014-07-20 13:14 ifw.xml<br />
drwx------ system system 2014-07-20 13:14 metadata<br />
<br />
/data/system/ifw/metadata:<br />
-rw-r--r-- system system 1 2014-07-20 13:14 gservices.version<br />
</pre><br />
<br />
The version number after the update is:<br />
<pre><br />
adb shell su 0 cat /data/system/ifw/metadata/gservices.version<br />
1<br />
</pre><br />
<br />
== post_process_mac_perms ==<br />
This tool will modify an existing <tt>mac_permissions.xml</tt> with additional app certs not already found in that policy. This becomes useful when a directory containing apps is searched and the certs from those apps are added to the policy not already explicitly listed.<br />
<br />
There is no make target for this tool (python script), so either move to <tt>HOST_EXECUTABLE</tt> or execute directly (e.g. <tt>$PREFIX/external/sepolicy/tools/post_process_mac_perms</tt>).<br />
<br />
Usage:<br />
<pre><br />
post_process_mac_perms [-h] -s SEINFO -d DIR -f POLICY<br />
<br />
-s SEINFO, --seinfo SEINFO seinfo tag for each generated stanza<br />
-d DIR, --dir DIR Directory to search for apks<br />
-f POLICY, --file POLICY mac_permissions.xml policy file<br />
</pre><br />
<br />
Example:<br />
<pre><br />
post_process_mac_perms -s netapps -d ./APK -f mac_permissions.xml<br />
</pre><br />
<br />
Before:<br />
<pre><br />
<?xml version="1.0" encoding="utf-8"?><br />
<policy><br />
<signer signature="- certificate here -" ><seinfo value="platform"/></signer><br />
<default><seinfo value="default"/></default><br />
</policy><br />
</pre><br />
<br />
After:<br />
<pre><br />
<?xml version="1.0" encoding="utf-8"?><br />
<policy><br />
<signer signature="- certificate here -" ><seinfo value="platform"/></signer><br />
<default><seinfo value="default"/></default><br />
<signer signature="- certificate here -"><seinfo value="netapps"/></signer><br />
</policy><br />
</pre><br />
<br />
== sepolicy_check ==<br />
A tool for auditing a <tt>sepolicy</tt> file for any allow rule that grants a given permission.<br />
<br />
Usage:<br />
<pre><br />
sepolicy-check -s <domain> -t <type> -c <class> -p <permission> <br />
-P out/target/product/<board>/root/sepolicy<br />
</pre><br />
<br />
The output will be "<tt>Match found!</tt>" or silent if not. <tt>sepolicy_check</tt> will return <tt>0</tt> for found, <tt>1</tt> for not found and <tt>-1</tt> for an error.<br />
<br />
Examples:<br />
<pre><br />
sepolicy-check -s healthd -t system_server_service \<br />
-c service_manager -p add \<br />
-P out/target/product/generic/root/sepolicy<br />
Match found!<br />
</pre><br />
<pre><br />
<tt>sepolicy-check -s su -t security_prop -c property_service \</tt><br />
-p set -P out/target/product/generic/root/sepolicy<br />
echo $?<br />
1<br />
</pre><br />
<br />
== sepolicy-analyze ==<br />
This is the text from the <tt>external/sepolicy/tools/README</tt> that describes the tool for performing various kinds of analysis on a sepolicy file. The analysis currently supported includes:<br />
<br />
=== Type Equivalence ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy typecmp -e<br />
</pre><br />
Display all <tt>[[TypeStatements#type | type]]</tt> pairs that are "equivalent", i.e. they are identical with respect to <tt>[[AVCRules#allow | allow]]</tt> rules, including indirect allow rules via attributes and default-enabled conditional rules (i.e. default boolean values yield a true conditional expression).<br />
<br />
Equivalent types are candidates for being coalesced into a single type. However, there may be legitimate reasons for them to remain separate, for example: - the types may differ in a respect not included in the current analysis, such as default-disabled conditional rules, audit-related rules (<tt>auditallow</tt> or <tt>dontaudit</tt>), default type transitions, or constraints (e.g. mls), or - the current policy may be overly permissive with respect to one or the other of the types and thus the correct action may be to tighten access to one or the other rather than coalescing them together, or - the domains that would in fact have different accesses to the types may not yet be defined or may be unconfined in the policy you are analyzing.<br />
<br />
Example output:<br />
<pre><br />
sepolicy-analyze out/target/product/generic/root/sepolicy typecmp -e<br />
<br />
Types adbd_socket and mdns_socket are equivalent.<br />
Types wifip2p_service and network_score_service are equivalent.<br />
Types wifip2p_service and registry_service are equivalent.<br />
...<br />
Types rild_debug_socket and init_tmpfs are equivalent.<br />
Types ram_device and vcs_device are equivalent.<br />
Types ram_device and uio_device are equivalent.<br />
..<br />
Types loop_device and vold_device are equivalent.<br />
</pre><br />
<br />
=== Type Difference ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy typecmp -d<br />
</pre><br />
Display <tt>[[TypeStatements#type | type]]</tt> pairs that differ and the first difference found between the two types. This may be used in looking for similar types that are not equivalent but may be candidates for coalescing.<br />
<br />
Example output:<br />
<pre><br />
sepolicy-analyze out/target/product/generic/root/sepolicy typecmp -d<br />
<br />
Types adbd_socket and functionfs differ, starting with:<br />
allow adbd_socket rootfs:filesystem { associate };<br />
allow functionfs self:filesystem { associate };<br />
<br />
Types adbd_socket and wifip2p_service differ, starting with:<br />
allow adbd_socket rootfs:filesystem { associate };<br />
allow system_server wifip2p_service:service_manager { add find };<br />
...<br />
...<br />
Types mtd_device and log_device differ, starting with:<br />
allow mtd_device tmpfs:filesystem { associate };<br />
<br />
Types goldfish_setup_exec and log_device differ, starting with:<br />
allow goldfish_setup_exec rootfs:filesystem { associate };<br />
</pre><br />
<br />
=== Duplicate Allow Rules ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy dups<br />
</pre><br />
Displays duplicate <tt>[[AVCRules#allow | allow]]</tt> rules, i.e. pairs of allow rules that grant the same permissions where one allow rule is written directly in terms of individual types and the other is written in terms of attributes associated with those same types. The rule with individual types is a candidate for removal. The rule with individual types may be directly represented in the source policy or may be a result of expansion of a type negation (e.g. domain -foo -bar is expanded to individual allow rules by the policy<br />
compiler). Domains with unconfineddomain (this was removed in 5.1) will typically have such duplicate rules as a natural side effect and can be ignored.<br />
<br />
Example output:<br />
<pre><br />
sepolicy-analyze out/target/product/generic/root/sepolicy dups<br />
<br />
Duplicate allow rule found:<br />
allow system_server sdcardd:lnk_file { ioctl read getattr lock open };<br />
allow system_server domain:lnk_file { ioctl read getattr lock open };<br />
<br />
Duplicate allow rule found:<br />
allow system_server inputflinger:binder { transfer };<br />
allow system_server binderservicedomain:binder { call transfer };<br />
...<br />
...<br />
Duplicate allow rule found:<br />
allow su keystore:binder { call transfer };<br />
allow appdomain binderservicedomain:binder { call transfer };<br />
<br />
Duplicate allow rule found:<br />
allow untrusted_app keystore:fd { use };<br />
allow appdomain binderservicedomain:fd { use };<br />
</pre><br />
<br />
=== Permissive Domains ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy permissive<br />
</pre><br />
Displays domains in the policy that are <tt>[[TypeStatements#permissive | permissive]]</tt>, i.e. avc denials are logged but not enforced for these domains. While permissive domains can be helpful during development, they should not be present in a final <tt>-user</tt> build.<br />
<br />
Example output on an ENG policy:<br />
<pre><br />
sepolicy-analyze out/target/product/generic/root/sepolicy permissive<br />
<br />
su<br />
</pre><br />
<br />
=== Booleans ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy booleans<br />
</pre><br />
Displays the <tt>[[ConditionalStatements | boolean]]</tt> names in the policy (if any).<br />
Policy booleans are forbidden in Android policy, so if there is any output, the policy will fail CTS.<br />
<br />
<br />
=== Attribute ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy attribute <name><br />
</pre><br />
Displays the <tt>[[TypeStatements#type | type]]</tt>s associated with the specified <tt>[[TypeStatements#attribute | attribute]]</tt> name.<br />
<br />
Example output:<br />
<pre><br />
sepolicy-analyze out/target/product/generic/root/sepolicy attribute mlstrustedsubject<br />
<br />
system_server<br />
netd<br />
zygote<br />
debuggerd<br />
kernel<br />
drmserver<br />
keystore<br />
adbd<br />
dumpstate<br />
runas<br />
uncrypt<br />
installd<br />
init<br />
radio<br />
mediaserver<br />
logd<br />
su<br />
mdnsd<br />
surfaceflinger<br />
racoon<br />
vold<br />
shell<br />
lmkd<br />
servicemanager<br />
</pre><br />
<br />
=== Neverallow Checking ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy neverallow [-w] [-d] [-f neverallows.conf] | [-n "neverallow string"]<br />
</pre><br />
Check whether the <tt>sepolicy</tt> file violates any of the <tt>[[AVCRules#neverallow | neverallow]]</tt> rules from the <tt>neverallows.conf</tt> file or a given string, which contain <tt>neverallow</tt> statements in the same format as the SELinux <tt>policy.conf</tt> file, i.e. after m4 macro expansion of the rules from a <tt>.te</tt> file. You can use an entire <tt>policy.conf</tt> file as the <tt>neverallows.conf</tt> file and <tt>sepolicy-analyze</tt> will ignore everything except for the neverallows within it. You can also specify this as a command-line string argument, which could be useful for quickly checking an individual expanded rule or group of rules. If there are no violations, <tt>sepolicy-analyze</tt> will exit successfully with no output. Otherwise, <tt>sepolicy-analyze</tt> will report all violations and exit with a non-zero exit status.<br />
<br />
The <tt>-w</tt> or <tt>--warn</tt> option may be used to warn on any types, attributes, classes, or permissions from a <tt>neverallow</tt> rule that could not be resolved<br />
within the <tt>sepolicy</tt> file. This can be normal due to differences between the policy from which the <tt>neverallow</tt> rules were taken and the policy<br />
being checked. Such values are ignored for the purposes of <tt>neverallow</tt> checking.<br />
<br />
The <tt>-d</tt> or <tt>--debug</tt> option may be used to cause sepolicy-analyze to emit the <tt>neverallow</tt> rules as it parses them. This is principally a debugging facility for the parser but could also be used to extract <tt>neverallow</tt> rules from a full <tt>policy.conf</tt> file and output them in a more easily parsed format.<br />
<br />
These <tt>neverallow</tt> rules are also used by the Andriod CTS to check for policy conformance, see <tt>cts/tools/selinux/SELinuxNeverallowTestGen.py</tt> that generates Java methods.<br />
<br />
Example output using the <tt>-d</tt> option:<br />
<pre><br />
sepolicy-analyze out/target/product/generic/root/sepolicy neverallow -d -f out/target/product/generic/obj/ETC/sepolicy_intermediates/policy.conf<br />
<br />
neverallow domain kernel : process { transition dyntransition };<br />
neverallow kernel { file_type fs_type - rootfs } : file { entrypoint execute_no_trans };<br />
neverallow { domain - init } fsck : process transition;<br />
...<br />
neverallow system_server { bluetooth_data_file nfc_data_file shell_data_file app_data_file } : file open;<br />
neverallow system_server dex2oat_exec : file { execute execute_no_trans };<br />
neverallow system_server { dev_type - frp_block_device } : blk_file { append create link unlink relabelfrom rename setattr write open read ioctl lock };<br />
</pre><br />
<br />
== setool ==<br />
The <tt>setool</tt> utility is not used during the build process and is intended only to produce entries for the <tt>mac_permissions.xml</tt> file and verify a correctly formated file. It is not supplied in AOSP.<br />
<br />
Usage:<br />
<pre><br />
Usage: setool [flags] <--build keys|package OR --policy policyFile> <apk> [ <apk> ]*<br />
<br />
Tool to help build and verify MMAC install policies.<br />
<br />
--build Generate an MMAC style policy stanza with a given --seinfo string.<br />
The resulting stanza can then be used as an entry in the mac_permissions.xml file.<br />
<br />
package Policy entry that contains the package name inside the signature stanza.<br />
<br />
keys Print just a signer tag which contains the hex encoded X.509 certs of the app.<br />
<br />
--policy Determine if the apks pass the supplied policy by printing the seinfo tag<br />
that would be assigned or null otherwise.<br />
<br />
apk An apk to analyze. All supplied apks must be absolute paths or relative to<br />
--apkdir (which defaults to the current directory).<br />
<br />
Flags:<br />
--help Prints this message and exits.<br />
--apkdir Directory to search for supplied apks (default to current directory).<br />
--verbose Increase the amount of debug statements.<br />
--outfile Dump output to the given file (defaults to stdout).<br />
--seinfo Create an seinfo tag for all generated policy stanzas. This is a required flag if using the --build option.<br />
</pre><br />
<br />
The following examples show the generation and verification process:<br />
<pre><br />
setool --build package --seinfo service_app --outfile sepolicy/mac_permissions.xml RunIsolatedService.apk<br />
</pre><br />
<br />
The output will be:<br />
<pre><br />
<signer signature="- certificate will be here -"><br />
<package name="com.example.runisolatedservice"><br />
<seinfo value="service_app" /><br />
</package><br />
</signer><br />
</pre><br />
<br />
Note that for verification via <tt>setool</tt> requires the segment to be included within a correctly formatted <tt>mac_permissions.xml</tt> file (i.e. have the<tt><nowiki> <policy></nowiki></tt> <tt><nowiki></policy></nowiki></tt> tags present:<br />
<pre><br />
setool --policy sepolicy/mac_permissions.xml RunIsolatedService.apk<br />
/pre><br />
<br />
The output will then be:<br />
<pre><br />
seinfo tag service_app assigned to ./RunIsolatedService.apk<br />
</pre><br />
<br />
= uid To username Utility =<br />
This utility will take an Android <tt>uid</tt> and convert it to a <tt>username</tt>. The code is a modified version from <tt>bionic/libc/bionic/stubbs.cpp</tt> that converts an Android <tt>uid</tt> to <tt>username</tt>.<br />
<br />
To compile this utility:<br />
<pre><br />
cc -std=gnu99 uid_to_username.c -o uid_to_username -include $ANDROID_BUILD_TOP/system/core/include/private/android_filesystem_config.h<br />
</pre><br />
<br />
<pre><br />
#include <stdio.h><br />
#include <stdlib.h><br />
<br />
int main(int argc, char **argv)<br />
{<br />
uid_t uid;<br />
<br />
if (argc != 2) {<br />
printf("Converts an Android uid to username\n");<br />
printf("usage: %s uid\n\n", argv[0]);<br />
exit(1);<br />
}<br />
<br />
uid = atoi(argv[1]);<br />
uid_t appid = uid % AID_USER;<br />
uid_t userid = uid / AID_USER;<br />
<br />
if (appid >= AID_ISOLATED_START) {<br />
printf("username: u%u_i%u\n", userid, appid - AID_ISOLATED_START);<br />
} else if (userid == 0 && appid >= AID_SHARED_GID_START) {<br />
printf("username: all_a%u\n", appid - AID_SHARED_GID_START);<br />
} else if (appid < AID_APP) {<br />
for (size_t n = 0; n < android_id_count; n++) {<br />
if (android_ids[n].aid == appid) {<br />
printf("username: u%u_%s\n", userid, android_ids[n].name);<br />
printf("Note that only \"%s\" will be shown in 'ps' etc.\n", android_ids[n].name);<br />
exit(0);<br />
}<br />
}<br />
printf("Failed - invalid uid\n");<br />
} else {<br />
printf("username: u%u_a%u\n", userid, appid - AID_APP);<br />
}<br />
exit(0);<br />
}<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_SEforAndroid_1 | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[LibselinuxAPISummary | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_SEforAndroid_2NB SEforAndroid 22015-03-15T14:39:52Z<p>RichardHaines: </p>
<hr />
<div>= Policy Configuration File Formats =<br />
This section details the Android policy configuration file formats with worked examples.<br />
<br />
The following files are described:<br />
* <tt>file_contexts<br />
* seapp_contexts<br />
* service_contexts<br />
* property_contexts<br />
* mac_permissions.xml<br />
* eops.xml<br />
* ifw.xml</tt><br />
<br />
== file_contexts ==<br />
This file is used to associate default contexts to files for file systems that support extended file attributes. It is used by the file labeling commands such as <tt>restorecon</tt>.<br />
<br />
The [[NB_SEforAndroid_1#Checking File Labels | Checking File Labels]] section describes how changes in this file are detected.<br />
<br />
The build process supports additional <tt>file_contexts</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Processing Device Policy | Processing Device Policy]] section.<br />
<br />
Each line within the file consists of the following:<br />
<pre><br />
pathname_regexp [file_type] security_context<br />
</pre><br />
<br />
'''Where:'''<br />
{| border="1"<br />
| <tt>pathname_regexp</tt><br />
| An entry that defines the pathname that may be in the form of a regular expression (see the example file_contexts file below). <br />
<br />
|-<br />
| <tt>file_type</tt><br />
| One of the following optional file_type entries (note if blank means "match all file types"):<br />
: '<tt>-b</tt>' - Block Device '<tt>-c</tt>' - Character Device<br />
: '<tt>-d</tt>' - Directory '<tt>-p</tt>' - Named Pipe (FIFO)<br />
: '<tt>-l</tt>' - Symbolic Link '<tt>-s</tt>' - Socket File<br />
: '<tt>--</tt>' - Ordinary file<br />
<br />
This entry equates to the file mode and also the file related object class (e.g. <tt>S_IFSOCK</tt> = <tt>sock_file</tt> class).<br />
<br />
|-<br />
| security_context<br />
| This entry can be either:<br />
* The security context that will be assigned to the file.<br />
* A value of <tt><nowiki><<none>></nowiki></tt> that states matching files should not be re-labeled. <br />
<br />
<br />
|}<br />
<br />
Example entries:<br />
<pre><br />
###########################################<br />
# Root<br />
/u:object_r:rootfs:s0<br />
<br />
# Data files<br />
/adb_keys u:object_r:adb_keys_file:s0<br />
/default\.prop u:object_r:rootfs:s0<br />
/fstab\..* u:object_r:rootfs:s0<br />
/init\..* u:object_r:rootfs:s0<br />
/res(/.*)? u:object_r:rootfs:s0<br />
/ueventd\..* u:object_r:rootfs:s0<br />
...<br />
##########################<br />
# Devices<br />
#<br />
/dev(/.*)? u:object_r:device:s0<br />
/dev/akm8973.* u:object_r:sensors_device:s0<br />
/dev/accelerometer u:object_r:sensors_device:s0<br />
/dev/adf[0-9]* u:object_r:graphics_device:s0<br />
/dev/adf-interface[0-9]*\.[0-9]* u:object_r:graphics_device:s0<br />
/dev/adf-overlay-engine[0-9]*\.[0-9]* u:object_r:graphics_device:s0<br />
...<br />
/dev/socket/adbd u:object_r:adbd_socket:s0<br />
/dev/socket/dnsproxyd u:object_r:dnsproxyd_socket:s0<br />
/dev/socket/dumpstate u:object_r:dumpstate_socket:s0<br />
...<br />
#############################<br />
# System files<br />
#<br />
/system(/.*)? u:object_r:system_file:s0<br />
/system/bin/sh -- u:object_r:shell_exec:s0<br />
/system/bin/run-as -- u:object_r:runas_exec:s0<br />
<br />
#############################<br />
# asec containers<br />
/mnt/asec(/.*)? u:object_r:asec_apk_file:s0<br />
/mnt/asec/[^/]+/res\.zip u:object_r:asec_public_file:s0<br />
/mnt/asec/[^/]+/lib(/.*)? u:object_r:asec_public_file:s0<br />
/data/app-asec(/.*)? u:object_r:asec_image_file:s0<br />
</pre><br />
<br />
These are example entries from <tt>device/asus/flo/sepolicy/file_contexts</tt>, note the '<tt>'''by-name'''</tt>' entry. This is resolved by <tt>ueventd</tt> as explained in the following commit:<br />
: [https://android.googlesource.com/platform/system/core/+/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a https://android.googlesource.com/platform/system/core/][https://android.googlesource.com/platform/system/core/+/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a +/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a]<br />
<pre><br />
# efs block labeling<br />
/dev/block/platform/msm_sdcc\.1/by-name/m9kefs[123c] u:object_r:efs_block_device:s0<br />
# Root block labeling<br />
/dev/block/mmcblk0 u:object_r:root_block_device:s0<br />
# modemst1, modemst2, fsg, ssd labeling<br />
/dev/block/platform/msm_sdcc\.1/by-name/modemst[12] u:object_r:modem_block_device:s0<br />
/dev/block/platform/msm_sdcc\.1/by-name/fsg u:object_r:modem_block_device:s0<br />
/dev/block/platform/msm_sdcc\.1/by-name/ssd u:object_r:modem_block_device:s0<br />
</pre><br />
<br />
It is also worth noting that the '<tt>'''by-name'''</tt>' (or '<tt>'''by-num'''</tt>') entry can exist in fstab files as shown in this example taken from <tt>device/asus/flo/fstab.flo</tt>:<br />
<pre><br />
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait<br />
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4<br />
</pre><br />
<br />
== seapp_contexts ==<br />
This file is loaded and sorted into memory using the precedence rules explained below on first use by of one of the following Android <tt>libselinux</tt> functions:<br />
* <tt>selinux_android_setcontext</tt> - Computes process security contexts.<br />
* <tt>selinux_android_setfilecon</tt> - Computes file/directory security contexts.<br />
<br />
The [[NB_SEforAndroid_1#Checking File Labels | Checking File Labels]] section describes how changes in this file are detected.<br />
<br />
The build process supports additional <tt>seapp_contexts</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Processing Device Policy | Processing Device Policy]] section.<br />
<br />
The following sections will show:<br />
# The default <tt>external/sepolicy/seapp_contexts</tt> file entries.<br />
# A description of the <tt>seapp_contexts</tt> entries and their usage.<br />
# A brief description of how a context is computed using either the <tt>selinux_android_setcontext</tt> or <tt>selinux_android_ setfilecon</tt> function using the <tt>seapp_contexts</tt> file entries.<br />
# Examples of computed domain and directory contexts for various apps.<br />
<br />
=== Default Entries ===<br />
The default Android <tt>external/sepolicy/seapp_contexts</tt> file contains the following entries:<br />
<pre><br />
isSystemServer=true domain=system_server<br />
user=system domain=system_app type=system_app_data_file<br />
user=bluetooth domain=bluetooth type=bluetooth_data_file<br />
user=nfc domain=nfc type=nfc_data_file<br />
user=radio domain=radio type=radio_data_file<br />
user=shared_relro domain=shared_relro<br />
user=shell domain=shell type=shell_data_file<br />
user=_isolated domain=isolated_app levelFrom=user<br />
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
</pre><br />
<br />
=== Entry Definitions ===<br />
The following has been extracted from the default file with some additional comments that describe the parameters and how they are used to compute a context:<br />
<br />
Input selectors from <tt>seapp_contexts</tt> file: <br />
: <tt>isSystemServer (boolean)</tt><br />
: <tt>isOwner (boolean)</tt><br />
: <tt>user (string)</tt><br />
: <tt>seinfo (string)</tt><br />
: <tt>name (string)</tt> - A package name e.g. <tt>com.example.demo</tt><br />
: <tt>path (string)</tt> - A path name (added to ensure correct labeling of some files).<br />
<br />
Notes:<br />
: <tt>isSystemServer=true</tt> can only be used once.<br />
: An unspecified <tt>isSystemServer</tt> defaults to false.<br />
: <tt>isOwner=true</tt> will only match for owner/primary user.<br />
: <tt>isOwner=false</tt> will only match for secondary users.<br />
: If unspecified, the entry can match either case.<br />
: An unspecified string selector will match any value.<br />
: A <tt>user</tt> string selector that ends in <tt><nowiki>*</nowiki></tt> will perform a prefix match.<br />
: <tt>user=_app</tt> will match any regular app UID.<br />
: <tt>user=_isolated</tt> will match any isolated service UID.<br />
: All specified input selectors in an entry must match (i.e. logical AND).<br />
: Matching is case-insensitive.<br />
<br />
Precedence rules:<br />
: 1) <tt>isSystemServer=true</tt> before <tt>isSystemServer=false</tt>.<br />
: 2) Specified <tt>isOwner=</tt> before unspecified <tt>isOwner=boolean</tt>. <br />
: 3) Specified <tt>user= string</tt> before unspecified <tt>user= string</tt>.<br />
: 4) Fixed <tt>user= string</tt> before <tt>user= prefix</tt> (i.e. ending in <tt><nowiki>*</nowiki></tt>).<br />
: 5) Longer <tt>user= prefix</tt> before shorter <tt>user= prefix</tt>. <br />
: 6) Specified <tt>seinfo= string</tt> before unspecified <tt>seinfo= string</tt>.<br />
: 7) Specified <tt>name= string</tt> before unspecified <tt>name= string</tt>.<br />
: 8) Specified <tt>path= string</tt> before unspecified <tt>path= string</tt>.<br />
<br />
Outputs:<br />
: <tt>domain (string)</tt> - The <tt>type</tt> component of a process context.<br />
: <tt>type (string)</tt> - The <tt>type</tt> component of a file/directory context.<br />
: <tt>levelFrom</tt> (<tt>string</tt><nowiki>; one of </nowiki><tt>none</tt>, <tt>all</tt>, <tt>app</tt>, or <tt>user</tt>) - A level that will be automatically computed based on the parameter.<br />
: <tt>level (string)</tt> - A predefined level (e.g. <tt>s0:c1022.c1023</tt>)<br />
<br />
Notes:<br />
: Only entries that specify <tt>domain=</tt> will be used for app process labeling.<br />
: Only entries that specify <tt>type=</tt> will be used for app directory labeling.<br />
: <tt>levelFrom=user</tt> is only supported for <tt>_app</tt> or <tt>_isolated</tt> UIDs.<br />
: <tt>levelFrom=app</tt> or <tt>levelFrom=all</tt> is only supported for <tt>_app</tt> UIDs.<br />
: <tt>level</tt> may be used to specify a fixed level for any UID. <br />
<br />
=== Computing a Context ===<br />
This section explains the process to compute a context using parameters supplied by the <tt>selinux_android_setcontext</tt>, <tt>selinux_android_setfilecon</tt>,<tt> selinux_android_restorecon</tt> and<tt> selinux_android_restorecon_pkgdir</tt> functions plus the precedence sorted contents of the <tt>seapp_contexts</tt> file, some examples are then shown.<br />
<br />
The context is computed first by converting the <tt>uid</tt> parameter to a string that is used to match the <tt>user</tt> component in the <tt>seapp_contexts</tt> entry as follows:<br />
# If an Android system service, the <tt>uid</tt> parameter is converted to a <tt>username</tt> string via an internal Android table (e.g. "radio", "system").<br />
# If an isolated service the <tt>_isolated</tt> string is used as the <tt>username</tt>.<br />
# For any other app or service <tt>_app</tt> string is used as the <tt>username</tt>.<br />
<br />
Then cycling through each precedence sorted <tt>seapp_contexts</tt> entry, check each component as follows until a match is found or generate an error log entry:<br />
<br />
* The <tt>isSystemServer</tt> component is matched against the <tt>isSystemServer</tt> parameter. If a match or <tt>isSystemServer</tt> not present check remaining components, else skip entry.<br />
* The <tt>isOwner</tt> boolean determines whether the remaining components should be checked or skip this entry. The rules are:<br />
** If <tt>isOwner</tt> not present then check remaining components.<br />
** If set <tt>true</tt> and the <tt>uid</tt> computes to the owner or primary user then check remaining components, else skip this entry.<br />
** If set <tt>false</tt> and the <tt>uid</tt> computes to a secondary user then check remaining components, else skip this entry.<br />
* The computed <tt>username</tt> is matched against the <tt>user</tt> component. If a match or <tt>user</tt> not present check remaining components, else skip entry. <br />
* The <tt>seinfo</tt> component is matched against the <tt>seinfo</tt> parameter. If a match or <tt>seinfo</tt> not present check remaining components, else skip entry.<br />
* The <tt>name</tt> component is matched against the <tt>pkgname</tt> parameter. If a match or <tt>name</tt> not present check remaining components, else skip entry. <br />
* The <tt>path</tt> component is matched against a computed path of a file having its context restored via one of the restorecon functions. If a match or <tt>path</tt> not present check remaining components, else skip entry. <br />
* The <tt>domain</tt> component is used to set the process context for the <tt>selinux_android_setcontext</tt> function and must match a type declared in the policy. If <tt>domain</tt> not present skip this entry.<br />
* The <tt>type</tt> component is used to set the file context for the <tt>selinux_android_setfilecon</tt> function and must match a type declared in the policy. If <tt>type</tt> not present skip this entry.<br />
* The <tt>levelFrom</tt> and <tt>level</tt> components if present will be used to determine the <tt>level</tt> component of the security context as follows:<br />
** if <tt>levelFrom=none</tt> then use current level.<br />
** else if <tt>levelFrom=app</tt> then compute a category pair based on a derived app id with a starting base of <tt>c512,c768</tt> base.<br />
** else if <tt>levelFrom=user</tt> then compute a category pair based on a derived user id with a starting base of <tt>c0,c256</tt> base.<br />
** else if <tt>levelFrom=all</tt> then compute a category pair based on a derived app id with a starting base of <tt>c512,c768</tt> base, and also compute another category pair based on a derived user id with a starting base of <tt>c0,c256</tt> base.<br />
** else if <tt>level</tt> has a value use this as the context level.<br />
<br />
The overall objective is that the computed levels should never be the same for different apps, users, or a combination of both. By encoding each ID as a category pair, up to 2^16 app IDs and up to 2^16 user IDs within the 1024 categories can be represented, including the <tt>levelFrom=all</tt> or mixed usage of <tt>levelFrom=app</tt> and <tt>levelFrom=user</tt>.<br />
<br />
If a valid entry is found, then:<br />
# If a context for the <tt>selinux_android_setcontext</tt> function has been computed, it is validated against policy, if correct <tt>'''setcon'''(3)</tt> is used to set the process context.<br />
# If a context for <tt>selinux_android_setfilecon</tt>, <tt>selinux_android_restorecon</tt> or<tt> selinux_android_restorecon_pkgdir</tt> functions have been computed, it is validated against policy, if correct <tt>'''setfilecon'''(3)</tt> or <tt>'''lsetfilecon'''(3)</tt> are used to set the context for labeling the file.<br />
<br />
If a valid entry is not found an error is generated in the log currently formatted as follows:<br />
: <tt>seapp_context_lookup: No match for app with uid uid, seinfo seinfo, name pkgname</tt><br />
<br />
==== Computing Process Context Examples ====<br />
The following is an example taken as the system server is loaded:<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 1000<br />
isSystemServer true<br />
seinfo null<br />
pkgname null<br />
<br />
seapp_contexts lookup parameters:<br />
uid 1000<br />
isSystemServer true<br />
seinfo null<br />
pkgname null<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
isSystemServer=true domain=system_server<br />
<br />
Outputs:<br />
domain system_server<br />
level s0<br />
<br />
Computed context = u:r:system_server:s0<br />
username computed from uid = system<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:system_server:s0 system 836 63 system_server<br />
</pre><br />
<br />
This is the ’radio’ application that is part of the platform:<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 1001<br />
isSystemServer false<br />
seinfo platform<br />
pkgname com.android.phone<br />
<br />
seapp_contexts lookup parameters:<br />
uid 1001 (computes user=radio entry)<br />
isSystemServer false<br />
seinfo platform<br />
pkgname com.android.phone<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=radio domain=radio type=radio_data_file<br />
<br />
Outputs:<br />
domain radio<br />
level s0<br />
<br />
Computed context = u:r:radio:s0<br />
username computed from uid = radio<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:radio:s0 radio 619 62 com.android.phone<br />
</pre><br />
<br />
This is the 'SEAndroid Admin Manager' application that is part of the SEAndroid release, however it is treated as an untrusted app (it is installed as a privileged app):<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 10013<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.android.seandroid_admin<br />
<br />
seapp_contexts lookup parameters:<br />
isSystemServer false<br />
uid 10013 (computes user=_app entry) <br />
seinfo default<br />
pkgname com.android.seandroid_admin<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
<br />
Outputs:<br />
domain untrusted_app<br />
level s0:c512,c768<br />
<br />
Computed context = u:r:untrusted_app:s0:c512,c768<br />
username computed from uid = u0_a13<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:untrusted_app:s0:c512,c768 u0_a13 827 45 com.android.seandroid_admin<br />
</pre><br />
<br />
This is a third party app (<tt>com.example.runisolatedservice</tt>) to run an isolated service that has been installed as a privileged app (<tt>com.se4android.isolatedservice</tt>):<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 10054<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.example.runisolatedservice<br />
<br />
seapp_contexts lookup parameters:<br />
uid 10054 (computes user=_app entry)<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.example.runisolatedservice<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
<br />
Outputs:<br />
domain untrusted_app<br />
level s0:c512,c768<br />
<br />
Computed context = u:r:untrusted_app:s0:c512,c768<br />
username computed from uid = u0_a54<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:untrusted_app:s0:c512,c768 u0_a54 1138 64 com.example.runisolatedservice<br />
</pre><br />
<br />
This is the isolated service installed as a privileged app (<tt>com.se4android.isolatedservice</tt>):<br />
<pre><br />
selinux_android_setcontext() parameters:<br />
uid 99000<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.se4android.isolatedservice<br />
<br />
seapp_contexts lookup parameters:<br />
uid 99000 (computes user=_isolated entry)<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.se4android.isolatedservice<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=_isolated domain=isolated_app levelFrom=user<br />
Note that uid's 99000-99999 are reserved for isolated services - see:<br />
system/core/include/private/android_filesystem_config.h<br />
<br />
Outputs:<br />
domain isolated_app<br />
level s0:c512,c768<br />
<br />
Computed context = u:r:isolated_app:s0:c512,c768<br />
username computed from uid = u0_i0<br />
<br />
Result using ps -Z command:<br />
LABEL USER PID PPID NAME<br />
u:r:isolated_app:s0:c512,c768 u0_i0 1140 62 com.se4android.isolatedservice<br />
</pre><br />
<br />
==== Computing File Context Example ====<br />
The following example is from the third party isolated app:<br />
<pre><br />
selinux_android_setfilecon() parameters:<br />
pkgdir /data/data/com.example.runisolatedservice<br />
pkgname com.example.runisolatedservice<br />
seinfo default<br />
uid 10046<br />
<br />
seapp_contexts lookup parameters:<br />
uid 10046 (computes user=_app entry)<br />
isSystemServer false<br />
seinfo default<br />
pkgname com.example.runisolatedservice<br />
path null<br />
<br />
Matching seapp_contexts entry:<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
<br />
Outputs:<br />
type app_data_file<br />
level s0:c512,c768<br />
<br />
Computed context = u:object_r:app_data_file:s0:c512,c768<br />
username computed from uid = u0_a46<br />
<br />
Result from /data/data directory using ls -Z command:<br />
drwxr-x--x u0_a46 u0_a46 u:object_r:app_data_file:s0:c512,c768 com.example.runisolatedservice<br />
</pre><br />
<br />
== property_contexts ==<br />
This file holds property service keys and their contexts that are matched against property names using <tt>'''selabel_lookup'''(3)</tt>. The returned context will then be used as the target context as described in the example below to determine whether the property is allowed or denied (see <tt>system/core/init/property_service.c</tt> and <tt>init.c</tt>).<br />
<br />
The build process supports additional <tt>property_contexts</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Processing Device Policy | Processing Device Policy]] section.<br />
<br />
When <tt>'''selabel_open'''(3)</tt> is called specifying this file it will be read into memory and sorted using <tt>'''qsort'''(3)</tt>, subsequent calls using <tt>'''selabel_lookup'''(3)</tt> will then retrieve the appropriate context based on matching the <tt>property_key</tt>. <br />
<br />
'''Example:'''<br />
<br />
Use <tt>adb</tt> to reload the SELinux policy:<br />
<pre><br />
adb shell su 0 setprop selinux.reload_policy 1<br />
</pre><br />
<br />
Sample <tt>property_contexts</tt> file entries are:<br />
<pre><br />
# property_key context to be applied on match<br />
net.rmnet u:object_r:net_radio_prop:s0<br />
net.gprs u:object_r:net_radio_prop:s0<br />
net.ppp u:object_r:net_radio_prop:s0<br />
net.qmi u:object_r:net_radio_prop:s0<br />
net.lte u:object_r:net_radio_prop:s0<br />
net.cdma u:object_r:net_radio_prop:s0<br />
net.dns u:object_r:net_radio_prop:s0<br />
sys.usb.config u:object_r:system_radio_prop:s0<br />
ril. u:object_r:radio_prop:s0<br />
gsm. u:object_r:radio_prop:s0<br />
persist.radio u:object_r:radio_prop:s0<br />
<br />
debug. u:object_r:debug_prop:s0<br />
debug.db. u:object_r:debuggerd_prop:s0<br />
log. u:object_r:shell_prop:s0<br />
service.adb.root u:object_r:shell_prop:s0<br />
service.adb.tcp.port u:object_r:shell_prop:s0<br />
<br />
persist.audio. u:object_r:audio_prop:s0<br />
persist.logd. u:object_r:logd_prop:s0<br />
persist.sys. u:object_r:system_prop:s0<br />
persist.service. u:object_r:system_prop:s0<br />
persist.service.bdroid. u:object_r:bluetooth_prop:s0<br />
persist.security. u:object_r:system_prop:s0<br />
<br />
# selinux non-persistent properties<br />
selinux. u:object_r:security_prop:s0<br />
<br />
# default property context (* is wild card match)<br />
* u:object_r:default_prop:s0<br />
</pre><br />
<br />
The property service will call <tt>selabel_lookup</tt> with parameters consisting of the handle passed from <tt>selabel_open</tt>, a buffer to hold the returned context, and the object name "<tt>selinux.reload_policy</tt>" to look-up (the final parameter is not used):<br />
<pre><br />
selabel_lookup(handle, &context, "selinux.reload_policy", 1);<br />
</pre><br />
<br />
The following context will be returned as the look-up process will search for a match based on the length of the <tt>property_key</tt> (and will therefore match against "<tt>selinux.</tt>"):<br />
<pre><br />
u:object_r:security_prop:s0<br />
</pre><br />
<br />
The property service will then validate whether the service has permission by issuing an <tt>'''selinux_check_access'''(3)</tt> call with the following parameters:<br />
<pre><br />
source context: u:r:su:s0<br />
target context: u:object_r:security_prop:s0<br />
class: property_service<br />
permission: set<br />
</pre><br />
<br />
The policy would then decide whether to allow or deny the property request. Using the [[#sepolicy_check | sepolicy-check]] tool will show that this will be denied by the current policy (a <tt>dontaudit</tt> rule is in the policy, however <tt>su</tt> runs permissive anyway):<br />
<pre><br />
sepolicy-check -s su -t security_prop -c property_service -p set -P out/target/product/generic/root/sepolicy<br />
echo $?<br />
1<br />
</pre><br />
<br />
== service_contexts ==<br />
This file holds binder service keys and their contexts that are matched against binder object names using <tt>'''selabel_lookup'''(3)</tt>. The returned context will then be used as the target context as described in the example below to determine whether the binder service is allowed or denied (see <tt>frameworks/native/cmds/servicemanager/servicemanager.c</tt>).<br />
<br />
The build process supports additional <tt>service_contexts</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Building the Policy | Building the Policy]] section.<br />
<br />
When <tt>'''selabel_open'''(3)</tt> is called specifying this file it will be read into memory and sorted using <tt>'''qsort'''(3)</tt>, subsequent calls using <tt>'''selabel_lookup'''(3)</tt> will then retrieve the appropriate context based on matching the <tt>service_key</tt>. <br />
<br />
'''Example:'''<br />
<br />
The <tt>healthd</tt> process wants to start a binder service "<tt>batterypropreg</tt>" (see <tt>frameworks/base/services/java/com/android/server/BatteryService.java</tt>).<br />
<br />
Sample <tt>service_contexts</tt> file entries are:<br />
<pre><br />
# service_key context to be applied on match<br />
batteryproperties u:object_r:healthd_service:s0<br />
batterystats u:object_r:system_server_service:s0<br />
battery u:object_r:system_server_service:s0<br />
<br />
# default service context (* is wild card match)<br />
* u:object_r:default_android_service:s0<br />
</pre><br />
<br />
The service manager will call <tt>selabel_lookup</tt> with parameters consisting of the handle passed from <tt>selabel_open</tt>, a buffer to hold the returned context, and the object name "<tt>batterypropreg</tt>" to look-up (the final parameter is not used):<br />
<pre><br />
selabel_lookup(handle, &context, "batterypropreg", 1);<br />
</pre><br />
<br />
The following context will be returned as the look-up process will search for a match based on the length of the <tt>service_key</tt> (and will therefore match against "<tt>battery</tt>"):<br />
<pre><br />
u:object_r:system_server_service:s0<br />
</pre><br />
<br />
The service manager will then validate whether the service has permission by issuing an <tt>'''selinux_check_access'''(3)</tt> call with the following parameters:<br />
<pre><br />
source context: u:r:healthd:s0<br />
target context: u:object_r:system_server_service:s0<br />
class: service_manager<br />
permission: add<br />
</pre><br />
<br />
The policy would then decide whether to allow or deny the service. Using the [[#sepolicy_check|sepolicy-check]] tool will show that this will be allowed by the current policy:<br />
<pre><br />
sepolicy-check -s healthd -t system_server_service \<br />
-c service_manager -p add \<br />
-P out/target/product/generic/root/sepolicy<br />
Match found!<br />
</pre><br />
<br />
== mac_permissions.xml ==<br />
The <tt>mac_permissions.xml</tt> file is used to configure Run/Install-time MMAC policy and provides x.509 certificate to <tt>seinfo</tt> string mapping so that Zygote spawns an app in the correct domain. See the [[#Computing a Context| Computing a Context]] section for how this is achieved using information also contained in the <tt>seapp_contexts</tt> file (AOSP and SEAndroid).<br />
<br />
An example AOSP <tt>mac_permissions.xml</tt> file that shows the <tt><nowiki><default></nowiki></tt> entry is:<br />
<pre><br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<policy><br />
<!-- Platform dev key in AOSP --><br />
<br />
<signer signature="@PLATFORM" ><br />
<seinfo value="platform" /><br />
</signer><br />
<br />
<!-- All other keys --><br />
<default><br />
<seinfo value="default" /><br />
</default><br />
<br />
</policy><br />
</pre><br />
<br />
<br />
The <tt><nowiki><signer signature=</nowiki></tt> entry may have the public base16 signing key present in the string or it may have an entry starting with <tt>@</tt>, then a keyword as shown that allows the key to be extracted from a <tt>pem</tt> file as discussed in the [[#insertkeys.py | insertkeys.py]] section. If a base16 key is required, it can be extracted from a package using the [[#post_process_mac_perms | post_process_mac_perms]] and [[#setool | setool]] utilities. <br />
<br />
The build process supports additional <tt>mac_permissions.xml</tt> files allowing devices to specify their entries as described in the [[NB_SEforAndroid_1#Processing Device Policy|Processing Device Policy]] section. An example SEAndroid test device <tt>mac_permissions.xml</tt> file is:<br />
<pre><br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<policy><br />
<br />
<!-- NET_APPS key and seinfo for SE4A-NetClient & SE4A-NetServer apps. --><br />
<signer signature="@NET_APPS" ><br />
<package name="com.se4android.netclient" ><br />
<seinfo value="netclient" /><br />
</package><br />
<package name="com.se4android.netserver" ><br />
<seinfo value="netserver" /><br />
</package><br />
</signer><br />
<br />
</policy><br />
</pre><br />
<br />
==== Policy Rules ====<br />
The following rules have been extracted from the AOSP <tt>mac_permissions.xml</tt> file with the one SEAndroid addition noted:<br />
<br />
* A signature is a hex encoded X.509 certificate or a tag defined in <tt>keys.conf</tt> and is required for each <tt>signer</tt> tag.<br />
* A <tt>signer</tt> tag may contain a <tt>seinfo</tt> tag and multiple package stanzas.<br />
* A <tt>default</tt> tag is allowed that can contain policy for all apps not signed with a previously listed cert. It may not contain any inner <tt>package</tt> stanzas.<br />
* Each <tt>signer</tt>/<tt>default</tt>/<tt>package</tt> tag is allowed to contain one <tt>seinfo</tt> tag. This tag represents additional info that each app can use in setting a SELinux security context on the eventual process.<br />
* When a package is installed the following logic is used to determine what <tt>seinfo</tt> value, if any, is assigned:<br />
** All signatures used to sign the app are checked first.<br />
** If a <tt>signer</tt> stanza has inner <tt>package</tt> stanzas, those stanza will be checked to try and match the package name of the app. If the package name matches then that <tt>seinfo</tt> tag is used. If no inner package matches then the outer <tt>seinfo</tt> tag is assigned.<br />
** The <tt>default</tt> tag is consulted last if needed.<br />
** If none of the cases apply then the app is denied install on the device. '''NOTE:''' This case only applies to SEAndroid.<br />
<br />
== eops.xml ==<br />
The following text has been taken from the SEAndroid <tt>/external/sepolicy/eops.xml</tt> file (so check if any changes) with a few minor additions (there is also a simple example in the [[#Eops Example | EOps Example]] section section).<br />
<br />
EOps (enterprise operations) is a security extension to the App Operations (AppOps) feature already present on Android 4.3+ devices. AppOps lets users fine tune certain functionality requested by apps by allowing the user to toggle these access rights.<br />
<br />
EOps seeks to provide an extension whereby a hard coded set of rules explicitly denies certain access rights to groups of installed apps. This feature will allow an enterprise like control over certain operations. EOps is not a front-end for SELinux which somehow ties app permissions to SELinux contexts. Rather, it is an extension of the middleware MAC (MMAC) controls that currently exist on Android 4.3+ devices. EOps uses the <tt>seinfo</tt> labels that are already assigned to apps upon install.<br />
<br />
The list of viable op tag names can be found in <tt>frameworks/base/core/java/android/app/AppOpsManager.java</tt>. Just use the string version of each op without the <tt>OP_</tt> prefix in your policy tags. These are the current 48 entries (March '15):<br />
<br />
<tt><br />
{| border="1"<br />
| COARSE_LOCATION<br />
| FINE_LOCATION<br />
| GPS<br />
<br />
|-<br />
| VIBRATE<br />
| READ_CONTACTS<br />
| WRITE_CONTACTS<br />
<br />
|-<br />
| READ_CALL_LOG<br />
| WRITE_CALL_LOG<br />
| READ_CALENDAR<br />
<br />
|-<br />
| WRITE_CALENDAR<br />
| WIFI_SCAN<br />
| POST_NOTIFICATION<br />
<br />
|-<br />
| NEIGHBORING_CELLS<br />
| CALL_PHONE<br />
| READ_SMS<br />
<br />
|-<br />
| WRITE_SMS<br />
| RECEIVE_SMS<br />
| RECEIVE_EMERGECY_SMS<br />
<br />
|-<br />
| RECEIVE_MMS<br />
| RECEIVE_WAP_PUSH<br />
| SEND_SMS<br />
<br />
|-<br />
| READ_ICC_SMS<br />
| WRITE_ICC_SMS<br />
| WRITE_SETTINGS<br />
<br />
|-<br />
| SYSTEM_ALERT_WINDOW<br />
| ACCESS_NOTIFICATIONS<br />
| CAMERA<br />
<br />
|-<br />
| RECORD_AUDIO<br />
| PLAY_AUDIO<br />
| READ_CLIPBOARD<br />
<br />
|-<br />
| WRITE_CLIPBOARD<br />
| TAKE_MEDIA_BUTTONS<br />
| TAKE_AUDIO_FOCUS<br />
<br />
|-<br />
| AUDIO_MASTER_VOLUME<br />
| AUDIO_VOICE_VOLUME<br />
| AUDIO_RING_VOLUME<br />
<br />
|-<br />
| AUDIO_MEDIA_VOLUME<br />
| AUDIO_ALARM_VOLUME<br />
| AUDIO_NOTIFICATION_VOLUME<br />
<br />
|-<br />
| AUDIO_BLUETOOTH_VOLUME<br />
| WAKE_LOCK<br />
| MONITOR_LOCATION<br />
<br />
|-<br />
| MONITOR_HIGH_POWER_LOCATION<br />
| GET_USAGE_STATS<br />
| MUTE_MICROPHONE<br />
<br />
|-<br />
| TOAST_WINDOW<br />
| PROJECT_MEDIA<br />
| ACTIVATE_VPN<br />
<br />
|}<br />
</tt><br />
<br />
All operations listed in the policy will have a mode of ignored. This means that empty data sets are returned to the caller when an operation is requested. This shadow data will then allow certain apps to presumably still operate. However, AOSP currently is not constructed to return these empty data sets and therefore acts as if ignored operations are completely denied (blocked). Because of this some apps might crash or behave oddly if you apply certain eops policy. In addition, while AOSP seems to have hooked the proper places to check operations against policy some of those hooks fail to follow through with the denial and still allow the operation to occur. Because of this, EOps will also fail to make those distinctions and likewise fail to enforce certain operations. Once the AOSP pieces are in place to return legitimate fake data and enforce all operations then of course eops, by its design, will also do the same.<br />
<br />
So, as long as AppOps is beta so too will EOps.<br />
<br />
A <tt>debug</tt> tag is also allowed which flips on the global debugging log functionality inside AppOps.<br />
<br />
Each stanza is grouped according to the <tt>seinfo</tt> tag that is assigned during install and thus creates a dependency with the <tt>mac_permissions.xml</tt> file. Each <tt>seinfo</tt> tag can then include any number of op tags. By including the op(s) you are simply removing that operation from working for all apps that have been installed with the listed <tt>seinfo</tt> label. These operations are restricted regardless of what any user controlled app ops policy may say. Any op not listed is therefore still subject to user control as normal.<br />
<br />
Lastly, there is no permissive mode for EOps. Once a policy is in place all ops listed are enforced.<br />
<br />
The following is an example <tt>eops.xml</tt> policy file that will stop the camera being used by any system or default app. The file installation is shown in the [[#buildeopbundle | Build Bundle Tools - buildeopbundle]] section:<br />
<pre><br />
<?xml version="1.0"?><br />
<app-ops><br />
<br />
<debug/><br />
<br />
<seinfo name="default"><br />
<op name="CAMERA"/><br />
</seinfo><br />
<br />
<seinfo name="system"><br />
<op name="CAMERA"/><br />
</seinfo><br />
<br />
</app-ops><br />
</pre><br />
<br />
== ifw.xml ==<br />
The example <tt>external/sepolicy/ifw.xml</tt> file has some comments regarding the tags, there is also an overview at [http://www.cis.syr.edu/~wedu/android/IntentFirewall/ http://www.cis.syr.edu/~wedu/android/IntentFirewall/]. <br />
<br />
The following is an example <tt>ifw.xml</tt> policy file that will stop the <tt>DemoIsolatedService</tt> being used by any app other than system apps or apps with the same signature. The file installation is shown in the [[#buildifwbundle | Build Bundle Tools - buildifwbundle]] section:<br />
<pre><br />
<?xml version="1.0"?><br />
<br />
<rules><br />
<br />
<!-- This will stop any app that is not a system app or<br />
does not have a matching signature from running the<br />
DemoIsolatedService service<br />
--><br />
<br />
<service log="true" block="true"><br />
<not><sender type="system|signature"/></not><<br />
<intent-filter /><br />
<component-filter name="com.se4android.isolatedservice/.DemoIsolatedService"/><br />
</service><br />
<br />
</rules><br />
</pre><br />
<br />
The events will be in the event log under the '<tt>ifw_intent_matched</tt>' tag, for example:<br />
<pre><br />
adb logcat -b events<br />
...<br />
...<br />
I/ifw_intent_matched( 390):[2,com.se4android.isolatedservice/.DemoIsolatedService,10058,1,NULL,NULL,NULL,NULL,0]<br />
...<br />
</pre><br />
<br />
= Policy Build Tools =<br />
This section covers the policy build tools located at <tt>external/sepolicy/tools</tt>. They are <tt>checkfc</tt>, <tt>checkseapp</tt> and <tt>insertkeys.py</tt>. There is also <tt>setool</tt> that is not used as part of the build process but generates <tt>mac_permissions.xml</tt> entries from packages.<br />
<br />
== checkfc ==<br />
The <tt>checkfc</tt> utility is used during the build process to validate the <tt>file_contexts</tt>, <tt>property_contexts</tt> and <tt>service_contexts</tt> files against policy. If validation fails <tt>checkfc</tt> will exit with an error.<br />
<br />
Usage:<br />
<pre><br />
usage: checkfc [OPTIONS] sepolicy context_file<br />
<br />
Parses a context file and checks for syntax errors.<br />
The context_file is assumed to be a file_contexts file<br />
unless explicitly switched by an option.<br />
<br />
OPTIONS:<br />
-p : context file represents a property_context file.<br />
</pre><br />
<br />
Example validating <tt>file_contexts</tt> file (note: no <tt>-p</tt> parameter):<br />
<pre><br />
checkfc out/target/product/generic/root/sepolicy out/target/product/generic/root/file_contexts<br />
</pre><br />
<br />
Example validating <tt>property_contexts</tt> file:<br />
<pre><br />
checkfc -p out/target/product/generic/root/sepolicy out/target/product/generic/root/property_contexts<br />
</pre><br />
<br />
== checkseapp ==<br />
The <tt>checkseapp</tt> utility is used during the build process to validate the <tt>seapp_contexts</tt> file against policy. If validation fails <tt>checkseapp</tt> will exit with an error. <tt>checkseapp</tt> also consolidates matching entries and outputs the valid file stripped of comments.<br />
<br />
Usage:<br />
<pre><br />
checkseapp [options] <input file><br />
<br />
Processes an seapp_contexts file specified by argument <input file> (default stdin) and allows later declarations to override previous ones on a match.<br />
<br />
Options:<br />
-h - print this help message<br />
-s - enable strict checking of duplicates. This causes the program to exit on a duplicate entry with a non-zero exit status<br />
-v - enable verbose debugging informations<br />
-p policy file - specify policy file for strict checking of output selectors against the policy<br />
-o output file - specify output file, default is stdout<br />
</pre><br />
<br />
An example command with output to <tt>stdout</tt> is:<br />
<pre><br />
checkseapp -p out/target/product/se4a_device/root/sepolicy out/target/product/se4a_device/root/seapp_contexts<br />
<br />
isSystemServer=true domain=system_server<br />
user=system domain=system_app type=system_app_data_file<br />
user=bluetooth domain=bluetooth type=bluetooth_data_file<br />
user=nfc domain=nfc type=nfc_data_file<br />
user=radio domain=radio type=radio_data_file<br />
user=shared_relro domain=shared_relro<br />
user=shell domain=shell type=shell_data_file<br />
user=_isolated domain=isolated_app levelFrom=user<br />
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user<br />
user=_app domain=untrusted_app type=app_data_file levelFrom=user<br />
user=_app seinfo=netclient domain=netclient_app type=net_apps_log_file levelFrom=app<br />
user=_app seinfo=netserver domain=netserver_app type=net_apps_log_file levelFrom=app<br />
</pre><br />
<br />
== insertkeys.py ==<br />
The <tt>insertkeys.py</tt> utility is used during the build process to insert signing keys into the <tt>mac_permissions.xml</tt> file. The keys are obtained from <tt>pem</tt> files and the entries to be replaced start with an <tt>@</tt> followed by a keyword. The <tt>external/sepolicy/keys.conf</tt> file contains corresponding entries that allow mapping of <tt>pem</tt> files to signatures as discussed in the [[#keys.conf File | keys.conf File]] section.<br />
<br />
<tt>insertkeys.py</tt> generates base16 encodings from the base64 <tt>pem</tt> files as this is required by the Android Package Manager Service. The resulting <tt>mac_permissions.xml</tt> file will also be stripped of comments and whitespace.<br />
<br />
Usage:<br />
<pre><br />
Usage: insertkeys.py [options] CONFIG_FILE MAC_PERMISSIONS_FILE [MAC_PERMISSIONS_FILE...]<br />
<br />
This tool allows one to configure an automatic inclusion of signing keys into the mac_permission.xml file(s) from the pem files. If multiple mac_permission.xml files are included then they are unioned to produce a final version.<br />
<br />
Options:<br />
--version show program's version number and exit<br />
-h, --help show this help message and exit<br />
-v, --verbose Print internal operations to stdout<br />
-o FILE, --output=FILE Specify an output file, default is stdout<br />
-c DIR, --cwd=DIR Specify a root (CWD) directory to run this from, itchdirs' AFTER loading the config file<br />
-t TARGET_BUILD_VARIANT, --target-build-variant=TARGET_BUILD_VARIANT Specify the TARGET_BUILD_VARIANT, defaults to eng<br />
-d KEY_DIRECTORY, --key-directory Specify a parent directory for keys<br />
</pre><br />
<br />
=== keys.conf File ===<br />
The <tt>keys.conf</tt> file is used by <tt>insertkeys.py</tt> for mapping the "<tt>@...</tt>" tags in <tt>mac_permissions.xml</tt>, <tt>mmac_types.xml</tt> and <tt>content_provider.xml</tt> signature entries with public keys found in <tt>pem</tt> files. The configuration file can be used in the <tt>BOARD_SEPOLICY_UNION</tt> variable and is processed via <tt>m4</tt> macros.<br />
<br />
<tt>insertkeys.py</tt> allows for mapping any string contained in <tt>TARGET_BUILD_VARIANT</tt> with a specific path to a <tt>pem</tt> file. Typically <tt>TARGET_BUILD_VARIANT</tt> is either <tt>user</tt>, <tt>eng</tt> or <tt>userdebug</tt>. Additionally "<tt>ALL</tt>" may be specified to map a path to any string specified in <tt>TARGET_BUILD_VARIANT</tt>. All tags are matched verbatim and all options are matched lowercase. The options are "<tt>tolowered</tt>" automatically for the user, it is convention to specify tags and options in all uppercase and tags start with <tt>@</tt>.<br />
<br />
An example <tt>keys.conf</tt> file is as follows:<br />
<pre><br />
#<br />
# Maps an arbitrary tag [TAGNAME] with the string contents found in<br />
# TARGET_BUILD_VARIANT. Common convention is to start TAGNAME with an @ and<br />
# name it after the base file name of the pem file.<br />
#<br />
# Each tag (section) then allows one to specify any string found in<br />
# TARGET_BUILD_VARIANT. Typcially this is user, eng, and userdebug. Another<br />
# option is to use ALL which will match ANY TARGET_BUILD_VARIANT string.<br />
#<br />
<br />
[@PLATFORM]<br />
ALL : $DEFAULT_SYSTEM_DEV_CERTIFICATE/platform.x509.pem<br />
<br />
[@MEDIA]<br />
ALL : $DEFAULT_SYSTEM_DEV_CERTIFICATE/media.x509.pem<br />
<br />
[@SHARED]<br />
ALL : $DEFAULT_SYSTEM_DEV_CERTIFICATE/shared.x509.pem<br />
<br />
# Example of ALL TARGET_BUILD_VARIANTS<br />
[@RELEASE]<br />
ENG : $DEFAULT_SYSTEM_DEV_CERTIFICATE/testkey.x509.pem<br />
USER : $DEFAULT_SYSTEM_DEV_CERTIFICATE/testkey.x509.pem<br />
USERDEBUG : $DEFAULT_SYSTEM_DEV_CERTIFICATE/testkey.x509.pem<br />
</pre><br />
<br />
The following is an example entry that will use a device specific key during the build process:<br />
<pre><br />
[@NET_APPS]<br />
ALL : $ANDROID_BUILD_TOP/device/demo_vendor/se4a_device/security/net_apps.x509.pem<br />
</pre><br />
<br />
== Build Bundle Tools ==<br />
The following tools will produce an Android "bundle" for updating MAC/MMAC policy within a zip file suitable for installation by the SEAdmin app. SEAdmin is currently hard-coded to look for these zip files in the SD Card device (<tt>/sdcard/</tt>).<br />
<br />
The [[#Using an Intent Example | buildsebundle]] section also shows how a policy can be updated by broadcasting an intent instead of using SEAdmin.<br />
<br />
=== buildsebundle ===<br />
The <tt>buildsebundle</tt> tool will produce an Android "bundle" for updating the core SE for Android policy within an <tt>selinux_bundle.zip</tt> file, suitable for installation by the SEAdmin app, although it is possible to update using an intent as described in the [[#Using an Intent Example | Using an Intent Example]] section.<br />
<br />
To be able to build the bundle the following mandatory files are required:<br />
: <tt>selinux_version</tt>, <tt>sepolicy</tt>, <tt>file_contexts</tt>, <tt>seapp_contexts</tt>, <tt>property_contexts</tt>, <tt>service_contexts</tt>, <tt>mac_permissions.xml</tt><br />
<br />
Usage:<br />
<pre><br />
usage: buildsebundle -k <private key.pk8> [-v <version>] [-r <previous hash>] \<br />
[-h] -- <selinux_version> <file_contexts> <property_contexts> \<br />
<sepolicy> <seapp_contexts> <service_contexts> <mac_permissions.xml><br />
<br />
This script builds a selinux policy bundle and supporting metadata file capable of being loaded via the ConfigUpdate mechanism. It takes a pkcs8 DER encoded RSA private key that is then used to sign the bundle. For AOSP development you'll typically want to use the key from the source tree at:<br />
build/target/product/security/testkey.pk8<br />
<br />
The built bundle will be written to selinux_bundle.zip which will include the signature metadata file of the bundle.<br />
<br />
OPTIONS:<br />
-h Show this message.<br />
-v Version of the built bundle. Defaults to 1.<br />
-r SHA-512 hash of the bundle to replace. Defaults to 'NONE'.<br />
</pre><br />
<br />
The following is an example where a new policy has been built with all required files. The wildcard can be used as <tt>buildsebundle</tt> will always use the mandatory list:<br />
<pre><br />
buildsebundle -k $ANDROID_BUILD_TOP/build/target/product/security/testkey.pk8 \<br />
-v 3 -- $ANDROID_BUILD_TOP/device/demo_device/se4a_device/new_sepolicy/*<br />
<br />
adb push selinux_bundle.zip /sdcard/<br />
</pre><br />
<br />
Once built, the bundle is pushed to the SD card and SEAdmin is used to update the policy (note that SEAdmin only reads the bundle from <tt>/sdcard</tt>).<br />
<br />
==== Using an Intent Example ====<br />
This example shows how to update a policy by broadcasting an intent in the same way as SEAdmin.<br />
<br />
Extract the <tt>selinux_bundle</tt> files from the <tt>selinux_bundle.zip</tt> file:<br />
<pre><br />
unzip selinux_bundle.zip<br />
Archive: selinux_bundle.zip<br />
inflating: update_bundle <br />
inflating: update_bundle_metadata<br />
</pre><br />
<br />
The two files contain:<br />
<br />
: <tt>'''update_bundle'''</tt> - Contains hex encoded policy files to be installed.<br />
: <tt>'''update_bundle_metadata'''</tt> - This is used by SEAdmin to form the intent and contains a hash of the bundle to replace or "<tt>NONE</tt>", the signature of the <tt>update_bundle</tt> and the bundle version (in this case "<tt>3</tt>"). Example contents are:<br />
<pre><br />
NONE:I6E0cZ8WbF6kJWkDozJCfckw5xuZhXuE0iqrbszsxhi7S4Z3DrR7RiH/aomRQxeskvMv9B/+G7JXfxFAQlV1CWZihnefkHGnei4atKnBLPK/g3gmf0Wb0jjizc4yb4uvu/XQAZvybKcsTvTiegfqTHMFWPGKgoq97RKAjk2kT2fa3liArylTrLl7OfRtKq6mNjQNnfVrte9e/aJptiAmOwDNdQydfRwhewrKPE6rM+YNuHJaJ+h28dNecQtCn9TabTxn8I1G+10d5/wmjjgXq6MdfEMQZ++H4ZIaL4bTdUOQVdFeMsnFLA3hjLGf3BXpHmG84s7iDO158V0kbXikzA==:3<br />
</pre><br />
<br />
Push the <tt>update_bundle</tt> to the device:<br />
<pre><br />
adb push update_bundle /data/update_bundle<br />
</pre><br />
<br />
Build an intent to broadcast via <tt>adb</tt> by including the bundle location, with the hash, signature and version from the <tt>update_bundle_metadata</tt> as follows:<br />
<pre><br />
adb shell am broadcast -a android.intent.action.UPDATE_SEPOLICY -e "CONTENT_PATH" "/data/update_bundle" -e "REQUIRED_HASH" "NONE" -e "SIGNATURE" "I6E0cZ8WbF6kJWkDozJCfckw5xuZhXuE0iqrbszsxhi7S4Z3DrR7RiH/aomRQxeskvMv9B/+G7JXfxFAQlV1CWZihnefkHGnei4atKnBLPK/g3gmf0Wb0jjizc4yb4uvu/XQAZvybKcsTvTiegfqTHMFWPGKgoq97RKAjk2kT2fa3liArylTrLl7OfRtKq6mNjQNnfVrte9e/aJptiAmOwDNdQydfRwhewrKPE6rM+YNuHJaJ+h28dNecQtCn9TabTxn8I1G+10d5/wmjjgXq6MdfEMQZ++H4ZIaL4bTdUOQVdFeMsnFLA3hjLGf3BXpHmG84s7iDO158V0kbXikzA==" -e "VERSION" "3"<br />
</pre><br />
<br />
When the intent has been broadcast there will be a response, however that does not indicate that the policy was updated, just that the intent was broadcast:<br />
<pre><br />
Broadcasting: Intent { act=android.intent.action.UPDATE_SEPOLICY (has extras) }<br />
Broadcast completed: result=0<br />
</pre><br />
<br />
<tt>logcat</tt> should show whether it was successful:<br />
<pre><br />
I/ConfigUpdateInstallReceiver( 908): Found new update, installing...<br />
I/ConfigUpdateInstallReceiver( 908): Installation successful<br />
I/SELinuxPolicyInstallReceiver( 908): Applying SELinux policy<br />
</pre><br />
If the update failed because of versioning then an error is given (however if signature incorrect fails silently).<br />
<br />
The following show various policy information after the third update:<br />
<pre><br />
adb shell ls -l /data/security/current<br />
lrwxrwxrwx system system 2014-07-19 10:41 current -> /data/security/contexts<br />
</pre><br />
<pre><br />
adb shell ls -l /data/security/contexts<br />
<br />
-rw-r--r-- system system 10512 2014-07-19 10:41 file_contexts<br />
-rw-r--r-- system system 10656 2014-07-19 09:01 file_contexts_backup<br />
-rw-r--r-- system system 4203 2014-07-19 10:41 mac_permissions.xml<br />
-rw-r--r-- system system 4203 2014-07-19 09:01 mac_permissions.xml_backup<br />
-rw-r--r-- system system 2549 2014-07-19 10:41 property_contexts<br />
-rw-r--r-- system system 2549 2014-07-19 09:01 property_contexts_backup<br />
-rw-r--r-- system system 641 2014-07-19 10:41 seapp_contexts<br />
-rw-r--r-- system system 641 2014-07-19 09:01 seapp_contexts_backup<br />
-rw-r--r-- system system 78 2014-07-19 10:41 selinux_version<br />
-rw-r--r-- system system 78 2014-07-19 09:01 selinux_version_backup<br />
-rw-r--r-- system system 115831 2014-07-19 10:41 sepolicy<br />
-rw-r--r-- system system 116438 2014-07-19 09:01 sepolicy_backup<br />
-rw-r--r-- system system 7748 2014-07-19 10:41 service_contexts<br />
-rw-r--r-- system system 7748 2014-07-19 09:01 service_contexts_backup<br />
</pre><br />
<pre><br />
adb shell ls -l /data/security<br />
<br />
drwx------ system system 2014-07-19 10:41 bundle<br />
drwx------ system system 2014-07-19 10:41 contexts<br />
lrwxrwxrwx system system 2014-07-19 10:41 current ->/data/security/contexts<br />
drwx------ system system 2014-07-19 10:37 eops<br />
</pre><br />
<pre><br />
adb shell ls -l /data/security/bundle<br />
<br />
drwx------ system system 2014-07-19 10:41 metadata<br />
-rw-r--r-- system system 191271 2014-07-19 10:41 sepolicy_bundle<br />
</pre><br />
<pre><br />
adb shell ls -l /data/security/bundle/metadata<br />
<br />
-rw-r--r-- system system 1 2014-07-19 10:41 version<br />
</pre><br />
<pre><br />
adb shell cat /data/security/bundle/metadata/version<br />
3<br />
</pre><br />
<br />
The loaded policy can be extracted from the device if required by:<br />
<pre><br />
adb pull /sys/fs/selinux/policy sepolicy-v3<br />
</pre><br />
<br />
=== buildeopbundle ===<br />
The <tt>buildeopbundle</tt> tool will produce an Android "bundle" for updating the Enterprise Operations policy within an <tt>eops_bundle.zip</tt> file suitable for installation by the SEAdmin app, although it is possible to update using an intent as described in the [[#Using an Intent Example | Using an Intent Example]] section.<br />
<br />
To be able to build the bundle an <tt>eops.xml</tt> file is required.<br />
<br />
Usage:<br />
<pre><br />
usage: buildeopbundle -k <private key.pk8> [-v <version>] [-r <previous hash>] \<br />
[-h] -- <eops.xml><br />
<br />
This script builds a eops policy bundle and supporting metadata file capable of being loaded via the ConfigUpdate mechanism. It takes a pkcs8 DER encoded RSA private key that is then used to sign the bundle. For AOSP development you'll typically want to use the key from the source tree at:<br />
build/target/product/security/testkey.pk8<br />
<br />
If building your own cert you should probably use a key size of at least 1024 or greater. The bundle requires that the eops.xml file be included and with that exact basename. The built bundle will be written to eop_bundle.zip which will include the signature metadata file of the bundle.<br />
<br />
OPTIONS:<br />
-h Show this message.<br />
-v Version of the built bundle. Defaults to 1.<br />
-r SHA-512 hash of the bundle to replace. Defaults to 'NONE'.<br />
</pre><br />
<br />
==== Eops Example ====<br />
The following is an example where a new <tt>eops.xml</tt> file has been produced, bundled, then pushed to the SD card. SEAdmin is then used to update the policy (note that SEAdmin only reads the bundle from <tt>/sdcard</tt>):<br />
<pre><br />
buildeopbundle -k $ANDROID_BUILD_TOP/build/target/product/security/testkey.pk8 -v 1 -- eops.xml<br />
<br />
adb push eops_bundle.zip /sdcard/<br />
</pre><br />
<br />
<tt>logcat</tt> should show if it was successful:<br />
<pre><br />
D/SEAdminConfigUpdateFragment( 904): android.intent.action.UPDATE_EOPS intent being broadcast. Bundle[{CONTENT_PATH=/cache/eops_bundle, SIGNATURE=qZJ8I07MHFTXaII2jhPMooRLzejArUI0qsvkteG9nzEzgzjwyh8RWUaaRil6xrQsPb5g+qWj+nfQCkH7DIEow/WF8S1sTeReS8G/z+hPQi0MHgWGKH0kCIfXn6yqqEri3+Dnolb1vHVuM7t/0mszCvtjqfq5GWbHZc1xYSgMQJXqrhfzSqa2zvO4+7zE0GszfuZXwt9QHci9C1IJ5B50URmmg4TDIuhfISWW9vYkEctwARIyCLhfYiZzIQOwzPj3oSHI1AUWMHxbbpADFzCumZ1WdfpA0txow8rDM+01qkKGtcAsNs8me2FAPz28tckQ9ea6QwAzDCSP3PzQC1Horg==, REQUIRED_HASH=NONE, VERSION=1}]<br />
I/ConfigUpdateInstallReceiver( 395): Couldn't find current metadata, assuming first update<br />
I/ConfigUpdateInstallReceiver( 395): Failed to read current content, assuming first update!<br />
I/ConfigUpdateInstallReceiver( 395): Found new update, installing...<br />
I/ConfigUpdateInstallReceiver( 395): Installation successful<br />
D/AppOps ( 381): Eops policy: system [ CAMERA]<br />
D/AppOps ( 381): Eops policy: default [ CAMERA]<br />
</pre><br />
<br />
The new file and its supporting metadata are:<br />
<pre><br />
adb shell su 0 ls -lR /data/security/eops<br />
<br />
/data/security/eops:<br />
-rw-r--r-- system system 189 2014-07-20 14:15 eops.xml<br />
drwx------ system system 2014-07-20 14:15 eops_metadata<br />
<br />
/data/security/eops/eops_metadata:<br />
-rw-r--r-- system system 1 2014-07-20 14:15 version<br />
</pre><br />
<br />
The version number after the update is:<br />
<pre><br />
adb shell su 0 cat /data/security/eops/eops_metadata/version<br />
1<br />
</pre><br />
<br />
Because the Eops policy specified an <tt>seinfo</tt> of <tt>system</tt> and the operation <tt>CAMERA</tt>, if the Camera app is now started it will load however, it will not be possible to take pictures as <tt>logcat</tt> will show:<br />
<pre><br />
D/AppOps ( 381): startOperation: reject #1 for code 26 (26) uid 10026 package com.android.camera2<br />
I/CameraService( 60): Camera 0: Access for "com.android.camera2" has been revoked<br />
</pre><br />
<br />
=== buildifwbundle ===<br />
The <tt>buildifwbundle</tt> tool will produce an Android "bundle" for updating the Intent Firewall policy within an <tt>ifw_bundle.zip</tt> file suitable for installation by the SEAdmin app, although it is possible to update using an intent as described in the [[#Using an Intent Example | Using an Intent Example]] section.<br />
<br />
To be able to build the bundle an <tt>ifw.xml</tt> file is required, although note that the Intent Firewall service will read any file so long as it has the <tt>.xml</tt> extension.<br />
<br />
Usage:<br />
<pre><br />
usage: buildifwbundle -k <private key.pk8> [-v <version>] [-r <previous hash>] \<br />
[-h] -- <ifw.xml><br />
<br />
This script builds an intent firewall policy bundle and supporting metadata file capable of being loaded via the ConfigUpdate mechanism. It takes a pkcs8 DER encoded RSA private key that is then used to sign the bundle. For AOSP development you'll typically want to use the key from the source tree at:<br />
build/target/product/security/testkey.pk8<br />
<br />
If building your own cert you should probably use a key size of at least 1024 or greater. The bundle requires that the ifw.xml file be included and with that exact basename. The built bundle will be written to ifw_bundle.zip which will include the signature metadata file of the bundle.<br />
<br />
OPTIONS:<br />
-h Show this message.<br />
-v Version of the built bundle. Defaults to 1.<br />
-r SHA-512 hash of the bundle to replace. Defaults to 'NONE'.<br />
</pre><br />
<br />
==== IFW Example ====<br />
The following is an example where a new <tt>ifw.xml</tt> file has been produced, bundled, and then pushed to the SD card. SEAdmin is then used to update the policy (note that SEAdmin only reads the bundle from <tt>/sdcard</tt>):<br />
<pre><br />
buildsifwbundle -k $ANDROID_BUILD_TOP/build/target/product/security/testkey.pk8 -v 1 -- eops.xml<br />
<br />
adb push ifw_bundle.zip /sdcard/<br />
</pre><br />
<br />
<tt>logcat</tt> should show whether it was successful:<br />
<pre><br />
D/SEAdminConfigUpdateFragment( 904): android.intent.action.UPDATE_INTENT_FIREWALL intent being broadcast. Bundle[{CONTENT_PATH=/cache/ifw_bundle, SIGNATURE=tfQONpEZbL1Y6sXj1BY98TO4izK2IyeqO9Hko5tZygE77zry98RGmU5BAAIFs21G9G7WpAcPTR7TGe4LRMpB7SKeZ1Xh+4B+U+30TnHkwXp9HRIgIJcN5Kqiyp/UPAjEJjYmBZk+yM5FLYcMCQS082wfpC9c+gRQcl6AYuSmiynvjgc1d33rtfB7Hd40LF30mBZyyiUJc5YF1ddaITBbL/CCKmFblfBqadZtmCN7xGUIJEHqWPnuEvscatkOLgZa+35ZXfl2WkD/DsGkwocXM9akjD0NJY9WZJpzwAHQPdQFXN6nthrsV8kiC7OUFvK/PKll9oetiyTSEEVH5JlMnA==, REQUIRED_HASH=NONE, VERSION=1}]<br />
I/ConfigUpdateInstallReceiver( 395): Couldn't find current metadata, assuming first update<br />
I/ConfigUpdateInstallReceiver( 395): Failed to read current content, assuming first update!<br />
I/ConfigUpdateInstallReceiver( 395): Found new update, installing...<br />
I/ConfigUpdateInstallReceiver( 395): Installation successful<br />
I/IntentFirewall( 395): Read new rules (A:0 B:0 S:1)<br />
</pre><br />
<br />
The new file and its supporting metadata are:<br />
<pre><br />
adb shell su 0 ls -lR /data/system/ifw<br />
<br />
/data/system/ifw:<br />
-rw-r--r-- system system 454 2014-07-20 13:14 ifw.xml<br />
drwx------ system system 2014-07-20 13:14 metadata<br />
<br />
/data/system/ifw/metadata:<br />
-rw-r--r-- system system 1 2014-07-20 13:14 gservices.version<br />
</pre><br />
<br />
The version number after the update is:<br />
<pre><br />
adb shell su 0 cat /data/system/ifw/metadata/gservices.version<br />
1<br />
</pre><br />
<br />
== post_process_mac_perms ==<br />
This tool will modify an existing <tt>mac_permissions.xml</tt> with additional app certs not already found in that policy. This becomes useful when a directory containing apps is searched and the certs from those apps are added to the policy not already explicitly listed.<br />
<br />
There is no make target for this tool (python script), so either move to <tt>HOST_EXECUTABLE</tt> or execute directly (e.g. <tt>$PREFIX/external/sepolicy/tools/post_process_mac_perms</tt>).<br />
<br />
Usage:<br />
<pre><br />
post_process_mac_perms [-h] -s SEINFO -d DIR -f POLICY<br />
<br />
-s SEINFO, --seinfo SEINFO seinfo tag for each generated stanza<br />
-d DIR, --dir DIR Directory to search for apks<br />
-f POLICY, --file POLICY mac_permissions.xml policy file<br />
</pre><br />
<br />
Example:<br />
<pre><br />
post_process_mac_perms -s netapps -d ./APK -f mac_permissions.xml<br />
</pre><br />
<br />
Before:<br />
<pre><br />
<?xml version="1.0" encoding="utf-8"?><br />
<policy><br />
<signer signature="- certificate here -" ><seinfo value="platform"/></signer><br />
<default><seinfo value="default"/></default><br />
</policy><br />
</pre><br />
<br />
After:<br />
<pre><br />
<?xml version="1.0" encoding="utf-8"?><br />
<policy><br />
<signer signature="- certificate here -" ><seinfo value="platform"/></signer><br />
<default><seinfo value="default"/></default><br />
<signer signature="- certificate here -"><seinfo value="netapps"/></signer><br />
</policy><br />
</pre><br />
<br />
== sepolicy_check ==<br />
A tool for auditing a <tt>sepolicy</tt> file for any allow rule that grants a given permission.<br />
<br />
Usage:<br />
<pre><br />
sepolicy-check -s <domain> -t <type> -c <class> -p <permission> <br />
-P out/target/product/<board>/root/sepolicy<br />
</pre><br />
<br />
The output will be "<tt>Match found!</tt>" or silent if not. <tt>sepolicy_check</tt> will return <tt>0</tt> for found, <tt>1</tt> for not found and <tt>-1</tt> for an error.<br />
<br />
Examples:<br />
<pre><br />
sepolicy-check -s healthd -t system_server_service \<br />
-c service_manager -p add \<br />
-P out/target/product/generic/root/sepolicy<br />
Match found!<br />
</pre><br />
<pre><br />
<tt>sepolicy-check -s su -t security_prop -c property_service \</tt><br />
-p set -P out/target/product/generic/root/sepolicy<br />
echo $?<br />
1<br />
</pre><br />
<br />
== sepolicy-analyze ==<br />
This is the text from the <tt>external/sepolicy/tools/README</tt> that describes the tool for performing various kinds of analysis on a sepolicy file. The analysis currently supported includes:<br />
<br />
=== Type Equivalence ===<br />
<pre><br />
sepolicy-analyze -e -P out/target/product/<board>/root/sepolicy<br />
</pre><br />
<br />
Display all type pairs that are "equivalent", i.e. they are identical with respect to allow rules, including indirect allow rules via attributes and default-enabled conditional rules (i.e. default boolean values yield a true conditional expression).<br />
<br />
Equivalent types are candidates for being coalesced into a single type. However, there may be legitimate reasons for them to remain separate, for example: the types may differ in a respect not included in the current analysis, such as default-disabled conditional rules, audit-related rules (<tt>auditallow</tt> or <tt>dontaudit</tt>), default type transitions, or constraints (e.g. mls), or - the current policy may be overly permissive with respect to one or the other of the types and thus the correct action may be to tighten access to one or the other rather than coalescing them together, or - the domains that would in fact have different accesses to the types may not yet be defined or may be unconfined in the policy you are analyzing.<br />
<br />
Example output:<br />
<pre><br />
sepolicy-analyze -e -P out/target/product/se4a_device/root/sepolicy<br />
<br />
Types adbd_socket and mdns_socket are equivalent.<br />
Types rild_debug_socket and init_tmpfs are equivalent.<br />
Types rild_debug_socket and qemud_tmpfs are equivalent.<br />
Types surfaceflinger_service and mediaserver_service are equivalent.<br />
Types surfaceflinger_service and inputflinger_service are equivalent.<br />
</pre><br />
<br />
=== Type Difference ===<br />
<pre><br />
sepolicy-analyze -d -P out/target/product/<board>/root/sepolicy<br />
</pre><br />
<br />
Display type pairs that differ and the first difference found between the two types. This may be used in looking for similar types that are not equivalent but may be candidates for coalescing.<br />
<br />
Example output:<br />
<pre><br />
sepolicy-analyze -d -P out/target/product/se4a_device/root/sepolicy<br />
<br />
Types adbd_socket and functionfs differ, starting with:<br />
allow adbd_socket rootfs:filesystem { associate };<br />
allow functionfs self:filesystem { associate };<br />
<br />
Types adbd_socket and hci_attach_exec differ, starting with:<br />
allow system_server adbd_socket:sock_file { ioctl read write getattr lock append open };<br />
allow debuggerd hci_attach_exec:file { ioctl read getattr lock open };<br />
<br />
Types adbd_socket and system_server differ, starting with:<br />
allow adbd_socket rootfs:filesystem { associate };<br />
allow system_server rootfs:filesystem { getattr };<br />
</pre><br />
<br />
=== Duplicate Allow Rules ===<br />
<pre><br />
sepolicy-analyze -D -P out/target/product/<board>/root/sepolicy<br />
</pre><br />
<br />
Displays duplicate allow rules, i.e. pairs of allow rules that grant the same permissions where one allow rule is written directly in terms of individual types and the other is written in terms of attributes associated with those same types. The rule with individual types is a candidate for removal. The rule with individual types may be directly represented in the source policy or may be a result of expansion of a type negation (e.g. <tt>domain -foo -bar</tt> is expanded to individual allow rules by the policy compiler). Domains with <tt>unconfineddomain</tt> will typically have such duplicate rules as a natural side effect and can be ignored.<br />
<br />
Example output:<br />
<pre><br />
sepolicy-analyze -D -P out/target/product/se4a_device/root/sepolicy<br />
<br />
Duplicate allow rule found:<br />
allow init hci_attach_exec:file { read getattr execute open };<br />
allow unconfineddomain exec_type:file { ioctl read getattr lock execute open };<br />
<br />
Duplicate allow rule found:<br />
allow ueventd device:dir { write add_name remove_name };<br />
allow ueventd dev_type:dir { ioctl read write create getattr setattr unlink link rename add_name remove_name reparent search rmdir open };<br />
</pre><br />
<br />
=== Permissive Domains ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy permissive<br />
</pre><br />
<br />
Displays domains in the policy that are permissive, i.e. avc denials are logged but not enforced for these domains. While permissive domains can be helpful during development, they should not be present in a final user build.<br />
<br />
=== Neverallow Checking ===<br />
<pre><br />
sepolicy-analyze out/target/product/<board>/root/sepolicy neverallow \<br />
[-w] [-d] [-f neverallows.conf] | [-n "neverallow string"]<br />
</pre><br />
<br />
Check whether the <tt>sepolicy</tt> file violates any of the [http://selinuxproject.org/page/AVCRules#neverallow neverallow] rules from the <tt>neverallows.conf</tt> file or a given string, which contain <tt>neverallow</tt> statements in the same format as the SELinux <tt>policy.conf</tt> file, i.e. after m4 macro expansion of the rules from a <tt>.te</tt> file. You can use an entire <tt>policy.conf</tt> file as the <tt>neverallows.conf</tt> file and <tt>sepolicy-analyze</tt> will ignore everything except for the neverallows within it. You can also specify this as a command-line string argument, which could be useful for quickly checking an individual expanded rule or group of rules. If there are no violations, <tt>sepolicy-analyze</tt> will exit successfully with no output. Otherwise, <tt>sepolicy-analyze</tt> will report all violations and exit with a non-zero exit status.<br />
<br />
The <tt>-w</tt> or <tt>--warn</tt> option may be used to warn on any types, attributes, classes, or permissions from a <tt>neverallow</tt> rule that could not be resolved within the <tt>sepolicy</tt> file. This can be normal due to differences between the policy from which the <tt>neverallow</tt> rules were taken and the policy being checked. Such values are ignored for the purposes of <tt>neverallow</tt> checking.<br />
<br />
The <tt>-d</tt> or <tt>--debug</tt> option may be used to cause <tt>sepolicy-analyze</tt> to emit the <tt>neverallow</tt> rules as it parses them. This is principally a debugging facility for the parser but could also be used to extract <tt>neverallow</tt> rules from a full <tt>policy.conf</tt> file and output them in a more easily parsed format.<br />
<br />
These <tt>neverallow</tt> rules are also used by the Andriod CTS to check for policy conformance, see <tt>cts/tools/selinux/SELinuxNeverallowTestGen.py</tt> that generates Java methods.<br />
<br />
== setool ==<br />
The <tt>setool</tt> utility is not used during the build process and is intended only to produce entries for the <tt>mac_permissions.xml</tt> file and verify a correctly formated file. It is not supplied in AOSP.<br />
<br />
Usage:<br />
<pre><br />
Usage: setool [flags] <--build keys|package OR --policy policyFile> <apk> [ <apk> ]*<br />
<br />
Tool to help build and verify MMAC install policies.<br />
<br />
--build Generate an MMAC style policy stanza with a given --seinfo string.<br />
The resulting stanza can then be used as an entry in the mac_permissions.xml file.<br />
<br />
package Policy entry that contains the package name inside the signature stanza.<br />
<br />
keys Print just a signer tag which contains the hex encoded X.509 certs of the app.<br />
<br />
--policy Determine if the apks pass the supplied policy by printing the seinfo tag<br />
that would be assigned or null otherwise.<br />
<br />
apk An apk to analyze. All supplied apks must be absolute paths or relative to<br />
--apkdir (which defaults to the current directory).<br />
<br />
Flags:<br />
--help Prints this message and exits.<br />
--apkdir Directory to search for supplied apks (default to current directory).<br />
--verbose Increase the amount of debug statements.<br />
--outfile Dump output to the given file (defaults to stdout).<br />
--seinfo Create an seinfo tag for all generated policy stanzas. This is a required flag if using the --build option.<br />
</pre><br />
<br />
The following examples show the generation and verification process:<br />
<pre><br />
setool --build package --seinfo service_app --outfile sepolicy/mac_permissions.xml RunIsolatedService.apk<br />
</pre><br />
<br />
The output will be:<br />
<pre><br />
<signer signature="- certificate will be here -"><br />
<package name="com.example.runisolatedservice"><br />
<seinfo value="service_app" /><br />
</package><br />
</signer><br />
</pre><br />
<br />
Note that for verification via <tt>setool</tt> requires the segment to be included within a correctly formatted <tt>mac_permissions.xml</tt> file (i.e. have the<tt><nowiki> <policy></nowiki></tt> <tt><nowiki></policy></nowiki></tt> tags present:<br />
<pre><br />
setool --policy sepolicy/mac_permissions.xml RunIsolatedService.apk<br />
/pre><br />
<br />
The output will then be:<br />
<pre><br />
seinfo tag service_app assigned to ./RunIsolatedService.apk<br />
</pre><br />
<br />
= uid To username Utility =<br />
This utility will take an Android <tt>uid</tt> and convert it to a <tt>username</tt>. The code is a modified version from <tt>bionic/libc/bionic/stubbs.cpp</tt> that converts an Android <tt>uid</tt> to <tt>username</tt>.<br />
<br />
To compile this utility:<br />
<pre><br />
cc -std=gnu99 uid_to_username.c -o uid_to_username -include $ANDROID_BUILD_TOP/system/core/include/private/android_filesystem_config.h<br />
</pre><br />
<br />
<pre><br />
#include <stdio.h><br />
#include <stdlib.h><br />
<br />
int main(int argc, char **argv)<br />
{<br />
uid_t uid;<br />
<br />
if (argc != 2) {<br />
printf("Converts an Android uid to username\n");<br />
printf("usage: %s uid\n\n", argv[0]);<br />
exit(1);<br />
}<br />
<br />
uid = atoi(argv[1]);<br />
uid_t appid = uid % AID_USER;<br />
uid_t userid = uid / AID_USER;<br />
<br />
if (appid >= AID_ISOLATED_START) {<br />
printf("username: u%u_i%u\n", userid, appid - AID_ISOLATED_START);<br />
} else if (userid == 0 && appid >= AID_SHARED_GID_START) {<br />
printf("username: all_a%u\n", appid - AID_SHARED_GID_START);<br />
} else if (appid < AID_APP) {<br />
for (size_t n = 0; n < android_id_count; n++) {<br />
if (android_ids[n].aid == appid) {<br />
printf("username: u%u_%s\n", userid, android_ids[n].name);<br />
printf("Note that only \"%s\" will be shown in 'ps' etc.\n", android_ids[n].name);<br />
exit(0);<br />
}<br />
}<br />
printf("Failed - invalid uid\n");<br />
} else {<br />
printf("username: u%u_a%u\n", userid, appid - AID_APP);<br />
}<br />
exit(0);<br />
}<br />
</pre><br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_SEforAndroid_1 | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[LibselinuxAPISummary | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/NB_SEforAndroid_1NB SEforAndroid 12015-03-15T14:34:27Z<p>RichardHaines: </p>
<hr />
<div>= Security Enhancements for Android =<br />
<br />
== Introduction ==<br />
This section gives an overview of the enhancements made to Android to add SELinux services to Security Enhancements for Androidâ„¢ (SE for Android). <br />
<br />
The main objective of this document is to provide a reference for the tools, commands, policy building tools and file formats of SE for Android based on the 5.1 release. The builds discussed are from AOSP master and SEAndriod master repositories (as March '15).<br />
<br />
The AOSP git repositories can be found at [https://android.googlesource.com/ https://android.googlesource.com] and the SEAndroid enhancements at [https://bitbucket.org/seandroid https://bitbucket.org/seandroid]. <br />
<br />
For up to date information on the status of SE for Android the following should be consulted: [http://seandroid.bitbucket.org/ http://seandroid.bitbucket.org/].<br />
<br />
=== Terminology ===<br />
This section describes how the terms SE for Android, AOSP and SEAndroid are used in this document.<br />
<br />
{| border="1"<br />
| '''SE for Android'''<br />
| This is the overall programme by Google to improve security on Android. For this document, it is used to describe the implementation of SELinux (MAC) and Middleware MAC (MMAC) on Android.<br />
<br />
|-<br />
| '''AOSP'''<br />
| The Android code base distributed by Google (see [http://source.android.com/source/downloading.html http://source.android.com/source/downloading.html]). Release 5.1 contains SELinux support that is described at [http://source.android.com/devices/tech/security/se-linux.html http://source.android.com/devices/tech/security/se-linux.html].<br />
<br />
AOSP contains the core SELinux MAC functionality with a run-time MMAC framework to support specific labeling of apps as described in the [[#Install/Run-time MMAC Policy | Install/Run-time MMAC Policy]] section.<br />
<br />
AOSP also contains services to allow updating of Intent Firewall policies, however currently no files are installed (although SEAndroid supplies a sample and update tools).<br />
<br />
|-<br />
| '''SEAndroid'''<br />
| The SEAndroid project enhancements are decreasing as more features move into AOSP (for example the MAC policy is now the same as AOSP). The additional SEAndroid features are:<br />
# Install time MMAC (an enhancement of the AOSP Run-time MMAC service)<br />
# Installation of Enterprise Operations (EOps) configuration files.<br />
# Sample EOps and Intent Firewall configuration files (the actual services are supplied by AOSP, replacing the SEAndroid Intent MMAC, Content Provider MMAC and Revoke Permissions services that are now obsolete). <br />
# Tools to manage bundles for policy, EOps and Intent Firewall updates.<br />
<br />
See the SE for Android project page for up-to-date details at [http://seandroid.bitbucket.org/ http://seandroid.bitbucket.org/]<br />
<br />
|}<br />
<br />
<br />
=== Useful Links ===<br />
The following link describes how to validate SELinux in Android:<br />
<br />
[http://source.android.com/devices/tech/security/se-linux.html http://source.android.com/devices/tech/security/se-linux.html]<br />
<br />
The [http://seandroid.bitbucket.org/ http://seandroid.bitbucket.org/] pages describe the current merge status with AOSP, how to obtain the code, install SEAndroid and the features that have been implemented. It also has useful reference papers with "Security Enhanced (SE) Android: Bringing Flexible MAC to Android" available at [http://www.internetsociety.org/sites/default/files/02_4.pdf http://www.internetsociety.org/sites/default/files/02_4.pdf] being a recommended read.<br />
<br />
The white paper "[http://www.samsung.com/global/business/business-images/resource/white-paper/2013/05/Samsung_KNOX_whitepaper_April2013_v1.1-0.pdf An Overview of Samsung KNOX]" also gives an overview of how SE for Android is being integrated with other security services (such as secure boot and integrity measurement) to help provide a more secure mobile platform.<br />
<br />
=== Document Sections ===<br />
The sections that follow cover:<br />
<br />
* Overview of Android package additions and updates to support MAC<br />
* Additional kernel LSM / SELinux support<br />
* Android Classes & Permissions<br />
* SELinux commands and methods<br />
* SELinux extensions for <tt>init</tt><br />
* Policy construction and build:<br />
** Build file locations<br />
** Policy files<br />
** Build tools<br />
* Logging and auditing<br />
* Android <tt>libselinux</tt> additional functions<br />
* Configuration file formats<br />
<br />
== SE for Android Project Updates ==<br />
This gives a high level view of the new and updated projects to support SE for Android services and covers AOSP with any additional SEAndroid functions noted. These are not a complete set of updates, but give some idea of the scope.<br />
<br />
: <tt>'''external/libselinux'''</tt><br />
:: Provides the SELinux userspace function library that is installed on the device. It is based on the 2.1.0 Linux version but has additional functions to support Android as summarised in the <tt>external/libselinux/README.android</tt>. Some additional detail is as follows:<br />
::: <tt>'''selinux_android_setcontext'''</tt><br />
:::: Sets the correct domain context when launching applications using <tt>'''setcon'''(3)</tt>. Information contained in the <tt>seapp_contexts</tt> file is used to compute the correct context.<br />
:::: It is called by <tt>frameworks/base/core/jni/com_android_internal_os_Zygote.cpp</tt> when forking a new process and the <tt>system/core/run-as/run-as.c</tt> utility for app debugging.<br />
::: <tt>'''selinux_android_setfilecon'''</tt><br />
:::: Sets the correct context on application directory / files using <tt>'''setfilecon'''(3)</tt>. Information contained in the <tt>seapp_contexts</tt> file is used to compute the correct context.<br />
:::: The function is used by the package installer within <tt>frameworks/native/cmds/installd/commands.c</tt> via the package <tt>install()</tt> and <tt>make_user_data()</tt> functions.<br />
::: <tt>'''selinux_android_restorecon'''</tt><br />
::: <tt>'''selinux_android_restorecon_pkgdir'''</tt><br />
:::: Basically these functions are used to label files and directories based on entries from the <tt>file_contexts</tt> and/or <tt>seapp_contexts</tt> files. They call a common handler (<tt>selinux_android_restorecon_common()</tt>) that will then relabel the requested directories and files. It will also handle recursive labeling of directories and files should a new app, <tt>file_contexts</tt> or <tt>seapp_contexts</tt> be installed (see the [[#Checking File Labels | Checking File Labels]] section for further information).<br />
:::: The <tt>'''selinux_android_restorecon'''</tt> function is used by:<br />
::::: <tt>frameworks/native/cmds/installd/installd.c</tt> when installing a new app.<br />
::::: <tt>frameworks/base/core/jni/android_os_SELinux.cpp</tt> for the Java <tt>native_restorecon</tt> method.<br />
::::: <tt>frameworks/native/cmds/dumpstate/utils.c</tt> when dumping Dalvik and stack traces to ensure correct label.<br />
:::: The <tt>'''selinux_android_restorecon_pkgdir'''</tt> function is used by:<br />
::::: <tt>frameworks/native/cmds/installd/commands.c</tt> for the package <tt>restorecon_data()</tt> and <tt>make_user_data()</tt> functions.<br />
::: <tt>'''selinux_android_seapp_context_reload'''</tt><br />
:::: Loads the <tt>seapp_contexts</tt> file for <tt>frameworks/native/cmds/installd/installd.c</tt> when the package installer is loaded.<br />
::: <tt>'''selinux_android_load_policy'''</tt><br />
:::: Mounts the SELinux filesystem if SELinux is enabled and then calls <tt>'''selinux_android_reload_policy'''</tt> to load the policy into the kernel. Used by <tt>system/core/init/init.c</tt> to initialise SELinux.<br />
::: <tt>'''selinux_android_reload_policy'''</tt><br />
:::: Reloads the policy into the kernel. Used by <tt>system/core/init/init.c</tt> <tt>selinux_reload_policy()</tt> to reload policy after setting the <tt>selinux.reload_policy</tt> property.<br />
::: <tt>'''selinux_android_use_data_policy'''</tt><br />
:::: Used by <tt>system/core/init/init.c</tt> to decide which policy directory to load the <tt>property_contexts</tt> file from.<br />
::: There is also a new labeling service for <tt>'''selabel_lookup'''(3)</tt> to query the Android <tt>property_contexts</tt> and <tt>service_contexts</tt> files.<br />
::: Various Android services will also call (not a complete list):<br />
:::: <tt>'''selinux_status_updated'''(3)</tt>, <tt>'''is_selinux_enabled'''(3)</tt>, to check whether anything changed within the SELinux environment (e.g. updated configuration files).<br />
:::: <tt>'''selinux_check_access'''(3)</tt> to check if the source context has access permission for the class on the target context.<br />
:::: <tt>'''selinux_label_open'''(3)</tt>, <tt>'''selabel_lookup'''(3)</tt>, <tt>'''selinux_android_file_context_handle'''</tt>, <tt>'''selinux_android_prop_context_handle'''</tt>, <tt>'''setfilecon'''(3)</tt>, <tt>'''setfscreatecon'''(3)</tt> to manage file labeling.<br />
:::: <tt>'''selinux_lookup_best_match'''</tt> called by<tt> system/core/init/devices.c</tt> when <tt>ueventd</tt> creates a device node as it may also create one or more symlinks (for block and PCI devices). Therefore a "best match" look-up for a device node is based on its real path, plus any links that may have been created (see commits [https://android.googlesource.com/platform/system/core/+/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a https://android.googlesource.com/platform/system/core/][https://android.googlesource.com/platform/system/core/+/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a +/b0ab94b7d5a888f0b6920b156e5c6a075fa0741a], [https://android.googlesource.com/platform/system/core/+/b4c5200f51c3568f604a4557119ab545a6ddac94 https://android.googlesource.com/platform/system/core/][https://android.googlesource.com/platform/system/core/+/b4c5200f51c3568f604a4557119ab545a6ddac94 +/b4c5200f51c3568f604a4557119ab545a6ddac94] and''' '''[https://android.googlesource.com/platform/external/libselinux/+/be7f5e8814c4954aca51d3f95455c5d9d527658c https://android.googlesource.com/platform/external/libselinux/+/be7f5e8814c4954aca51d3f95455c5d9d527658c]).<br />
<br />
: <tt>'''external/libsepol'''</tt><br />
:: Provides the policy userspace library for building policy on the host and is not available on the device. There are no specific updates to support Android except an <tt>Android.mk</tt> file.<br />
<br />
: <tt>'''external/checkpolicy'''</tt><br />
:: Provides the policy build tool. Added support for MacOS X. Not available on the device as policy rebuilds are done in the development environment.<br />
<br />
: <tt>'''external/sepolicy'''</tt><br />
:: This is a policy specifically for the core components of Android that looks much like the reference policy, but is contained in one directory that has the policy modules (<tt><nowiki>*.te</nowiki></tt> files), class / permission files etc.. The policy is built by the <tt>Android.mk</tt> file and the resulting policy is installed on the target device (as <tt>sepolicy</tt>) along with its supporting configuration files. <br />
:: Device specific policy may be defined under the device directory as discussed in the [[#Processing Device Policy | Processing Device Policy]] section. <br />
:: The policy can be updated along with its configuration files as discussed in the [[#Updating Policy | Updating Policy]] section.<br />
:: The policy files are discussed in the [[#SELinux Policy Files | SELinux Policy Files]] section and support tools in [[NB_SEforAndroid_2#Policy_Build_Tools | Policy Build Tools]].<br />
:: The Android specific object classes are described in the [[#Android Classes and Permissions | Android Classes and Permissions]] section.<br />
:: The directory also contains the MMAC configuration files.<br />
<br />
: <tt>'''packages/apps/SEAdmin'''</tt><br />
:: This is an example Android application to manage the SE for Android environment (such as loading a new policy). Only available on SEAndroid build.<br />
<br />
: <tt>'''packages/apps/Settings'''</tt><br />
:: SELinux settings for the settings manager application.<br />
<br />
: <tt>'''bionic'''</tt><br />
:: Bionic is the Android <tt>libc</tt> that is a derived from the BSD standard C library code. It contains enhancements to support security providers such as SELinux.<br />
<br />
: <tt>'''bootable/recovery'''</tt><br />
:: Changes to manage file labeling on recovery plus a recovery <tt>init.rc</tt> file in the etc directory.<br />
<br />
: <tt>'''build'''</tt><br />
:: Changes to build SE for Android and manage file labeling on images and OTA (over the air) target files.<br />
<br />
: <tt>'''frameworks/base'''</tt><br />
:: JNI - Add SELinux support functions such as <tt>isSELinuxEnabled</tt> and <tt>setFSCreateCon</tt>.<br />
:: SELinux Java class and method definitions.<br />
:: Checking Zygote connection contexts.<br />
:: Managing file permissions for the package manager and wallpaper services.<br />
:: SELinux additions to support run time MMAC and for SEAndroid the additional MMAC services.<br />
<br />
: <tt>'''system/core'''</tt><br />
:: SELinux support services for toolbox (e.g. <tt>load_policy</tt>, <tt>runcon</tt>).<br />
:: SELinux support for system initialisation (e.g. <tt>init</tt>, <tt>init.rc</tt>). <br />
:: SELinux support for auditing avc's (<tt>auditd</tt>).<br />
<br />
: <tt>'''system/extras'''</tt><br />
:: SELinux support for the <tt>ext4</tt> file system. Note that the <tt>make_ext4fs</tt> utility is used to build these file systems and relies on the <tt>file_contexts</tt> file having all the relevant entries, if not, it will be unable to set the <tt>security.selinux</tt> xattr on the inode and fail.<br />
<br />
: <tt>'''kernel'''</tt><br />
:: All Android kernels support the Linux Security Module (LSM) and SELinux services, however they are based on various versions (currently 3.4 for Goldfish used by the emulator), therefore the latest SELinux enhancements may not always be present. The [[#Kernel LSM / SELinux Support | Kernel LSM / SELinux Support]] section describes the Andriod kernel changes.<br />
<br />
: <tt>'''device'''</tt><br />
:: Build information for each device, details regarding SEAndroid supported devices can be found at: <br />
::: [http://seandroid.bitbucket.org/BuildingKernels.html#9 http://seandroid.bitbucket.org/BuildingKernels.html#9]<br />
:: Device specific policy can be added as discussed in the [[#Building the Policy | Building the Policy]] and [[#Processing Device Policy | Processing Device Policy]] sections.<br />
<br />
== Kernel LSM / SELinux Support ==<br />
The paper "Security Enhanced (SE) Android: Bringing Flexible MAC to Android" available at [http://www.internetsociety.org/sites/default/files/02_4.pdf http://www.internetsociety.org/sites/default/files/02_4.pdf] gives a good review of what did and didn't change in the kernel to support Android. This section briefly describes the only major change that was to support the Binder IPC service that consists of the following:<br />
<br />
# LSM hooks in the binder code (<tt>drivers/staging/android/binder.c</tt>) and (<tt>include/linux/security.h</tt>)<br />
# Default support for capabilities (<tt>security/capability.c</tt>) in case no other module is loaded.<br />
# Hooks in the LSM security module (<tt>security/security.c</tt>).<br />
# SELinux support for the binder object class and permissions (<tt>security/selinux/include/classmap.h</tt>) that are shown in the [[#Android Classes and Permissions | Android Classes and Permissions]] section. Support for these permission checks are added to <tt>security/selinux/hooks.c</tt>.<br />
<br />
== Android Classes and Permissions ==<br />
Additional classes have been added to Android and are listed in the following tables with descriptions of their permissions. The policy files <tt>external/sepolicy/security_classes</tt> and <tt>external/sepolicy/access_vectors</tt> contain the complete list with descriptions available at: [http://selinuxproject.org/page/NB_ObjectClassesPermissions http://selinuxproject.org/page/NB_ObjectClassesPermissions]. However, note that while the <tt>security_classes</tt> file contains many entries, not all are required for Android. <br />
<br />
{| border="1"<br />
| colspan="2" | <tt>'''binder'''</tt> class - This is a kernel object to manage the Binder IPC service.<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (4 unique permissions)<br />
<br />
|-<br />
| <tt>call</tt><br />
| Perform a binder IPC to a given target process (can A call B?).<br />
<br />
|-<br />
| <tt>impersonate</tt><br />
| Perform a binder IPC on behalf of another process (can A impersonate B on an IPC?).<br />
<br />
Not currently used in policy but kernel (<tt>selinux/hooks.c</tt>) checks permission in <tt>selinux_binder_transaction</tt> call.<br />
<br />
|-<br />
| <tt>set_context_mgr</tt><br />
| Register self as the Binder Context Manager aka <tt>servicemanager</tt> (global name service). Can A set the context manager to B, where normally A == B.<br />
<br />
See policy module <tt>servicemanager.te</tt>. <br />
<br />
|-<br />
| <tt>transfer</tt><br />
| Transfer a binder reference to another process (can A transfer a binder reference to B?).<br />
<br />
|}<br />
<br />
<br />
{| border="1"<br />
| colspan="2" | <tt>'''property_service'''</tt> class - This is a userspace object to manage the Android Property Service. <tt>See check_mac_perms()</tt> in <tt>system/core/init/property_service.c</tt><br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (1 unique permission)<br />
<br />
|-<br />
| <tt>set</tt><br />
| Set a property.<br />
<br />
|}<br />
<br />
<br />
{| border="1"<br />
| colspan="2" | <tt>'''service_manager'''</tt> class - This is a userspace object to manage Android services. See <tt>check_mac_perms()</tt> in <tt>frameworks/native/cmds/servicemanager/service_manager.c</tt><br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (3 unique permission)<br />
<br />
|-<br />
| <tt>add</tt><br />
| Add a service.<br />
<br />
|-<br />
| <tt>find</tt><br />
| Find a service.<br />
<br />
|-<br />
| <tt>list</tt><br />
| List services.<br />
<br />
|}<br />
<br />
<br />
{| border="1"<br />
| colspan="2" | <tt>'''keystore_key'''</tt> class - This is a userspace object to manage the Android keystore (see <tt>system/security/keystore/keystore.cpp</tt>).<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (16 unique permissions)<br />
<br />
|-<br />
| <tt>test</tt><br />
| Test if keystore okay.<br />
<br />
|-<br />
| <tt>get</tt><br />
| Get key.<br />
<br />
|-<br />
| <tt>insert</tt><br />
| Insert/update key.<br />
<br />
|-<br />
| <tt>delete</tt><br />
| Delete key.<br />
<br />
|-<br />
| <tt>exist</tt><br />
| Check if key exists.<br />
<br />
|-<br />
| <tt>saw</tt><br />
| Search for matching string.<br />
<br />
|-<br />
| <tt>reset</tt><br />
| Reset keystore.<br />
<br />
|-<br />
| <tt>password</tt><br />
| Generate new keystore password.<br />
<br />
|-<br />
| <tt>lock</tt><br />
| Lock keystore.<br />
<br />
|-<br />
| <tt>unlock</tt><br />
| Unlock keystore.<br />
<br />
|-<br />
| <tt>zero</tt><br />
| Check if keystore empty.<br />
<br />
|-<br />
| <tt>sign</tt><br />
| Sign data.<br />
<br />
|-<br />
| <tt>verify</tt><br />
| Verify data.<br />
<br />
|-<br />
| <tt>grant</tt><br />
| Add or remove access.<br />
<br />
|-<br />
| <tt>duplicate</tt><br />
| Duplicate the key.<br />
<br />
|-<br />
| <tt>clear_uid</tt><br />
| Clear keys for this uid.<br />
|}<br />
<br />
<br />
{| border="1"<br />
| colspan="2" | <tt>'''debuggerd'''</tt> class - This is a userspace object to allow file dumps (see <tt>system/core/debuggerd/debuggerd.cpp</tt>).<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| <tt>dump_tombstone</tt><br />
| Write tombstone file.<br />
<br />
|-<br />
| <tt>dump_backtrace</tt><br />
| Write backtrace file.<br />
<br />
|}<br />
<br />
<br />
{| border="1"<br />
| colspan="2" | <tt>'''drmservice'''</tt> class - This is a userspace object to allow finer access control of the Digital Rights Management services (see <tt>frameworks/av/drm/drmserver/DrmManagerService.cpp</tt>).<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (8 unique permissions)<br />
<br />
|-<br />
| <tt>consumeRights</tt><br />
| Consume rights for content.<br />
<br />
|-<br />
| <tt>setPlaybackStatus</tt><br />
| Set the playback state.<br />
<br />
|-<br />
| <tt>openDecryptSession</tt><br />
| Open the DRM session for the requested DRM plugin.<br />
<br />
|-<br />
| <tt>closeDecryptSession</tt><br />
| Close DRM session.<br />
<br />
|-<br />
| <tt>initializeDecrypSession</tt><br />
| Initialise the decrypt resources.<br />
<br />
|-<br />
| <tt>decrypt</tt><br />
| Decrypt data stream.<br />
<br />
|-<br />
| <tt>finalizeDecryptUnit</tt><br />
| Release DRM resources.<br />
<br />
|-<br />
| <tt>pread</tt><br />
| Read the data stream.<br />
<br />
|}<br />
<br />
<br />
== SELinux Commands ==<br />
A subset of the Linux SELinux commands have been implemented in Android and are listed in Table 1. Some are available as Toolbox commands (see <tt>system/core/toolbox</tt>) and can be run via <tt>adb shell</tt>, for example:<br />
<pre><br />
adb shell su 0 setenforce permissive<br />
</pre><br />
<br />
<br />
'''Table 1: SELinux enabled commands'''<br />
{| border="1"<br />
| '''Command'''<br />
| '''Comment'''<br />
<br />
|-<br />
| <tt>getenforce</tt><br />
| Returns the current enforcing mode.<br />
<br />
|-<br />
| <tt>setenforce</tt><br />
| Modify the SELinux enforcing mode:<br />
<br />
<tt><nowiki>setenforce [enforcing|permissive|1|0]</nowiki></tt><br />
<br />
|-<br />
| <tt>load_policy</tt><br />
| Load new policy into kernel:<br />
<br />
<tt>load_policy policy-file</tt><br />
<br />
|-<br />
| <tt>ls</tt><br />
| Supports <tt>-Z</tt> option to display security context.<br />
<br />
|-<br />
| <tt>ps</tt><br />
| Supports <tt>-Z</tt> option to display security context.<br />
<br />
|-<br />
| <tt>restorecon</tt><br />
| Restore file default security context as defined in the <tt>file_contexts</tt> or <tt>seapp_contexts</tt> files. The options are: <tt>D</tt> - data files, <tt>F</tt> - Force reset, <tt>n</tt> - do not change, <tt>R</tt>/<tt>r</tt> - Recursive change, <tt>v</tt> - Show changes.<br />
<br />
<tt><nowiki>restorecon [-DFnrRv] pathname</nowiki></tt><br />
<br />
|-<br />
| <tt>chcon</tt><br />
| Change security context of file. The options are: <tt>h</tt> - Change symlinks, <tt>R</tt> - Recurse into subdirectories, <tt>v</tt> - Verbose output.<br />
<br />
<tt><nowiki>chcon [-hRv] context file...</nowiki></tt><br />
<br />
|-<br />
| <tt>runcon</tt><br />
| Run command in specified security context:<br />
<br />
<tt>runcon context program args...</tt><br />
<br />
|-<br />
| <tt>id</tt><br />
| If SELinux is enabled then the security context is automatically displayed.<br />
<br />
|-<br />
| <tt>getsebool</tt><br />
| Deprecated as policy booleans no longer supported.<br />
<br />
Returns SELinux boolean value(s): <br />
<br />
<tt><nowiki>getsebool [-a | boolean_name]</nowiki></tt><br />
<br />
|-<br />
| <tt>setsebool</tt><br />
| Deprecated as policy booleans no longer supported.<br />
<br />
Set SELinux boolean to a value, does not set the boolean across reboots:<br />
<br />
<tt><nowiki>setsebool boolean_name [1|true|on|0|false|off]</nowiki></tt><br />
<br />
|}<br />
<br />
<br />
== SELinux Public Methods ==<br />
The public methods implemented are equivalent to <tt>libselinux</tt> functions and shown in Table 2. They have been taken from <tt>frameworks/base/core/java/android/os/SELinux.java</tt>.<br />
<br />
The SELinux class and its methods are not available in the Android SDK, however if developing SELinux enabled apps within AOSP then Reflection would be used (see the <tt>proguard.flags</tt> and <tt>Android.mk</tt> files in <tt>packages/apps/SEAdmin</tt>). <br />
<br />
<br />
'''Table 2: SELinux class public methods'''<br />
{| border="1"<br />
| <tt>'''boolean isSELinuxEnabled()'''</tt><br />
<br />
Determine whether SELinux is enabled or disabled. <br />
Return <tt>true</tt> if SELinux is enabled.<br />
<br />
|-<br />
| <tt>'''boolean isSELinuxEnforced()'''</tt><br />
<br />
Determine whether SELinux is permissive or enforcing.<br />
Returns <tt>true</tt> if SELinux is enforcing.<br />
<br />
|-<br />
| <tt>'''boolean setSELinuxEnforce(boolean value)'''</tt><br />
<br />
Set whether SELinux is in permissive or enforcing modes.<br />
<tt>value</tt> of <tt>true</tt> sets SELinux to enforcing mode.<br />
Returns <tt>true</tt> if the desired mode was set.<br />
<br />
|-<br />
| <tt>'''boolean setFSCreateContext(String context)'''</tt><br />
<br />
Sets the security context for newly created file objects.<br />
<tt>context</tt> is the security context to set.<br />
Returns <tt>true</tt> if the operation succeeded.<br />
<br />
|-<br />
| <tt>'''boolean setFileContext(String path, String context)'''</tt><br />
<br />
Change the security context of an existing file object.<br />
<tt>path</tt> represents the path of file object to relabel.<br />
<tt>context</tt> is the new security context to set .<br />
Returns <tt>true</tt> if the operation succeeded.<br />
<br />
|-<br />
| <tt>'''String getFileContext(String path)'''</tt><br />
<br />
Get the security context of a file object.<br />
<tt>path</tt> the pathname of the file object.<br />
Returns the requested security context or null.<br />
<br />
|-<br />
| <tt>'''String getPeerContext(FileDescriptor fd)'''</tt><br />
<br />
Get the security context of a peer socket.<br />
<tt>FileDescriptor</tt> is the file descriptor class of the peer socket.<br />
Returns the peer socket security context or null.<br />
<br />
|-<br />
| <tt>'''String getContext()'''</tt><br />
<br />
Gets the security context of the current process.<br />
Returns the current process security context or null.<br />
<br />
|-<br />
| <tt>'''String getPidContext(int pid)'''</tt><br />
<br />
Gets the security context of a given process id.<br />
<tt>pid</tt> an <tt>int</tt> representing the process id to check.<br />
Returns the security context of the given pid or null.<br />
<br />
|-<br />
| Deprecated as policy booleans no longer supported.<br />
<br />
<tt>'''<nowiki>String[] getBooleanNames()</nowiki>'''</tt><br />
<br />
Gets a list of the SELinux boolean names.<br />
Return an array of strings containing the SELinux boolean names.<br />
<br />
|-<br />
| Deprecated as policy booleans no longer supported.<br />
<br />
<tt>'''boolean getBooleanValue(String name)'''</tt><br />
<br />
Gets the value for the given SELinux boolean name.<br />
<tt>name</tt> is the name of the SELinux boolean.<br />
Returns true or false indicating whether the SELinux boolean is set or not.<br />
<br />
|-<br />
| Deprecated as policy booleans no longer supported.<br />
<br />
<tt>'''boolean setBooleanValue(String name, boolean value)'''</tt><br />
<br />
Sets the value for the given SELinux boolean name. Note that this will be set the boolean permanently across reboots.<br />
<tt>name</tt> is the name of the SELinux boolean.<br />
<tt>value</tt> is the new value of the SELinux boolean.<br />
Returns true if the operation succeeded.<br />
<br />
|-<br />
| <tt>'''boolean checkSELinuxAccess(String scon, String tcon, String tclass, String perm)'''</tt><br />
<br />
Check permissions between two security contexts.<br />
<tt>scon</tt> is the source or subject security context.<br />
<tt>tcon</tt> is the target or object security context.<br />
<tt>tclass</tt> is the object security class name.<br />
<tt>perm</tt> is the permission name.<br />
Returns true if permission was granted.<br />
<br />
|-<br />
| <tt>'''boolean restorecon(String pathname)'''</tt><br />
<br />
Restores a file to its default SELinux security context. If the system is not compiled with SELinux, then true is automatically returned. If SELinux is compiled in, but disabled, then true is returned.<br />
<tt>pathname</tt> is the pathname of the file to be relabeled.<br />
Returns true if the relabeling succeeded.<br />
<tt>exception NullPointerException</tt> if the pathname is a null object.<br />
<br />
|-<br />
| <tt>'''boolean restorecon(File file)'''</tt><br />
<br />
Restores a file to its default SELinux security context. If the system is not compiled with SELinux, then true is automatically returned. If SELinux is compiled in, but disabled, then true is returned.<br />
<tt>file</tt> is the file object representing the path to be relabeled. <br />
Returns true if the relabeling succeeded.<br />
<tt>exception NullPointerException</tt> if the file is a null object.<br />
<br />
|-<br />
| <tt>'''boolean restoreconRecursive(File file)'''</tt><br />
<br />
Recursively restores all files under the given path to their default SELinux security context. If the system is not compiled with SELinux, then true is automatically returned. If SELinux is compiled in, but disabled, then true is returned.<br />
<tt>pathname</tt> is the pathname of the file to be relabeled.<br />
Returns a boolean indicating whether the relabeling succeeded.<br />
<br />
|}<br />
<br />
<br />
== Android Init Language SELinux Extensions ==<br />
The Android init process language has been expanded to support SELinux as shown in Table 3. The complete Android <tt>init</tt> language description is available in the <tt>system/core/init/readme.txt</tt> file.<br />
<br />
'''Table 3: SELinux init extensions'''<br />
{| border="1"<br />
| <tt>'''<nowiki>seclabel <securitycontext></nowiki>'''</tt><br />
<br />
: <tt>service option</tt>: Change to security context before exec'ing this service. Primarily for use by services run from the rootfs, e.g. <tt>ueventd</tt>, <tt>adbd</tt>. Services on the system partition can instead use policy defined transitions based on their file security context. If not specified and no transition is defined in policy, defaults to the init context.<br />
<br />
|-<br />
| <tt>'''<nowiki>restorecon <path></nowiki>'''</tt><br />
<br />
: <tt>action command</tt>: Restore the file named by <tt><nowiki><path></nowiki></tt> to the security context specified in the <tt>file_contexts</tt> configuration. Not required for directories created by the <tt>init.rc</tt> as these are automatically labeled correctly by init.<br />
<br />
|-<br />
| <tt>'''<nowiki>restorecon_recursive <path> [ <path> ]*</nowiki>'''</tt><br />
<br />
: <tt>action command</tt>: Recursively restore the directory tree named by <tt><nowiki><path></nowiki></tt> to the security context specified in the <tt>file_contexts</tt> configuration. Do NOT use this with paths leading to shell-writable or app-writable directories, e.g. /data/local/tmp, /data/data or any prefix thereof.<br />
: See the [[#Checking File Labels|Checking File Labels]] section for further details.<br />
<br />
|-<br />
| <tt>'''<nowiki>setcon <securitycontext></nowiki>'''</tt><br />
<br />
: <tt>action command</tt>: Set the current process security context to the specified string. This is typically only used from <tt>early-init</tt> to set the init context before any other process is started (see <tt>init.rc</tt> example above).<br />
<br />
|-<br />
| <tt>'''<nowiki>setenforce 0|1</nowiki>'''</tt><br />
<br />
: <tt>action command</tt>: Set the SELinux system-wide enforcing status. 0 is permissive (i.e. log but do not deny), 1 is enforcing.<br />
<br />
|-<br />
| <tt>'''<nowiki>setsebool <name> <value></nowiki>'''</tt><br />
<br />
: Deprecated as booleans no longer supported.<br />
: <tt>action command</tt>: Set SELinux boolean <tt><nowiki><name></nowiki></tt> to <tt><nowiki><value></nowiki></tt>. <br />
: <tt><nowiki><value></nowiki></tt> may be <tt>1|true|on</tt> or <tt>0|false|off</tt><br />
<br />
|}<br />
<br />
<br />
Examples of their usage are shown in the following <tt>init.rc</tt> file segments:<br />
<pre><br />
system/core/rootdir/init.rc<br />
...<br />
<br />
on early-init<br />
...<br />
<br />
# Set the security context for the init process.<br />
# This should occur before anything else (e.g. ueventd) is started.<br />
setcon u:r:init:s0<br />
<br />
# Set the security context of /adb_keys if present.<br />
restorecon /adb_keys<br />
<br />
start ueventd<br />
...<br />
<br />
on post-fs-data<br />
...<br />
# Reload policy from /data/security if present.<br />
setprop selinux.reload_policy 1<br />
<br />
# Set SELinux security contexts on upgrade or policy update.</nowiki><br />
restorecon_recursive /data<br />
...<br />
service ueventd /sbin/ueventd<br />
class core<br />
critical<br />
seclabel u:r:ueventd:s0<br />
</pre><br />
<br />
<br />
== Device Policy File Locations ==<br />
Table 4 shows the Android policy files with their default location when the device is built, and their alternate locations when devices are updated by other methods (such as OTA or via <tt>adb</tt>). The alternate locations are always checked first as if present they override the default location as discussed in the comments section of Table 4.<br />
<br />
The <tt>init</tt> process will initially load the SELinux set of policy files from root (<tt>/</tt>). Once the <tt>/data</tt> partition setup has been completed (see <tt>init.rc</tt>) a policy reload is performed. This will check whether there is a valid policy at <tt>/data/security/current</tt> and load that if valid. <br />
<br />
If safe mode, then only the root policy files will be loaded. A factory reset will wipe <tt>/data</tt> and will therefore revert to the original root policy files.<br />
<br />
'''Table 4: Policy file locations'''<br />
{| border="1"<br />
| <center>'''Default Location'''</center><br />
| <center>'''Alternate Location'''</center><br />
| <center>'''Comments'''</center><br />
<br />
|-<br />
| <tt>/sepolicy</tt><br />
<tt>/file_contexts</tt><br />
<tt>/seapp_contexts</tt><br />
<tt>/property_contexts</tt><br />
<tt>/service_contexts</tt><br />
<tt>/selinux_version</tt><br />
<tt>/mac_permissions.xml</tt><br />
<br />
| <tt>/data/security/current</tt><br />
| Any or all these files may be in the alternate directory as each conponent that requires them will look in the alternate first and then the default, however:<br />
# During a policy reload, if there is an <tt>selinux_version</tt> file in the alternate location, then the default location will be over-ridden. If the policy has been updated via the <tt>buildsebundle</tt> / SEAdmin app process then this would be the case.<br />
# The alternate directory may be a symbolic link to another directory. For example the <tt>buildsebundle</tt> / SEAdmin app process adds a link to <tt>/data/security/context</tt> that holds the policy files<br />
# If the policy has been updated via the <tt>buildsebundle</tt> / SEAdmin app process, then the following will also be present:<br />
<br />
::: <tt>/data/security/bundle</tt> will contain the <tt>sepolicy_bundle</tt> (the packed files) and a <tt>metadata</tt> directory containing a <tt>version</tt> file holding the last version number.<br />
::: There will be <tt><nowiki>*_backup</nowiki></tt> policy files of the previous version that could be restored if required.<br />
<br />
See the [[NB_SEforAndroid_2#buildsebundle|Build Bundle Tools - ]][[NB_SEforAndroid_2#buildsebundle|buildsebundle]] section for a worked example.<br />
<br />
|-<br />
| <tt>/system/etc/security/eops.xml</tt><br />
| <tt>/data/security/eops</tt><br />
| If the policy has been updated via the <tt>buildeopbundle</tt> / SEAdmin app process, then the following will also be present in the alternative location: <br />
<br />
* <tt>/data/security/eops/eops_metadata/version</tt> file holding the last version number.<br />
<br />
See the [[NB_SEforAndroid_2#buildeopbundle|Build Bundle Tools - ]][[NB_SEforAndroid_2#buildeopbundle|buildeopbundle]] section for a worked example.<br />
<br />
|-<br />
| <tt>/data/system/ifw/ifw.xml</tt><br />
| <tt>/data/secure/system/ifw</tt><br />
<br />
(default for encrypted systems)<br />
| This file is not installed by default and note that the Intent Firewall service will read any file from <tt>/data/system/ifw/</tt> so long as it has an <tt>.xml</tt> extension.<br />
<br />
If required would be built and delivered by the <tt>buildifwbundle</tt> / SEAdmin app process, with the following also present in the default location:<br />
<br />
* <tt>/data/system/ifw/metadata/gservices.version</tt> file holding the last version number.<br />
<br />
See the [[NB_SEforAndroid_2#buildifwbundle|Build Bundle Tools - ]][[NB_SEforAndroid_2#buildifwbundle|buildifwbundle]] section for a worked example.<br />
<br />
|-<br />
| <tt>/system/etc/sepolicy.recovery</tt><br />
| none<br />
| Only used for recovery.<br />
<br />
|}<br />
<br />
<br />
== Building the Policy ==<br />
This section covers building of SELinux MAC and Install-time MMAC policies. The file formats of Android specific configuration files are detailed in [[NB_SEforAndroid_2#Policy Configuration File Formats | Policy Configuration File Formats]] with examples.<br />
<br />
=== SELinux Policy Files ===<br />
The core policy files are contained in <tt>external/sepolicy</tt>, with device specific policy in <tt><nowiki>device/<vendor>/<device>/sepolicy</nowiki><ref name="ftn1">Except for the emulator device policy that is in <tt>build/target/board/generic/sepolicy</tt>.</ref> (see the [[#Processing Device Policy | Processing Device Policy]] section). Once generated, the policy and its supporting configuration files will be installed on the device as part of the build process.<br />
<br />
==== Core Policy Files ====<br />
The following files (along with any device specific policy) are used to build the kernel binary policy file named <tt>sepolicy</tt> and installed by default in the root directory.<br />
<br />
: <tt>'''access_vectors'''</tt><br />
: <tt>'''security_classes'''</tt><br />
:: These have been modified to support the new Android classes and permissions (although they still contain the unused Linux userspace items).<br />
<br />
: <tt>'''initial_sids'''</tt><br />
: <tt>'''initial_sids_contexts'''</tt><br />
:: Contains the system initialisation (before policy is loaded) and failsafe (for objects that would not otherwise have a valid label).<br />
<br />
: <tt>'''fs_use'''<br />
: '''genfs_contexts'''<br />
: '''port_contexts'''</tt><br />
:: For flexibility of policy building, these files have been separated to allow additional policy files to be defined for specific devices as discussed below. <br />
<br />
: <tt>'''users'''<br />
: '''roles'''</tt><br />
:: These define the only user (<tt>u</tt>) and role (<tt>r</tt>) used by the policy.<br />
<br />
: <tt>'''mls'''</tt><br />
:: Contains the constraints to be applied to the defined classes and permissions.<br />
<br />
: <tt>'''global_macros'''<br />
: '''mls_macro'''<br />
: '''te_marcos'''</tt><br />
:: These contain the m4 macros that expand the policy files to build a policy in the kernel policy language as described in [http://selinuxproject.org/page/PolicyLanguage http://selinuxproject.org/page/PolicyLanguage]. The policy will then be compiled by <tt>'''checkpolicy'''(8)</tt>.<br />
<br />
: <tt>'''attributes'''</tt><br />
:: Contains the attribute names (forming the [http://selinuxproject.org/page/TypeStatements#attribute_Statement attribute] statements) that will be used to group [http://selinuxproject.org/page/TypeStatements#type_Statement type] identifiers defined by the policy.<br />
<br />
: <tt>'''policy_capabilities'''</tt><br />
:: Contains the policy capabilities enabled for the kernel policy (see [http://selinuxproject.org/page/Policy_Configuration_Statements policycap] statement).<br />
<br />
: <tt>'''<nowiki>*.te</nowiki>'''</tt><br />
:: The <tt><nowiki>*.te</nowiki></tt> files are the core policy module definition files. These are the same format as the standard reference policy and are expanded by the m4 macros. There is (generally) one <tt>.te</tt> file for each domain/service defined containing the policy rules.<br />
<br />
==== Policy Configuration Files ====<br />
These files (along with any device specific files) will be installed on the device and used to compute security contexts (see the [[#Checking File Labels | Checking File Labels]] section for further information).<br />
<br />
: <tt>'''file_contexts'''</tt><br />
:: Contains default file contexts for setting the SELinux extended file attributes (<tt>'''attr'''(1)</tt>). The format of this file is defined in the [[NB_SEforAndroid_2#file_contexts | file_contexts]] section. The file is installed by default in the root directory.<tt> </tt>Android services (such as [[#SELinux Commands | restorecon]]) will first check for this file at:<br />
::: <tt>/data/security/current/file_contexts</tt> <br />
:: If not present then check root directory:<br />
::: <tt>/file_contexts</tt><br />
<br />
: <tt>'''seapp_contexts'''</tt><br />
:: Contains information to allow domain or data file contexts to be computed based on parameters as discussed in the [[NB_SEforAndroid_2#seapp_contexts | seapp_contexts]] section. The file is installed by default in the root directory. The Android initialisation / reload process will first check for this file at:<br />
::: <tt>/data/security/current/seapp_contexts</tt><br />
:: If not present then check root directory:<br />
::: <tt>/seapp_contexts</tt><br />
<br />
: <tt>'''property_contexts'''</tt><br />
:: Contains default contexts for Android property services as discussed in the [[NB_SEforAndroid_2#property_contexts | property_contexts]] section. The file is installed by default in the root directory. The Android initialisation / reload process will first check for this file at:<br />
::: <tt>/data/security/property_contexts</tt><br />
:: If not present then check root directory:<br />
::: <tt>/property_contexts</tt><br />
<br />
: <tt>'''service_contexts'''</tt><br />
:: Contains default contexts for Android services as discussed in the [[NB_SEforAndroid_2#service_contexts | service_contexts]] section. The file is installed by default in the root directory. The Android initialisation / reload process will first check for this file at:<br />
::: <tt>/data/security/service_contexts</tt><br />
:: If not present then check root directory:<br />
::: <tt>/service_contexts</tt><br />
<br />
The following files will be built as part of the build process and installed on the device:<br />
<br />
: <tt>'''sepolicy'''</tt><br />
:: The kernel binary policy. The Android initialisation / reload process will first check for this file at:<br />
::: <tt>/data/security/current/sepolicy</tt><br />
:: If not present then check root directory:<br />
::: <tt>/sepolicy</tt><br />
:: For reference, the policy text file containing the [http://selinuxproject.org/page/PolicyLanguage#Kernel_Policy_Language_Definition_Links kernel policy language statements] is available at:<br />
::: <tt><nowiki>out/target/product/<device>/obj/ETC/sepolicy_intermediates/policy.conf</nowiki></tt><br />
:: The compiled kernel policy (<tt>sepolicy</tt>) is also in this directory along with <tt>policy.conf.dontaudit</tt> and <tt>sepolicy.dontaudit</tt> files that have the <tt>dontaudit</tt> rules removed.<br />
<br />
: <tt>'''sepolicy.recovery'''</tt><br />
:: A recovery policy is installed at <tt>system/etc/sepolicy.recovery</tt>. It is build with the macro<tt> target_recovery = true</tt> that will add additional rules defined in the <tt>recovery.te</tt> module (see <tt>Android.mk</tt> and <tt>te_macros</tt>). For reference the recovery policy text file is available at:<br />
:: <tt><nowiki>out/target/product/<device>/obj/ETC/sepolicy.recovery_intermediates/policy_recovery.conf</nowiki></tt><br />
<br />
: <tt>'''selinux_version'''</tt><br />
:: The <tt>selinux_version</tt> file is generated containing the <tt>BUILD_FINGERPRINT</tt> that the policy was built against. Its existence is used at boot time, policy upgrades or reloads to determine whether the policy configuration files should be read from <tt>/data/security/current</tt> or root (<tt>/</tt>). The <tt>mac_permissions.xml</tt> would also be read from either <tt>/data/security/current</tt> or <tt>/system/etc/security</tt>).<br />
<br />
=== Install/Run-time MMAC Policy ===<br />
The Install/Run-time MMAC is part of AOSP (Run-time only currently) and SEAndroid (Install and Run time) policy build that is always enabled.<br />
<br />
The file that configures this policy is <tt>mac_permissions.xml</tt> that assigns an <tt>seinfo</tt> tag to apps based on their signature and optionally their package name. The <tt>seinfo</tt> tag can then be used as a key in the <tt>seapp_contexts</tt> file to assign a specific label to all apps with that <tt>seinfo</tt> tag. The configuration file is read by <tt>system_server</tt> during start-up. Its format is discussed in the [[NB_SEforAndroid_2#mac_permissions.xml | mac_permissions.xml]] section.<br />
<br />
Note that AOSP and SEAndroid builds only differ in that SEAndroid will not install or load an app if there is no matching entry in the <tt>mac_permissions.xml</tt> file when no <tt><nowiki><default></nowiki></tt> entry is present.<br />
<br />
The file is installed by default at:<br />
:: <tt>/system/etc/security/mac_permissions.xml</tt><br />
<br />
The Android initialisation / reload process will first check for this file at:<br />
:: <tt>/data/security/current/mac_permissions.xml</tt><br />
<br />
This file can be:<br />
# Appended to by the <tt>BOARD_SEPOLICY_UNION</tt> variable as described in the [[#Processing Device Policy | Processing Device Policy]] section.<br />
# Updated along with all other MAC policy files as described in the [[#Updating Policy | Updating Policy]] section.<br />
<br />
The main code for the service is <tt>frameworks/base/services/java/com/android/server/pm/SELinuxMMAC.java</tt>, however it does hook into other Android services such as <tt>PackageManagerService.java</tt>.<br />
<br />
=== Device Specific Policy ===<br />
Some of this section has been extracted from the <tt>external/sepolicy/README</tt> that should be checked in case there have been updates. It describes how files in <tt>external/sepolicy</tt> can be manipulated during the build process to reflect requirements of different device vendors whose policy files would normally be located in the <tt><nowiki>device/<vendor>/<device>/sepolicy</nowiki></tt> directory.<br />
<br />
Important Note: Android policy has a number of [http://selinuxproject.org/page/AVCRules neverallow] rules defined in the core policy to ensure that [http://selinuxproject.org/page/AVCRules allow] rules are never added to domains that would weaken security. However developers may need to customise their device policies, and as a consequence they may fail one or more of these rules. If so, then this thread may be useful:<br />
:: [http://marc.info/?l=seandroid-list&m=141116103611797&w=2 http://marc.info/?l=seandroid-list&m=141116103611797&w=2]<br />
<br />
==== Managing Device Policy Files ====<br />
Additional per device policy files are manipulated by the policy build process using the following two variables that may be added to the device <tt>BoardConfig.mk</tt> file:<br />
<br />
: <tt>'''BOARD_SEPOLICY_DIRS'''</tt><br />
:: Contains a list of directories to search for files listed by the <tt>BOARD_SEPOLICY_UNION</tt> variable. Order matters in this list. e.g. If the following is defined:<br />
::: <tt>BOARD_SEPOLICY_UNION := widget.te</tt><br />
:: and there are two instances of <tt>widget.te</tt> files on the <tt>BOARD_SEPOLICY_DIRS</tt> search path, the first one found (at the first search directory containing the file) gets processed first. Reviewing the devices <tt>policy.conf<ref name="ftn2">The <tt>policy.conf</tt> file contains the policy language statements as described at [http://selinuxproject.org/page/PolicyLanguage http://selinuxproject.org/page/PolicyLanguage]. These define the policy that will be enforced.</ref> will help sort out ordering issues and is located at:<br />
::: <tt><nowiki>out/target/product/<device>/obj/ETC/sepolicy_intermediates/policy.conf</nowiki></tt><br />
<br />
: <tt>'''BOARD_SEPOLICY_UNION'''</tt><br />
:: Contains a list of files that will be "unioned", i.e. concatenated at the END of their respective files in <tt>external/sepolicy</tt><br />
:: To add a unique/new file this variable would be used.<br />
:: It is an error to specify a <tt>BOARD_POLICY_UNION</tt> file that does not exist in <tt>external/sepolicy</tt>.<br />
<br />
'''Examples:'''<br />
<br />
The example <tt>BoardConfig.mk</tt> entries showing the use of <tt>BOARD_SEPOLICY_UNION</tt> that will take files referenced in <tt>BOARD_SEPOLICY_DIRS</tt> and add their contents to the end of the respective files in <tt>external/sepolicy</tt>, it will also include those not in <tt>external/sepolicy</tt>.<br />
<br />
Example:<br />
<pre><br />
BOARD_SEPOLICY_DIRS := device/samsung/tuna/sepolicy<br />
<br />
BOARD_SEPOLICY_UNION := \<br />
genfs_contexts \<br />
file_contexts \<br />
sepolicy.te<br />
</pre><br />
<br />
=== Build Tools ===<br />
The kernel policy is compiled using <tt>'''checkpolicy'''(8)</tt> via the <tt>external/sepolicy/Android.mk</tt> file. There are also a number of Android specific tools used to assist in policy configuration that are described in [[NB_SEforAndroid_2#Policy Build Tools|Policy Build Tools]], with a summary as follows:<br />
: <tt>'''checkfc'''</tt> - Used to parse the <tt>file_contexts</tt> file against the binary policy <tt>sepolicy</tt>. This is to ensure all file contexts are valid for the policy. There is a <tt>-p</tt> option that is used to validate the contexts defined in the <tt>property_contexts</tt> or <tt>service_contexts</tt> file.<br />
: <tt>'''checkseapp'''</tt> - Used to validate the <tt>seapp_contexts</tt> file entries against the binary policy <tt>sepolicy</tt>. <br />
: <tt>'''insertkeys.py'''</tt> - Used to replace keywords in the <tt>signature</tt> sections of the <tt>mac_permissions.xml</tt> file with information obtained from <tt>pem</tt> files. This uses information contained in the <tt>external/sepolicy/keys.conf</tt> file that is detailed in the [[NB_SEforAndroid_2#insertkeys.py |insertkeys.py]] tools section.<br />
:: Note that the tools listed below are not built as part of the standard build process, therefore use <tt><nowiki>make <tool_name></nowiki></tt> except where indicated.<br />
: <tt>'''post_process_mac_perms'''</tt> - Assists in generating new entries in an existing <tt>mac_permissions.xml</tt> file (also see <tt>setool</tt>). There is no make target for this python script, so either move to <tt>HOST_EXECUTABLE</tt> or execute directly (e.g. <tt>$PREFIX/external/sepolicy/tools/post_process_mac_perms</tt>).<br />
: <tt>'''sepolicy-analyze'''</tt> - Used to analyze the kernel policy file (<tt>sepolicy</tt>) for equivalent or different type pairs, or duplicate allow rules.<br />
: <tt>'''sepolicy-check'''</tt> - Used to check the kernel policy file (<tt>sepolicy</tt>) for allow rules based on source / target types, class and a single permission. <br />
: <tt>'''<nowiki>build<???>bundle</nowiki>'''</tt> - Used to build bundles for <tt>sepolicy</tt> et al., <tt>eop.xml</tt> or <tt>ifw.xml</tt> files to handle policy updates. Not available on AOSP.<br />
: <tt>'''setool'''</tt> - Assists in generating new entries for the <tt>mac_permissions.xml</tt> file. It will extract certificates from one or more packages then generate the package sections. Its output may need to be modified before inclusion in the master file as detailed in the [[NB_SEforAndroid_2#setool | setool]] tools section. Not available on AOSP.<br />
<br />
=== Miscellaneous Information ===<br />
==== SELinux Policy Versions ====<br />
The default SELinux policy version is 26 that requires a kernel >= 3.0 and is set in <tt>external/sepolicy/Android.mk</tt> as follows:<br />
: <tt>POLICYVERS ?= 26</tt><br />
<br />
If an older kernel must be supported <tt>POLICYVERS</tt> can be set as an environment variable as follows:<br />
: <tt>export POLICYVERS=24</tt><br />
<br />
Information regarding policy versions can be found at [http://selinuxproject.org/page/NB_PolicyType#Policy_Versions http://selinuxproject.org/page/NB_PolicyType#Policy_Versions] that also gives information on the kernel versions required.<br />
<br />
==== SELinux Policy Booleans ====<br />
AOSP does not allow the use of booleans and the Android Compatibility Test Suite will specifically check and fail if they are present in a policy.<br />
<br />
==== Setting Permissive / Enforcing Mode ====<br />
Since version 4.4 Android is always started in enforcing mode, although some domains may be running in 'per-domain' permissive mode due to the [[PolicyStatements#permissive_Statement | permissive]] being present in the policy. These are ways to set permissive or enforcing mode:<br />
<br />
: Using adb to run the setenforce command:<br />
<pre><br />
# enforcing = 1 permissive = 0<br />
<br />
adb shell su 0 setenforce 1<br />
</pre><br />
<br />
: If running the emulator:<br />
<pre><br />
emulator -selinux permissive<br />
</pre><br />
<br />
==== Checking File Labels ====<br />
Checks on file labels take place at boot time, policy upgrades / reloads, app installation / upgrade, and via <tt>adb</tt> using <tt>restorecon</tt>. Depending on whether data, app or system areas are being labeled by the various <tt>restorecon</tt> services, there are two files involved:<br />
# <tt>file_contexts</tt> for all areas other than <tt>/data/data</tt> and <tt>/data/user</tt>.<br />
# <tt>seapp_contexts</tt> file for <tt>/data/data</tt> and <tt>/data/user</tt> directories.<br />
<br />
Their use and format are described in the [[NB_SEforAndroid_2#file_contexts | file_contexts]] and [[NB_SEforAndroid_2#seapp_contexts | seapp_contexts]] sections.<br />
<br />
To determine whether either of these two files have changed:<br />
# The <tt>file_contexts</tt> file has an SHA hash taken when loaded. This will be used when a recursive <tt>restorecon</tt> request is made and will be written to the pathname inode <tt>xattr</tt> entry of "<tt>security.resorecon_last</tt>" as files are labeled (except <tt>/sys</tt> files). When <tt>restorecon</tt> is run again (policy reload/update etc.), the <tt>xattr</tt> hash will be compared to the loaded <tt>file_contexts</tt> file hash, thus allowing automatic relabeling should the file change.<br />
# The s<tt>eapp_contexts</tt> file has an SHA hash taken when loaded and stored as <tt>/data/system/seapp_hash</tt> by <tt>SELinuxMMAC.java</tt>. This is used to determine whether a recursive <tt>restorecon</tt> should be carried out on the <tt>/data/data</tt> and <tt>data/user</tt> directories by the package manager.<br />
<br />
== Updating Policy Files ==<br />
This is covered at [http://seandroid.bitbucket.org/PolicyUpdates.html http://seandroid.bitbucket.org/PolicyUpdates.html] in some detail and there are worked examples in the following sections:<br />
<br />
* [[NB_SEforAndroid_2#buildsebundle|Build Bundle Tools - ]][[NB_SEforAndroid_2#buildsebundle|buildsebundle]] - This includes using an intent to update policy.<br />
* [[NB_SEforAndroid_2#buildeopbundle|Build Bundle Tools - ]][[NB_SEforAndroid_2#buildeopbundle|buildeopbundle]]<br />
* [[NB_SEforAndroid_2#buildifwbundle|Build Bundle Tools - ]][[NB_SEforAndroid_2#buildifwbundle|buildifwbundle]]<br />
<br />
There are also details in the [[#Device Policy File Locations | Device Policy File Locations]] section.<br />
<br />
The Android services that manage the updates are contained in the following java source files within the <tt>frameworks/base/services/java/com/android/server/updates</tt> directory:<br />
* <tt>SELinuxPolicyInstallReceiver.java</tt> <br />
* <tt>IntentFirewallInstallReceiver.java</tt> <br />
* <tt>EopsInstallReceiver.java</tt> <br />
<br />
==== Local Policy Update ====<br />
An example of loading a different policy via <tt>adb</tt> is described at [http://seandroid.bitbucket.org/AddressingHiddenDenials.html#13 http://seandroid.bitbucket.org/AddressingHiddenDenials.html#13], however this is an alternate method:<br />
<br />
* Modify the required policy source files including the relevant device policy modules. Rebuild the kernel policy file by:<br />
<pre><br />
make sepolicy<br />
</pre><br />
<br />
* Copy the policy file to the device (it copies the new policy to the alternate directory so that it is picked up by the reload property):<br />
<pre><br />
adb push out/target/product/<device>/root/sepolicy /data/security/current<br />
</pre><br />
<br />
* Then load the new policy by:<br />
<pre><br />
adb shell su 0 setprop selinux.reload_policy 1<br />
</pre><br />
<br />
== Logging and Auditing ==<br />
Android now supports auditing of SELinux events via the AOSP logger service that can be viewed using <tt>logcat</tt>, for example:<br />
<pre><br />
adb logcat > logcat.log<br />
</pre><br />
<br />
Example SELinux audit events (avc denials) are:<br />
<pre><br />
W/iptables( 92): type=1400 audit(0.0:18): avc: denied { relabelto } for scontext=u:r:init:s0 tcontext=u:object_r:net_apps_packet:s0 tclass=packet<br />
W/iptables( 92): type=1300 audit(0.0:18): arch=40000028 syscall=294 per=800000 success=no exit=-13 a0=4 a1=0 a2=40 a3=b845a468 items=0 ppid=54 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 exe="/system/bin/iptables" subj=u:r:init:s0 key=(null)<br />
...<br />
...<br />
W/com.se4android.netclient( 3168): type=1400 audit(0.0:200): avc: denied { send } for comm=4173796E635461736B202331 saddr=10.0.2.15 src=43397 daddr=10.0.2.15 dest=9999 netif=lo scontext=u:r:netclient_app:s0:c15,c256 tcontext=u:object_r:unlabeled:s0 tclass=packet<br />
W/com.se4android.netclient( 3168): type=1300 audit(0.0:200): arch=40000028 syscall=283 per=800000 success=no exit=-111 a0=14 a1=abf4e6c4 a2=1c a3=b6f98e98 items=0 ppid=66 auid=4294967295 uid=10015 gid=10015 euid=10015 suid=10015 fsuid=10015 egid=10015 sgid=10015 fsgid=10015 tty=(none) ses=4294967295 comm=4173796E635461736B202331 exe="/system/bin/app_process32" subj=u:r:netclient_app:s0:c15,c256 key=(null)<br />
</pre><br />
<br />
The <tt>'''audit2allow'''(1)</tt> command can be used to create policy rules as follows:<br />
<pre><br />
audit2allow -p out/target/product/<device>/root/sepolicy < logcat.log > policy.te<br />
</pre><br />
<br />
Note that before the auditing daemon is loaded, messages will be logged in the kernel buffers that can be read using <tt>'''dmesg'''(1)</tt>:<br />
<pre><br />
adb shell su 0 dmesg<br />
</pre><br />
<br />
<br />
= Policy Configuration File Formats =<br />
These are detailed in the following section:<br />
* [[NB_SEforAndroid_2 | Policy Configuration File Formats]]<br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_Imp_SELinux-aware_Apps | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_SEforAndroid_2 | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/Category:NotebookCategory:Notebook2015-02-03T15:48:56Z<p>RichardHaines: /* Notebook Sections */</p>
<hr />
<div>= The SELinux Notebook - 4th Edition =<br />
== Introduction ==<br />
This Notebook should help with explaining:<br />
<br />
# SELinux and its purpose in life.<br />
# The LSM / SELinux architecture, its supporting services and how they are implemented within GNU / Linux.<br />
# SELinux Networking, Virtual Machine, X-Windows, PostgreSQL and Apache/SELinux-Plus SELinux-aware capabilities.<br />
# The core SELinux kernel policy language and how basic policy modules can be constructed for instructional purposes. <br />
# An introduction to the new Common Intermediate Language (CIL) implementation.<br />
# The core SELinux policy management tools with examples of usage.<br />
# The Reference Policy architecture, its supporting services and how it is implemented.<br />
# The integration of SELinux within Android - SE for Android.<br />
<br />
Note that this Notebook will not explain how the SELinux implementations are managed for each GNU / Linux distribution as they have their own supporting documentation.<br />
<br />
While the majority of this Notebook is based on Fedora 20, all additional developments as seen on the SELinux mail list ([mailto:selinux@tycho.nsa.gov selinux@tycho.nsa.gov]) up to September '14 have been added.<br />
<br />
== Notebook Overview ==<br />
The book and source tarball are available from: from [http://freecomputerbooks.com/The-SELinux-Notebook-The-Foundations.html http://freecomputerbooks.com/The-SELinux-Notebook-The-Foundations.html] and has the following major sections:<br />
: '''SELinux Overview''' - Gives a description of SELinux and its major components to provide Mandatory Access Control services for GNU / Linux. Hopefully it will show how all the SELinux components link together and how SELinux-aware applications / object manager have been implemented (such as Networking, X-Windows, PostgreSQL and virtual machines).<br />
: '''SELinux Configuration Files''' - Describes all known SELinux configuration files with samples. Also lists any specific SELinux commands or libselinux APIs used by them.<br />
: '''SELinux Policy Language''' - Gives a brief description of each policy language statement, with supporting examples taken from the Reference Policy source. Also an introduction to the new CIL language (Common Intermediate Language).<br />
: '''The Reference Policy''' - Describes the Reference Policy and its supporting macros.<br />
: '''SE for Android''' - An overview of the SELinux services used to support Android.<br />
: '''Object Classes and Permissions''' - Describes the SELinux object classes and permissions.<br />
: '''libselinux Functions''' - Describes the <tt>libselinux</tt> library functions.<br />
<br />
<br />
=== Notebook Source Overview ===<br />
To demonstrate some of the SELinux capabilities a supporting Notebook source tarball is available (<tt>notebook-source-4.0.tar.gz</tt>). The tarball contains directories and READMEs covering the following:<br />
: '''Building a Basic Policy''' - Describes how to build monolithic, base and loadable policy modules using core policy language statements and SELinux commands. Note that these policies should not to be used in a live environment, they are examples to show simple policy construction. These can be extended with additional modules in kernel policy language and CIL.<br />
: '''Example <tt>libselinux</tt> applications''' - This contains over 100 samples that use the <tt>libselinux</tt> 2.2.1-6 functions. To save typing long context strings it makes use of a configuration file. There are also some supporting policy modules for the F-20 <tt>targeted</tt> policy to show how the functions work.<br />
: '''Example Android emulator device''' - This replaces the kernel policy language version with a CIL policy using namespaces. This is built using Android 4.4 AOSP master and will show processes as <tt>u:r:kernel.process:s0</tt>, <tt>u:r:untrusted_app.process:s0:c512,c768</tt>. and files as <tt>u:r:bluetooth.data_file:s0</tt>, <tt>u:r:app.data_file:s0:c512,c768</tt> etc..<br />
<br />
== Notebook Sections ==<br />
The major sections are:<br />
* [[NB_Overview | SELinux Overview]]<br />
* [[NB_CoreComponents | Core Components]]<br />
* [[NB_MAC | Mandatory Access Control (MAC)]]<br />
* [[NB_USERS | SELinux Users]]<br />
* [[NB_RBAC | Role-Based Access Control (RBAC)]]<br />
* [[NB_TE | Type Enforcement (TE)]]<br />
* [[NB_SC | Security Context]]<br />
* [[NB_Subjects | Subjects]]<br />
* [[NB_Objects | Objects]]<br />
* [[NB_ComputingSecurityContexts | Computing Security Contexts]]<br />
* [[NB_ComputingAccessDecisions | Computing Access Decisions]]<br />
* [[NB_Domain_and_Object_Transitions | Domain and Object Transitions]]<br />
* [[NB_MLS | Multi-Level Security and Multi-Category Security]]<br />
* [[NB_PolicyType | Types of SELinux Policy]]<br />
* [[NB_PandE | Permissive and Enforcing Modes]]<br />
* [[NB_AL | Auditing Events]]<br />
* [[NB_Poly | Polyinstantiation Support]]<br />
* [[NB_PAM | PAM Login Process]]<br />
* [[NB_LSM | Linux Security Module and SELinux]]<br />
* [[NB_Userspace_Libraries | SELinux Userspace Libraries]]<br />
* [[NB_Networking | SELinux Networking Support]]<br />
* [[NB_VM | SELinux Virtual Machine Support]]<br />
* [[NB_XWIN | SELinux X-Windows Support]]<br />
* [[NB_SandBox | Sandbox Services]]<br />
* [[NB_SQL_9.3 | SE-PostgreSQL Support]]<br />
* [[NB_Apache | Apache-Plus Support]]<br />
* [[ConfigurationFiles | SELinux Configuration Files]]<br />
** [[GlobalConfigurationFiles | Global Configuration Files]]<br />
** [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]]<br />
** [[PolicyConfigurationFiles | Policy Configuration Files]]<br />
* [[PolicyLanguage | The SELinux Policy Languages]]<br />
** [[PolicyLanguage#CIL_Policy_Language | CIL Policy Language]]<br />
** [[PolicyLanguage#Kernel_Policy_Language | Kernel Policy Language]]<br />
*** [[Policy Configuration Statements | Policy Configuration Statements]]<br />
*** [[DefaultRules | Default Rules]]<br />
*** [[UserStatements | User Statements]]<br />
*** [[RoleStatements | Role Statements]]<br />
*** [[TypeStatements | Type Statements]]<br />
*** [[Bounds Rules | Bounds Rules]]<br />
*** [[AVCRules | Access Vector Rules]]<br />
*** [[ObjectClassStatements | Object Class and Permission Statements]]<br />
*** [[ConditionalStatements | Conditional Policy Statements]]<br />
*** [[ConstraintStatements | Constraint Statements]]<br />
*** [[MLSStatements | MLS Statements]]<br />
*** [[SIDStatements | Security ID (SID) Statement]]<br />
*** [[FileStatements | File System Labeling Statements]]<br />
*** [[NetworkStatements | Network Labeling Statements]]<br />
*** [[PolicyStatements | Modular Policy Support Statements]]<br />
*** [[XENStatements | XEN Statements]]<br />
* [[NB_RefPolicy | The Reference Policy]]<br />
* [[NB_Imp_SELinux-aware_Apps | Implementing SELinux-aware Applications]]<br />
* [[NB_SEforAndroid_1 | SE for Android]]<br />
* [[LibselinuxAPISummary | <tt>libselinux</tt> API Summary]]<br />
* [[NB_ObjectClassesPermissions | Object Classes and Permissions]]<br />
<br />
== Abbreviations ==<br />
<br />
{| border="1"<br />
| '''AV'''<br />
| Access Vector<br />
<br />
|-<br />
| '''AVC'''<br />
| Access Vector Cache<br />
<br />
|-<br />
| '''BLP'''<br />
| Bell-La Padula<br />
<br />
|-<br />
| '''CC'''<br />
| [http://www.commoncriteriaportal.org/ Common Criteria]<br />
<br />
|-<br />
| '''CIL'''<br />
| Common Intermediate Language<br />
<br />
|-<br />
| '''CMW'''<br />
| Compartmented Mode Workstation<br />
<br />
|-<br />
| '''DAC'''<br />
| Discretionary Access Control<br />
<br />
|-<br />
| '''F-20'''<br />
| Fedora 20<br />
<br />
|-<br />
| '''FLASK'''<br />
| Flux Advanced Security Kernel<br />
<br />
|-<br />
| '''Fluke'''<br />
| Flux micro kernel Environment<br />
<br />
|-<br />
| '''Flux'''<br />
| The Flux Research Group ([http://www.cs.utah.edu/flux/ http://www.cs.utah.edu/flux/])<br />
<br />
|-<br />
| '''ID'''<br />
| Identification<br />
<br />
|-<br />
| '''LSM'''<br />
| Linux Security Module<br />
<br />
|-<br />
| '''LAPP'''<br />
| Linux, Apache, PostgreSQL, PHP / Perl / Python<br />
<br />
|-<br />
| '''LSPP'''<br />
| Labeled Security Protection Profile<br />
<br />
|-<br />
| '''MAC'''<br />
| Mandatory Access Control<br />
<br />
|-<br />
| '''MCS'''<br />
| Multi-Category Security<br />
<br />
|-<br />
| '''MLS'''<br />
| Multi-Level Security<br />
<br />
|-<br />
| '''NSA'''<br />
| National Security Agency<br />
<br />
|-<br />
| '''OM'''<br />
| Object Manager<br />
<br />
|-<br />
| '''OTA'''<br />
| over the air<br />
<br />
|-<br />
| '''PAM'''<br />
| Pluggable Authentication Module<br />
<br />
|-<br />
| '''RBAC'''<br />
| Role-based Access Control<br />
<br />
|-<br />
| '''rpm'''<br />
| Red Hat Package Manager<br />
<br />
|-<br />
| '''SELinux'''<br />
| Security Enhanced Linux<br />
<br />
|-<br />
| '''SID'''<br />
| Security Identifier<br />
<br />
|-<br />
| '''SMACK'''<br />
| [http://www.schaufler-ca.com/ Simplified Mandatory Access Control Kernel]<br />
<br />
|-<br />
| '''SUID'''<br />
| Super-user Identifier<br />
<br />
|-<br />
| '''TE'''<br />
| Type Enforcement<br />
<br />
|-<br />
| '''UID'''<br />
| User Identifier<br />
<br />
|-<br />
| '''XACE'''<br />
| X (windows) Access Control Extension<br />
<br />
|}<br />
== Terminology ==<br />
These give a brief introduction to the major components that form the core SELinux infrastructure.<br />
<br />
<br />
{| border="1"<br />
! Term<br />
! Description<br />
<br />
|-<br />
| '''Access Vector (AV)'''<br />
| A bit map representing a set of permissions (such as open, read, write).<br />
<br />
|-<br />
| '''Access Vector Cache (AVC)'''<br />
| A component that stores access decisions made by the SELinux '''Security Server''' for subsequent use by '''Object Managers'''. This allows previous decisions to be retrieved without the overhead of re-computation.<br />
<br />
Within the core SELinux services there are two '''Access Vector Caches''':# A kernel AVC that caches decisions by the '''Security Server''' on behalf of kernel based object managers.<br />
# A userspace AVC built into <tt>'''libselinux'''</tt> that caches decisions when SELinux-aware applications use <tt>'''avc_open'''(3)</tt> with <tt>'''avc_has_perm'''(3)</tt> or <tt>'''avc_has_perm_noaudit'''(3)</tt> function calls. This will save kernel calls after the first decision has been made.<br />
<br />
<br />
<br />
|-<br />
| '''Domain'''<br />
| For SELinux this consists of one or more processes associated to the type component of a '''Security Context'''. '''Type Enforcement''' rules declared in Policy describe how the domain will interact with objects (see '''Object Class''').<br />
<br />
|-<br />
| '''Linux Security Module (LSM)'''<br />
| A framework that provides hooks into kernel components (such as disk and network services) that can be utilised by security modules (e.g. SELinux and SMACK) to perform access control checks.<br />
<br />
Currently only one LSM module can be loaded, however work is in progress to stack multiple modules).<br />
<br />
|-<br />
| '''Mandatory Access Control'''<br />
| An access control mechanisim enforced by the system. This can be achieved by 'hard-wiring' the operating system and applications (the bad old days - well good for some) or via a policy that conforms to a '''Policy'''. Examples of policy based MAC are SELinux and SMACK.<br />
<br />
|-<br />
| '''Multi-Level Security (MLS)'''<br />
| Based on the Bell-La & Padula model (BLP) for confidentiality in that (for example) a process running at a 'Confidential' level can read / write at their current level but only read down levels or write up levels. While still used in this way, it is more commonly used for application separation utilising the Multi-Category Security variant.<br />
<br />
|-<br />
| '''Object Class'''<br />
| Describes a resource such as files, sockets or services.<br />
<br />
Each 'class' has relevant permissions associated to it such as read, write or export. This allows access to be enforced on the instantiated object by their '''Object Manager'''. <br />
<br />
|-<br />
| '''Object Manager'''<br />
| Userspace and kernel components that are responsible for the labeling, management (e.g. creation, access, destruction) and enforcement of the objects under their control. '''Object Managers''' call the '''Security Server''' for an access decision based on a source and target '''Security Context''' (or '''SID'''), an '''Object Class''' and a set of permissions (or '''AV'''s). The '''Security Server''' will base its decision on whether the currently loaded '''Policy''' will allow or deny access.<br />
<br />
An '''Object Manager''' may also call the '''Security Server''' to compute a new '''Security Context''' or '''SID''' for an object.<br />
<br />
|-<br />
| '''Policy'''<br />
| A set of rules determining access rights. In SELinux these rules are generally written in a kernel policy language using either <tt>'''m4'''(1)</tt> macro support (e.g. Reference Policy) or the new CIL language. The '''Policy''' is then compiled into a binary format for loading into the '''Security Server'''.<br />
<br />
|-<br />
| '''Role Based Access Control'''<br />
| SELinux users are associated to one or more roles, each role may then be associated to one or more '''Domain''' types.<br />
<br />
|-<br />
| '''Security Server'''<br />
| A sub-system in the Linux kernel that makes access decisions and computes security contexts based on '''Policy''' on behalf of SELinux-aware applications and Object Managers.<br />
<br />
The''' Security Server''' does not enforce a decision, it merely states whether the operation is allowed or not according to the '''Policy'''. It is the SELinux-aware application or '''Object Manager''' responsibility to enforce the decision.<br />
<br />
|-<br />
| '''Security Context'''<br />
| An SELinux '''Security Context''' is a variable length string that consists of the following mandatory components <tt>user:role:type</tt> and an optional <tt><nowiki>[:range]</nowiki></tt> component.<br />
<br />
Generally abbreviated to 'context', and sometimes called a 'label'.<br />
<br />
|-<br />
| '''Security Identifier (SID)'''<br />
| SIDs are unique opaque integer values mapped by the kernel '''Security Server''' and userspace AVC that represent a '''Security Context'''.<br />
<br />
The SIDs generated by the kernel '''Security Server''' are <tt>u32</tt> values that are passed via the '''Linux Security Module''' hooks to/from the kernel '''Object Managers'''.<br />
<br />
|-<br />
| '''Type Enforcement'''<br />
| SELinux makes use of a specific style of type enforcement (TE) to enforce '''Mandatory Access Control'''. This is where all subjects and objects have a type identifier associated to them that can then be used to enforce rules laid down by '''Policy'''.<br />
<br />
|}</div>RichardHaineshttp://selinuxproject.org/page/NB_ObjectClassesPermissionsNB ObjectClassesPermissions2015-02-03T15:42:36Z<p>RichardHaines: </p>
<hr />
<div>= Object Classes and Permissions =<br />
== Introduction ==<br />
This section contains a list of object classes and their associated permissions that have been taken from the Fedora F-20 policy sources. There are also additional entries for Xen. The SEAndroid specific classes and permissions are shown in the [[NB_SEforAndroid_1 | Security Enhancements for Android]] section.<br />
<br />
All objects are kernel objects unless marked as user space objects.<br />
<br />
In most cases the permissions are self explanatory as they are those used in the standard Linux function calls (such as 'create a socket' or 'write to a file'). Some SELinux specific permissions are:<br />
<br />
{| border="1"<br />
| relabelfrom<br />
| Used on most objects to allow the objects security context to be changed from the current type.<br />
<br />
|-<br />
| relabelto<br />
| Used on most objects to allow the objects security context to be changed to the new type.<br />
<br />
|-<br />
| entrypoint<br />
| Used for files to indicate that they can be used as an entry point into a domain via a domain transition.<br />
<br />
|-<br />
| execute_no_trans<br />
| Used for files to indicate that they can be used as an entry point into the calling domain (i.e. does not require a domain transition).<br />
<br />
|-<br />
| execmod<br />
| Generally used for files to indicate that they can execute the modified file in memory.<br />
<br />
|}<br />
<br />
<br />
Where possible the specific object class permissions are explained, however for some permissions it is difficult to determine what they are used for (or if used at all) so a '?' has been added when doubt exists.<br />
<br />
== Defining Object Classes and Permissions ==<br />
The Reference Policy already contains the default object classes and permissions required to manage the system and supporting services.<br />
<br />
For those who write or manager SELinux policy, there is no need to define new objects and their associated permissions as these would be done by those who actually design and/or write object managers.<br />
<br />
== Common Permissions ==<br />
=== Common File Permissions ===<br />
Common file permissions inherited by a number of object classes.<br />
<br />
{| border="1"<br />
| '''Permissions'''<br />
| '''Description''' (17 permissions)<br />
<br />
|-<br />
| append<br />
| Append to file.<br />
<br />
|-<br />
| create<br />
| Create new file.<br />
<br />
|-<br />
| execute<br />
| Execute the file with domain transition.<br />
<br />
|-<br />
| getattr<br />
| Get file attributes.<br />
<br />
|-<br />
| ioctl<br />
| I/O control system call requests.<br />
<br />
|-<br />
| link<br />
| Create hard link.<br />
<br />
|-<br />
| lock<br />
| Set and unset file locks.<br />
<br />
|-<br />
| mounton<br />
| Use as mount point.<br />
<br />
|-<br />
| quotaon<br />
| Enable quotas.<br />
<br />
|-<br />
| read<br />
| Read file contents.<br />
<br />
|-<br />
| relabelfrom<br />
| Change the security context based on existing type.<br />
<br />
|-<br />
| relabelto<br />
| Change the security context based on the new type.<br />
<br />
|-<br />
| rename<br />
| Rename file.<br />
<br />
|-<br />
| setattr<br />
| Change file attributes.<br />
<br />
|-<br />
| swapon<br />
| Allow file to be used for paging / swapping space. (not used ?)<br />
<br />
|-<br />
| unlink<br />
| Delete file (or remove hard link).<br />
<br />
|-<br />
| write<br />
| Write or append file contents.<br />
<br />
|}<br />
<br />
<br />
=== Common Socket Permissions ===<br />
Common socket permissions inherited by a number of object classes.<br />
<br />
'''Table 32: Common Socket Permissions'''<br />
{| border="1"<br />
| '''Permissions'''<br />
| '''Description '''(22 Permissions)<br />
<br />
|-<br />
| accept<br />
| Accept a connection.<br />
<br />
|-<br />
| append<br />
| Write or append socket contents<br />
<br />
|-<br />
| bind<br />
| Bind to a name.<br />
<br />
|-<br />
| connect<br />
| Initiate a connection.<br />
<br />
|-<br />
| create<br />
| Create new socket.<br />
<br />
|-<br />
| getattr<br />
| Get socket information.<br />
<br />
|-<br />
| getopt<br />
| Get socket options. <br />
<br />
|-<br />
| ioctl<br />
| Get and set attributes via ioctl call requests.<br />
<br />
|-<br />
| listen<br />
| Listen for connections.<br />
<br />
|-<br />
| lock<br />
| Lock and unlock socket file descriptor.<br />
<br />
|-<br />
| name_bind<br />
| <tt>AF_INET</tt> - Controls relationship between a socket and the port number.<br />
<br />
<tt>AF_UNIX</tt> - Controls relationship between a socket and the file.<br />
<br />
|-<br />
| read<br />
| Read data from socket.<br />
<br />
|-<br />
| recv_msg<br />
| Receive datagram.<br />
<br />
|-<br />
| recvfrom<br />
| Receive datagrams from socket.<br />
<br />
|-<br />
| relabelfrom<br />
| Change the security context based on existing type.<br />
<br />
|-<br />
| relabelto<br />
| Change the security context based on the new type.<br />
<br />
|-<br />
| send_msg<br />
| Send datagram.<br />
<br />
|-<br />
| sendto<br />
| Send datagrams to socket.<br />
<br />
|-<br />
| setattr<br />
| Change attributes.<br />
<br />
|-<br />
| setopt<br />
| Set socket options.<br />
<br />
|-<br />
| shutdown<br />
| Terminate connection.<br />
<br />
|-<br />
| write<br />
| Write data to socket.<br />
<br />
|}<br />
<br />
<br />
=== Common IPC Permissions ===<br />
Common IPC permissions inherited by a number of object classes.<br />
<br />
{| border="1"<br />
| '''Permissions'''<br />
| '''Description '''(9 Permissions)<br />
<br />
|-<br />
| associate<br />
| shm - Get shared memory ID.<br />
<br />
msgq - Get message ID.<br />
<br />
sem - Get semaphore ID.<br />
<br />
|-<br />
| create<br />
| Create.<br />
<br />
|-<br />
| destroy<br />
| Destroy.<br />
<br />
|-<br />
| getattr<br />
| Get information from IPC object.<br />
<br />
|-<br />
| read<br />
| shm - Attach shared memory to process.<br />
<br />
msgq - Read message from queue.<br />
<br />
sem - Get semaphore value.<br />
<br />
|-<br />
| setattr<br />
| Set IPC object information.<br />
<br />
|-<br />
| unix_read<br />
| Read.<br />
<br />
|-<br />
| unix_write<br />
| Write or append.<br />
<br />
|-<br />
| write<br />
| shm - Attach shared memory to process.<br />
<br />
msgq - Send message to message queue.<br />
<br />
sem - Change semaphore value.<br />
<br />
|}<br />
<br />
<br />
=== Common Database Permissions ===<br />
Common database permissions inherited by a number of object classes. The "[http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Security-Enhanced PostgreSQL Security Wiki]<nowiki>" [2] explains the objects, their permissions and how they should be used in detail.</nowiki><br />
<br />
{| border="1"<br />
| '''Permissions'''<br />
| '''Description''' (6 Permissions)<br />
<br />
|-<br />
| create<br />
| Create a database object such as a 'TABLE'.<br />
<br />
|-<br />
| drop<br />
| Delete (<tt>DROP</tt>) a database object.<br />
<br />
|-<br />
| getattr<br />
| Get metadata - needed to reference an object (e.g. SELECT ... FROM ...).<br />
<br />
|-<br />
| relabelfrom<br />
| Change the security context based on existing type.<br />
<br />
|-<br />
| relabelto<br />
| Change the security context based on the new type.<br />
<br />
|-<br />
| setattr<br />
| Set metadata - this permission is required to update information in the database (e.g. ALTER ...).<br />
<br />
|}<br />
<br />
<br />
=== Common X_Device Permissions ===<br />
Common <tt>x_device</tt> permissions inherited by the X-Windows <tt>x_keyboard</tt> and <tt>x_pointer</tt> object classes.<br />
<br />
{| border="1"<br />
| '''Permissions'''<br />
| '''Description''' (19 permissions)<br />
<br />
|-<br />
| add<br />
| <br />
<br />
|-<br />
| bell<br />
| <br />
<br />
|-<br />
| create<br />
| <br />
<br />
|-<br />
| destroy<br />
| <br />
<br />
|-<br />
| force_cursor<br />
| Get window focus.<br />
<br />
|-<br />
| freeze<br />
| <br />
<br />
|-<br />
| get_property<br />
| Required to create a device context. (source code)<br />
<br />
|-<br />
| getattr<br />
| <br />
<br />
|-<br />
| getfocus<br />
| <br />
<br />
|-<br />
| grab<br />
| Set window focus.<br />
<br />
|-<br />
| list_property<br />
| <br />
<br />
|-<br />
| manage<br />
| <br />
<br />
|-<br />
| read<br />
| <br />
<br />
|-<br />
| remove<br />
| <br />
<br />
|-<br />
| set_property<br />
| <br />
<br />
|-<br />
| setattr<br />
| <br />
<br />
|-<br />
| setfocus<br />
| <br />
<br />
|-<br />
| use<br />
| <br />
<br />
|-<br />
| write<br />
| <br />
<br />
|}<br />
<br />
<br />
== File Object Classes ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''filesystem''' - A mounted filesystem<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (10 unique permissions)<br />
<br />
|-<br />
| associate<br />
| Use type as label for file.<br />
<br />
|-<br />
| getattr<br />
| Get file attributes.<br />
<br />
|-<br />
| mount<br />
| Mount filesystem.<br />
<br />
|-<br />
| quotaget<br />
| Get quota information.<br />
<br />
|-<br />
| quotamod<br />
| Modify quota information.<br />
<br />
|-<br />
| relabelfrom<br />
| Change the security context based on existing type.<br />
<br />
|-<br />
| relabelto<br />
| Change the security context based on the new type.<br />
<br />
|-<br />
| remount<br />
| Remount existing mount.<br />
<br />
|-<br />
| transition<br />
| Transition to a new SID (change security context).<br />
<br />
|-<br />
| unmount<br />
| Unmount filesystem.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''dir''' - Directory<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 17 common file permissions + 7 unique)<br />
<br />
|-<br />
| [[#Common_File_Permissions | Inherit Common File Permissions]]<br />
| append, create, execute, getattr, ioctl, link, lock, mounton, quotaon, read, relabelfrom, relabelto, rename, setattr, swapon, unlink, write<br />
<br />
|-<br />
| add_name<br />
| Add entry to the directory.<br />
<br />
|-<br />
| audit_access<br />
| The rules for this permission work as follows:<br />
<br />
If a process calls <tt>access()</tt> or <tt>faccessat()</tt> and SELinux denies their request there will be a check for a <tt>dontaudit</tt> rule on the <tt>audit_access</tt> permission. If there is a <tt>dontaudit</tt> rule on <tt>audit_access</tt> an AVC event will not be written. If there is no <tt>dontaudit</tt> rule an AVC event will be written for the permissions requested (<tt>read</tt>, <tt>write</tt>, or <tt>exec</tt>). <br />
<br />
Notes:# There will never be a denial message with the<tt> audit_access</tt> permission as this permission does not control security decisions.<br />
# <tt>allow</tt> and <tt>auditallow</tt> rules with this permission are therfore meaningless, however the kernel will accept a policy with such rules, but they will do nothing.<br />
<br />
<br />
<br />
|-<br />
| execmod<br />
| Make executable a file that has been modified by copy-on-write.<br />
<br />
|-<br />
| open<br />
| Added in 2.6.26 Kernel to control the open permission.<br />
<br />
|-<br />
| remove_name<br />
| Remove an entry from the directory.<br />
<br />
|-<br />
| reparent<br />
| Change parent directory.<br />
<br />
|-<br />
| rmdir<br />
| Remove directory.<br />
<br />
|-<br />
| search<br />
| Search directory.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''file''' - Ordinary file<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 17 common file permissions + 5 unique)<br />
<br />
|-<br />
| [[#Common_File_Permissions | Inherit Common File Permissions]]<br />
| append, create, execute, getattr, ioctl, link, lock, mounton, quotaon, read, relabelfrom, relabelto, rename, setattr, swapon, unlink, write<br />
<br />
|-<br />
| audit_access<br />
| See the <tt>dir</tt> class for details<br />
<br />
|-<br />
| entrypoint<br />
| Entry point permission for a domain transition.<br />
<br />
|-<br />
| execute_no_trans<br />
| Execute in the caller's domain (i.e. no domain transition).<br />
<br />
|-<br />
| execmod<br />
| Make executable a file that has been modified by copy-on-write.<br />
<br />
|-<br />
| open<br />
| Added in 2.6.26 Kernel to control the open permission.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''lnk_file''' - Symbolic links<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 17 common file permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_File_Permissions | Inherit Common File Permissions]]<br />
| append, create, execute, getattr, ioctl, link, lock, mounton, quotaon, read, relabelfrom, relabelto, rename, setattr, swapon, unlink, write<br />
<br />
|-<br />
| audit_access<br />
| See the <tt>dir</tt> class for details<br />
<br />
|-<br />
| execmod<br />
| Make executable a file that has been modified by copy-on-write.<br />
<br />
|-<br />
| open<br />
| Added in 2.6.26 Kernel to control the open permission.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''chr_file''' - Character files<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 17 common file permissions + 5 unique)<br />
<br />
|-<br />
| [[#Common_File_Permissions | Inherit Common File Permissions]]<br />
| append, create, execute, getattr, ioctl, link, lock, mounton, quotaon, read, relabelfrom, relabelto, rename, setattr, swapon, unlink, write<br />
<br />
|-<br />
| audit_access<br />
| See the <tt>dir</tt> class for details<br />
<br />
|-<br />
| entrypoint<br />
| Entry point permission for a domain transition.<br />
<br />
|-<br />
| execute_no_trans<br />
| Execute in the caller's domain (i.e. no domain transition).<br />
<br />
|-<br />
| execmod<br />
| Make executable a file that has been modified by copy-on-write.<br />
<br />
|-<br />
| open<br />
| Added in 2.6.26 Kernel to open a character device.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''blk_file''' - Block files<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 17 common file permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_File_Permissions | Inherit Common File Permissions]]<br />
| append, create, execute, getattr, ioctl, link, lock, mounton, quotaon, read, relabelfrom, relabelto, rename, setattr, swapon, unlink, write<br />
<br />
|-<br />
| audit_access<br />
| See the <tt>dir</tt> class for details<br />
<br />
|-<br />
| execmod<br />
| Make executable a file that has been modified by copy-on-write.<br />
<br />
|-<br />
| open<br />
| Added in 2.6.26 Kernel to control the open permission.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''sock_file''' - UNIX domain sockets<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 17 common file permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_File_Permissions | Inherit Common File Permissions]]<br />
| append, create, execute, getattr, ioctl, link, lock, mounton, quotaon, read, relabelfrom, relabelto, rename, setattr, swapon, unlink, write<br />
<br />
|-<br />
| audit_access<br />
| See the <tt>dir</tt> class for details<br />
<br />
|-<br />
| execmod<br />
| Make executable a file that has been modified by copy-on-write.<br />
<br />
|-<br />
| open<br />
| Added in 2.6.26 Kernel to control the open permission.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''fifo_file''' - Named pipes<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 17 common file permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_File_Permissions | Inherit Common File Permissions]]<br />
| append, create, execute, getattr, ioctl, link, lock, mounton, quotaon, read, relabelfrom, relabelto, rename, setattr, swapon, unlink, write<br />
<br />
|-<br />
| audit_access<br />
| See the <tt>dir</tt> class for details<br />
<br />
|-<br />
| execmod<br />
| Make executable a file that has been modified by copy-on-write.<br />
<br />
|-<br />
| open<br />
| Added in 2.6.26 Kernel to control the open permission.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''fd''' - File descriptors<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (1 unique permission)<br />
<br />
|-<br />
| use<br />
| 1) Inherit fd when process is executed and domain has been changed.<br />
<br />
2) Receive fd from another process by Unix domain socket.<br />
<br />
3) Get and set attribute of fd.<br />
<br />
|}<br />
<br />
<br />
== Network Object Classes ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''node''' - IP address or range of IP addresses<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (11 unique permissions)<br />
<br />
|-<br />
| dccp_recv<br />
| Allow Datagram Congestion Control Protocol receive packets. <br />
<br />
|-<br />
| dccp_send<br />
| Allow Datagram Congestion Control Protocol send packets.<br />
<br />
|-<br />
| enforce_dest<br />
| Ensure that destination node can enforce restrictions on the destination socket.<br />
<br />
|-<br />
| rawip_recv<br />
| Receive raw IP packet.<br />
<br />
|-<br />
| rawip_send<br />
| Send raw IP packet.<br />
<br />
|-<br />
| recvfrom<br />
| Network interface and address check permission for use with the ingress permission.<br />
<br />
|-<br />
| sendto<br />
| Network interface and address check permission for use with the egress permission.<br />
<br />
|-<br />
| tcp_recv<br />
| Receive TCP packet.<br />
<br />
|-<br />
| tcp_send<br />
| Send TCP packet.<br />
<br />
|-<br />
| udp_recv<br />
| Receive UDP packet.<br />
<br />
|-<br />
| udp_send<br />
| Send UDP packet.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netif''' - Network Interface (e.g. eth0)<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (10 unique permissions)<br />
<br />
|-<br />
| dccp_recv<br />
| Allow Datagram Congestion Control Protocol receive packets.<br />
<br />
|-<br />
| dccp_send<br />
| Allow Datagram Congestion Control Protocol send packets.<br />
<br />
|-<br />
| egress<br />
| Each packet leaving the system must pass an egress access control. Also requires the node sendto permission.<br />
<br />
|-<br />
| ingress<br />
| Each packet entering the system must pass an ingress access control. Also requires the node recvfrom permission.<br />
<br />
|-<br />
| rawip_recv<br />
| Receive raw IP packet.<br />
<br />
|-<br />
| rawip_send<br />
| Send raw IP packet.<br />
<br />
|-<br />
| tcp_recv<br />
| Receive TCP packet.<br />
<br />
|-<br />
| tcp_send<br />
| Send TCP packet.<br />
<br />
|-<br />
| udp_recv<br />
| Receive UDP packet.<br />
<br />
|-<br />
| udp_send<br />
| Send UDP packet.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''socket''' - Socket that is not part of any other specific SELinux socket object class.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''tcp_socket''' - Protocol: PF_INET, PF_INET6 Family Type: SOCK_STREAM<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions + 5 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| acceptfrom<br />
| Accept connection from client socket. <br />
<br />
|-<br />
| connectto<br />
| Connect to server socket.<br />
<br />
|-<br />
| name_connect<br />
| Connect to a specific port type.<br />
<br />
|-<br />
| newconn<br />
| Create new connection.<br />
<br />
|-<br />
| node_bind<br />
| Bind to a node.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''udp_socket''' - Protocol: PF_INET, PF_INET6 Family Type: SOCK_DGRAM<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions + 1 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| node_bind<br />
| Bind to a node.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''rawip_socket''' - Protocol: PF_INET, PF_INET6 Family Type: SOCK_RAW<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 1 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| node_bind<br />
| Bind to a node.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''packet_socket''' - Protocol: PF_PACKET Family Type: All.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''unix_stream_socket''' - Communicate with processes on same machine. Protocol: PF_STREAM Family Type: SOCK_STREAM<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| acceptfrom<br />
| Accept connection from client socket.<br />
<br />
|-<br />
| connectto<br />
| Connect to server socket.<br />
<br />
|-<br />
| newconn<br />
| Create new socket for connection.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''unix_dgram_socket''' - Communicate with processes on same machine. Protocol: PF_STREAM Family Type: SOCK_DGRAM<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''tun_socket''' - TUN is Virtual Point-to-Point network device driver to support IP tunneling.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 1 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| attach_queue<br />
| <br />
<br />
|}<br />
<br />
<br />
=== IPSec Network Object Classes ===<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''association''' - IPSec security association<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(4 unique permissions)<br />
<br />
|-<br />
| polmatch<br />
| Match IPSec Security Policy Database (SPD) context (-ctx) entries to an SELinux domain (contained in the Security Association Database (SAD) .<br />
<br />
|-<br />
| recvfrom<br />
| Receive from an IPSec association.<br />
<br />
|-<br />
| sendto<br />
| Send to an IPSec assocation.<br />
<br />
|-<br />
| setcontext<br />
| Set the context of an IPSec association on creation.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''key_socket''' - IPSec key management. Protocol: PF_KEY Family Type: All<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_xfrm_socket''' - Netlink socket to maintain IPSec parameters. <br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 2 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| nlmsg_read<br />
| Get IPSec configuration information.<br />
<br />
|-<br />
| nlmsg_write<br />
| Set IPSec configuration information.<br />
<br />
|}<br />
<br />
<br />
=== Netlink Object Classes ===<br />
Netlink sockets communicate between userspace and the kernel.<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_socket''' - Netlink socket that is not part of any specific SELinux Netlink socket class. Protocol: PF_NETLINK Family Type: All other types that are not part of any other specific netlink object class.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_route_socket''' - Netlink socket to manage and control network resources.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 2 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| nlmsg_read<br />
| Read kernel routing table.<br />
<br />
|-<br />
| nlmsg_write<br />
| Write to kernel routing table.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_firewall_socket''' - Netlink socket for firewall filters.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 2 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| nlmsg_read<br />
| Read netlink message.<br />
<br />
|-<br />
| nlmsg_write<br />
| Write netlink message.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_tcpdiag_socket''' - Netlink socket to monitor TCP connections.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 2 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| nlmsg_read<br />
| Request information about a protocol.<br />
<br />
|-<br />
| nlmsg_write<br />
| Write netlink message.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_nflog_socket''' - Netlink socket for Netfilter logging<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_selinux_socket''' - Netlink socket to receive SELinux events such as a policy or boolean change.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_audit_socket''' - Netlink socket for audit service.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 5 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| nlmsg_read<br />
| Query status of audit service.<br />
<br />
|-<br />
| nlmsg_readpriv<br />
| List auditing configuration rules.<br />
<br />
|-<br />
| nlmsg_relay<br />
| Send userspace audit messages to theaudit service.<br />
<br />
|-<br />
| nlmsg_tty_audit<br />
| Control TTY auditing.<br />
<br />
|-<br />
| nlmsg_write<br />
| Update audit service configuration.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_ip6fw_socket''' - Netlink socket for IPv6 firewall filters.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 2 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| nlmsg_read<br />
| Read netlink message.<br />
<br />
|-<br />
| nlmsg_write<br />
| Write netlink message.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_dnrt_socket''' - Netlink socket for DECnet routing<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''netlink_kobject_uevent_socket''' - Netlink socket to send kernel events to userspace.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
=== Miscellaneous Network Object Classes ===<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''peer '''- NetLabel and Labeled IPsec have separate access controls, the network peer label consolidates these two access controls into a single one (see [http://paulmoore.livejournal.com/1863.html http://paulmoore.livejournal.com/1863.html] for details).<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (1 unique permission)<br />
<br />
|-<br />
| recv<br />
| Receive packets from a labeled networking peer.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''packet''' - Supports 'secmark' services where packets are labeled using iptables to select and label packets, SELinux thent enforces policy using these packet labels.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (7 unique permissions)<br />
<br />
|-<br />
| flow_in<br />
| Receive external packets. (deprecated)<br />
<br />
|-<br />
| flow_out<br />
| Send packets externally. (deprecated)<br />
<br />
|-<br />
| forward_in<br />
| Allow inbound forwaded packets. <br />
<br />
|-<br />
| forward_out<br />
| Allow outbound forwarded packets. <br />
<br />
|-<br />
| recv<br />
| Receive inbound locally consumed packets. <br />
<br />
|-<br />
| relabelto<br />
| Control how domains can apply specific labels to packets.<br />
<br />
|-<br />
| send<br />
| Send outbound locally generated packets. <br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''appletalk_socket''' - Appletalk socket<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 22 common socket permissions)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''dccp_socket - '''Datagram Congestion Control Protocol (DCCP)<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 22 common socket permissions + 2 unique)<br />
<br />
|-<br />
| [[#Common_Socket_Permissions | Inherit Common Socket Permissions]]<br />
| accept, append, bind, connect, create, getattr, getopt, ioctl, listen, lock, name_bind, read, recv_msg, recvfrom, relabelfrom, relabelto, send_msg, sendto, setattr, setopt, shutdown, write<br />
<br />
|-<br />
| name_connect<br />
| Allow DCCP name connect(). <br />
<br />
|-<br />
| node_bind<br />
| Allow DCCP bind().<br />
<br />
|}<br />
<br />
<br />
== IPC Object Classes ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''ipc''' - Interprocess communications<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 9 common IPC permissions)<br />
<br />
|-<br />
| [[#Common_IPC_Permissions | Inherit Common IPC Permissions]]<br />
| associate, create, destroy, getattr, read, setattr, unix_read, unix_write, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''sem''' - Semaphores<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 9 common IPC permissions)<br />
<br />
|-<br />
| [[#Common_IPC_Permissions | Inherit Common IPC Permissions]]<br />
| associate, create, destroy, getattr, read, setattr, unix_read, unix_write, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''msgq''' - IPC Message queues<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 9 common IPC permissions + 1 unique)<br />
<br />
|-<br />
| [[#Common_IPC_Permissions | Inherit Common IPC Permissions]]<br />
| associate, create, destroy, getattr, read, setattr, unix_read, unix_write, write<br />
<br />
|-<br />
| enqueue<br />
| Send message to message queue.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''msg''' - Message in a queue<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| receive<br />
| Read (and remove) message from queue.<br />
<br />
|-<br />
| send<br />
| Add message to queue.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''shm''' - Shared memory segment<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (Inherit 9 common IPC permissions + 1 unique)<br />
<br />
|-<br />
| [[#Common_IPC_Permissions | Inherit Common IPC Permissions]]<br />
| associate, create, destroy, getattr, read, setattr, unix_read, unix_write, write<br />
<br />
|-<br />
| lock<br />
| Lock or unlock shared memory.<br />
<br />
|}<br />
<br />
<br />
== Process Object Class ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''process''' - An object is instantiated for each process created by the system.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (31 unique permissions)<br />
<br />
|-<br />
| dyntransition<br />
| Dynamically transition to a new context using <tt>'''setcon'''(3)</tt>.<br />
<br />
|-<br />
| execheap<br />
| Make the heap executable.<br />
<br />
|-<br />
| execmem<br />
| Make executable an anonymous mapping or private file mapping that is writable.<br />
<br />
|-<br />
| execstack<br />
| Make the main process stack executable.<br />
<br />
|-<br />
| fork<br />
| Create new process using fork(2).<br />
<br />
|-<br />
| getattr<br />
| Get process security information.<br />
<br />
|-<br />
| getcap<br />
| Get Linux capabilities of process.<br />
<br />
|-<br />
| getpgid<br />
| Get group Process ID of another process.<br />
<br />
|-<br />
| getsched<br />
| Get scheduling information of another process.<br />
<br />
|-<br />
| getsession<br />
| Get session ID of another process.<br />
<br />
|-<br />
| noatsecure<br />
| Disable secure mode environment cleansing.<br />
<br />
|-<br />
| ptrace<br />
| Trace program execution of parent ('''ptrace'''(2)).<br />
<br />
|-<br />
| ptrace_child<br />
| Trace program execution of child ('''ptrace'''(2)).<br />
<br />
|-<br />
| rlimitinh<br />
| Inherit rlimit information from parent process.<br />
<br />
|-<br />
| setcap<br />
| Set Linux capabilities of process.<br />
<br />
|-<br />
| setcurrent<br />
| Set the current process context.<br />
<br />
|-<br />
| setexec<br />
| Set security context of executed process by '''setexecon'''(3).<br />
<br />
|-<br />
| setfscreate<br />
| Set security context by '''setfscreatecon'''(3).<br />
<br />
|-<br />
| setkeycreate<br />
| Set security context by '''setkeycreatecon'''(3).<br />
<br />
|-<br />
| setpgid<br />
| Set group Process ID of another process.<br />
<br />
|-<br />
| setrlimit<br />
| Change process rlimit information.<br />
<br />
|-<br />
| setsched<br />
| Modify scheduling information of another process.<br />
<br />
|-<br />
| setsockcreate<br />
| Set security context by '''setsockcreatecon'''(3).<br />
<br />
|-<br />
| share<br />
| Allow state sharing with cloned or forked process.<br />
<br />
|-<br />
| sigchld<br />
| Send SIGCHLD signal.<br />
<br />
|-<br />
| siginh<br />
| Inherit signal state from parent process.<br />
<br />
|-<br />
| sigkill<br />
| Send SIGKILL signal.<br />
<br />
|-<br />
| signal<br />
| Send a signal other than SIGKILL, SIGSTOP, or SIGCHLD.<br />
<br />
|-<br />
| signull<br />
| Test for exisitence of another process without sending a signal<br />
<br />
|-<br />
| sigstop<br />
| Send SIGSTOP signal<br />
<br />
|-<br />
| transition<br />
| Transition to a new context on exec().<br />
<br />
|}<br />
<br />
<br />
== Security Object Class ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''security''' - This is the security server object and there is only one instance of this object (for the SELinux security server).<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (12 unique permissions)<br />
<br />
|-<br />
| check_context<br />
| Determine whether the context is valid by querying the security server.<br />
<br />
|-<br />
| compute_av<br />
| Compute an access vector given a source, target and class.<br />
<br />
|-<br />
| compute_create<br />
| Determine context to use when querying the security server about a transition rule (type_transition).<br />
<br />
|-<br />
| compute_member<br />
| Determine context to use when querying the security server about a membership decision (type_member for a polyinstantiated object).<br />
<br />
|-<br />
| compute_relabel<br />
| Determines the context to use when querying the security server about a relabeling decision (type_change).<br />
<br />
|-<br />
| compute_user<br />
| Determines the context to use when querying the security server about a user decision (user).<br />
<br />
|-<br />
| load_policy<br />
| Load the security policy into the kernel (the security server).<br />
<br />
|-<br />
| read_policy<br />
| Read the kernel policy to userspace.<br />
<br />
|-<br />
| setbool<br />
| Change a boolean value within the active policy.<br />
<br />
|-<br />
| setcheckreqprot<br />
| Set if SELinux will check original protection mode or modified protection mode (read-implies-exec) for mmap / mprotect.<br />
<br />
|-<br />
| setenforce<br />
| Change the enforcement state of SELinux (permissive or enforcing).<br />
<br />
|-<br />
| setsecparam<br />
| Set kernel access vector cache tuning parameters.<br />
<br />
|}<br />
<br />
<br />
== System Operation Object Class ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''system''' - This is the overall system object and there is only one instance of this object.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (12 unique permissions)<br />
<br />
|-<br />
| disable<br />
| Allow services to be disabled.<br />
<br />
|-<br />
| enable<br />
| Allow services to be enabled.<br />
<br />
|-<br />
| halt<br />
| Allow the system to be halted.<br />
<br />
|-<br />
| ipc_info<br />
| Get info about an IPC object.<br />
<br />
|-<br />
| module_request<br />
| Request the kernel to load a module.<br />
<br />
|-<br />
| reboot<br />
| Allow system to be rebooted.<br />
<br />
|-<br />
| reload<br />
| Allow services to be reloaded.<br />
<br />
|-<br />
| status<br />
| Get system status information.<br />
<br />
|-<br />
| syslog_console<br />
| Control output of kernel messages to the console with syslog(2).<br />
<br />
|-<br />
| syslog_mod<br />
| Clear kernel message buffer with syslog(2).<br />
<br />
|-<br />
| syslog_read<br />
| Read kernel message with syslog(2).<br />
<br />
|-<br />
| undefined<br />
| Allow an undefined operation.<br />
<br />
|}<br />
<br />
<br />
== Kernel Service Object Class ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''kernel_service''' - Used to add kernel services.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| use_as_override<br />
| Grant a process the right to nominate an alternate process SID for the kernel to use as an override for the SELinux subjective security when accessing information on behalf of another process.<br />
<br />
For example, CacheFiles when accessing the cache on behalf of a process accessing an NFS file needs to use a subjective security ID appropriate to the cache rather than the one the calling process is using. The <tt>cachefilesd</tt> daemon will nominate the security ID to be used.<br />
<br />
|-<br />
| create_files_as<br />
| Grant a process the right to nominate a file creation label for a kernel service to use.<br />
<br />
|}<br />
<br />
<br />
== Capability Object Classes ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''capability''' - Used to manage the Linux capabilities granted to root processes. Taken from the header file: <br />
<br />
/usr/include/linux/capability.h<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (32 unique permissions)<br />
<br />
|-<br />
| audit_control<br />
| Change auditing rules. Set login UID.<br />
<br />
|-<br />
| audit_write<br />
| Send audit messsages from user space.<br />
<br />
|-<br />
| chown<br />
| Allow changing file and group ownership.<br />
<br />
|-<br />
| dac_override<br />
| Overrides all DAC including ACL execute access.<br />
<br />
|-<br />
| dac_read_search<br />
| Overrides DAC for read and directory search.<br />
<br />
|-<br />
| fowner<br />
| Grant all file operations otherwise restricted due to different ownership except where FSETID capability is applicable. DAC and MAC accesses are not overridden.<br />
<br />
|-<br />
| fsetid<br />
| Overrides the restriction that the real or effective user ID of a process sending a signal must match the real or effective user ID of the process receiving the signal.<br />
<br />
|-<br />
| ipc_lock<br />
| Grants the capability to lock non-shared and shared memory segments.<br />
<br />
|-<br />
| ipc_owner<br />
| Grant the ability to ignore IPC ownership checks.<br />
<br />
|-<br />
| kill<br />
| Allow signal raising for any process.<br />
<br />
|-<br />
| lease<br />
| Grants ability to take leases on a file.<br />
<br />
|-<br />
| linux_immutable<br />
| Grant privilege to modify S_IMMUTABLE and S_APPEND file attributes on supporting filesystems.<br />
<br />
|-<br />
| mknod<br />
| Grants permission to creation of character and block device nodes.<br />
<br />
|-<br />
| net_admin<br />
| Allow the following: interface configuration; administration of IP firewall; masquerading and accounting; setting debug option on sockets; modification of routing tables; setting arbitrary process / group ownership on sockets; binding to any address for transparent proxying; setting TOS (type of service); setting promiscuous mode; clearing driver statistics; multicasting; read/write of device-specific registers; activation of ATM control sockets.<br />
<br />
|-<br />
| net_bind_service<br />
| <nowiki>Allow low port binding. Port < 1024 for TCP/UDP. VCI < 32 for ATM.</nowiki><br />
<br />
|-<br />
| net_raw<br />
| Allows opening of raw sockets and packet sockets.<br />
<br />
|-<br />
| netbroadcast<br />
| Grant network broadcasting and listening to incoming multicasts.<br />
<br />
|-<br />
| setfcap<br />
| Allow the assignment of file capabilities.<br />
<br />
|-<br />
| setgid<br />
| Allow setgid(2) allow setgroups(2) allow fake gids on credentials passed over a socket.<br />
<br />
|-<br />
| setpcap<br />
| Transfer capability maps from current process to any process.<br />
<br />
|-<br />
| setuid<br />
| Allow all setsuid(2) type calls including fsuid. Allow passing of forged pids on credentials passed over a socket.<br />
<br />
|-<br />
| sys_admin<br />
| Allow the following: configuration of the secure attention key; administration of the random device; examination and configuration of disk quotas; configuring the kernel's syslog; setting the domainname; setting the hostname; calling bdflush()<nowiki>; </nowiki>mount() and umount(), setting up new smb connection; some autofs root ioctls; nfsservctl; VM86_REQUEST_IRQ; to read/write pci config on alpha; irix_prctl on mips (setstacksize); flushing all cache on m68k (sys_cacheflush); removing semaphores; locking/unlocking of shared memory segment; turning swap on/off; forged pids on socket credentials passing; setting readahead and flushing buffers on block devices; setting geometry in floppy driver; turning DMA on/off in xd driver; administration of md devices; tuning the ide driver; access to the nvram device; administration of apm_bios, serial and bttv (TV) device; manufacturer commands in isdn CAPI support driver; reading non-standardized portions of pci configuration space; DDI debug ioctl on sbpcd driver; setting up serial ports; sending raw qic-117 commands; enabling/disabling tagged queuing on SCSI controllers and sending arbitrary SCSI commands; setting encryption key on loopback filesystem; setting zone reclaim policy.<br />
<br />
|-<br />
| sys_boot<br />
| Grant ability to reboot the system.<br />
<br />
|-<br />
| sys_chroot<br />
| Grant use of the '''chroot'''(2) call.<br />
<br />
|-<br />
| sys_module<br />
| Allow unrestricted kernel modification including but not limited to loading and removing kernel modules. Allows modification of kernel's bounding capability mask. See sysctl. <br />
<br />
|-<br />
| sys_nice<br />
| Grants privilage to change priority of any process. Grants change of scheduling algorithm used by any process.<br />
<br />
|-<br />
| sys_pacct<br />
| Allow modification of accounting for any process.<br />
<br />
|-<br />
| sys_ptrace<br />
| Allow ptrace of any process.<br />
<br />
|-<br />
| sys_rawio<br />
| Grant permission to use '''ioperm'''(2) and '''iopl'''(2) as well as the ability to send messages to USB devices via /proc/bus/usb.<br />
<br />
|-<br />
| sys_resource<br />
| Override the following: resource limits; quota limits; reserved space on ext2 filesystem; size restrictions on IPC message queues; max number of consoles on console allocation; max number of keymaps.<br />
<br />
Set resource limits.<br />
<br />
Modify data journaling mode on ext3 filesystem, <br />
<br />
Allow more than 64hz interrupts from the real-time clock.<br />
<br />
|-<br />
| sys_time<br />
| Grant permission to set system time and to set the real-time lock.<br />
<br />
|-<br />
| sys_tty_config<br />
| Grant permission to configure tty devices.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''capability2'''<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (7 unique permissions)<br />
<br />
|-<br />
| block_suspend<br />
| Prevent system suspends (was <tt>epollwakeup</tt>)<br />
<br />
|-<br />
| compromise_kernel<br />
| Allow tasks that can modify the running kernel (Secure Boot).<br />
<br />
|-<br />
| mac_admin<br />
| Allow MAC configuration state changes. For SELinux allow contexts not defined in the policy to be assigned. This is called 'deferred mapping of security contexts' and is explained at:<br />
<br />
[http://www.nsa.gov/research/selinux/list-archive/0805/26046.shtml http://www.nsa.gov/research/selinux/list-archive/0805/26046.shtml]<br />
<br />
|-<br />
| mac_override<br />
| Allow MAC policy to be overridden.<br />
<br />
|-<br />
| syslog<br />
| Allow configuration of kernel <tt>syslog</tt> (<tt>printk</tt> behaviour).<br />
<br />
|-<br />
| wake_alarm<br />
| Trigger the system to wake up<br />
<br />
|}<br />
<br />
<br />
== X Windows Object Classes ==<br />
These are userspace objects managed by XSELinux.<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_drawable''' - The drawable parameter specifies the area into which the text will be drawn. It may be either a pixmap or a window.<br />
<br />
Some of the permission information has been extracted from an [http://marc.info/?l=selinux&m=121485496531386&q=raw email] describing them in terms of an MLS system.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (19 unique permissions)<br />
<br />
|-<br />
| add_child<br />
| Add new window. Normally SystemLow for MLS systems.<br />
<br />
|-<br />
| blend<br />
| There are two cases: 1) Allow a non-root window to have a transparent background. 2) The application is redirecting the contents of the window and its sub-windows into a memory buffer when using the Composite extension. Only <tt>SystemHigh</tt> processes should have the blend permission on the root window.<br />
<br />
|-<br />
| create<br />
| Create a drawable object. Not applicable to the root windows as it cannot be created.<br />
<br />
|-<br />
| destroy<br />
| Destroy a drawable object. Not applicable to the root windows as it cannot be destroyed.<br />
<br />
|-<br />
| get_property<br />
| Read property information. Normally <tt>SystemLow</tt> for MLS systems.<br />
<br />
|-<br />
| getattr<br />
| Get attributes from a drawable object. Most applications will need this so SystemLow.<br />
<br />
|-<br />
| hide<br />
| Hide a drawable object. Not applicable to the root windows as it cannot be hidden.<br />
<br />
|-<br />
| list_child<br />
| Allows all child window IDs to be returned. From the root window it will show the client that owns the window and their stacking order. If hiding this information is required then processes should be <tt>SystemHigh</tt>.<br />
<br />
|-<br />
| list_property<br />
| List property associated with a window. Normally SystemLow for MLS systems.<br />
<br />
|-<br />
| manage<br />
| Required to create a context, move and resize windows. Not applicable to the root windows as it cannot be resized etc.<br />
<br />
|-<br />
| override<br />
| Allow setting the <tt>override-redirect</tt> bit on the window. Not applicable to the root windows as it cannot be overridden.<br />
<br />
|-<br />
| read<br />
| Read window contents. Note that this will also give read permission to all child windows, therefore (for MLS), only <tt>SystemHigh</tt> processes should have read permission on the root window.<br />
<br />
|-<br />
| receive<br />
| Allow receiving of events. Normally <tt>SystemLow</tt> for MLS systems (but could leak information between clients running at different levels, therefore needs investigation).<br />
<br />
|-<br />
| remove_child<br />
| Remove child window. Normally <tt>SystemLow</tt> for MLS systems.<br />
<br />
|-<br />
| send<br />
| Allow sending of events. Normally <tt>SystemLow</tt> for MLS systems (but could leak information between clients running at different levels, therefore needs investigation).<br />
<br />
|-<br />
| set_property<br />
| Set property. Normally SystemLow for MLS systems (but could leak information between clients running at different levels, therefore needs investigation. Polyinstantiation may be required).<br />
<br />
|-<br />
| setattr<br />
| Allow window attributes to be set. This permission protects operations on the root window such as setting the background image or colour, setting the colormap and setting the mouse cursor to display when the cursor is in nthe window, therefore only <tt>SystemHigh</tt> processes should have the <tt>setattr</tt> permission.<br />
<br />
|-<br />
| show<br />
| Show window. Not applicable to the root windows as it cannot be hidden.<br />
<br />
|-<br />
| write<br />
| Draw within a window. Note that this will also give write permission to all child windows, therefore (for MLS), only <tt>SystemHigh</tt> processes should have <tt>write</tt> permission on the root window.<br />
<br />
|}<br />
<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_screen -''' The specific screen available to the display (X-server) <tt>(hostname:display_number.screen</tt>)<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (8 unique permissions)<br />
<br />
|-<br />
| getattr<br />
| <br />
<br />
|-<br />
| hide_cursor<br />
| <br />
<br />
|-<br />
| saver_getattr<br />
| <br />
<br />
|-<br />
| saver_hide<br />
| <br />
<br />
|-<br />
| saver_setattr<br />
| <br />
<br />
|-<br />
| saver_show<br />
| <br />
<br />
|-<br />
| setattr<br />
| <br />
<br />
|-<br />
| show_cursor<br />
| <br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_gc - '''The graphics contexts allows the X-server to cache information about how graphics requests should be interpreted. It reduces the network traffic.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (5 unique permissions)<br />
<br />
|-<br />
| create<br />
| Create Graphic Contexts object.<br />
<br />
|-<br />
| destroy<br />
| Free (dereference) a Graphics Contexts object.<br />
<br />
|-<br />
| getattr<br />
| Get attributes from Graphic Contexts object.<br />
<br />
|-<br />
| setattr<br />
| Set attributes for Graphic Contexts object.<br />
<br />
|-<br />
| use<br />
| Allow GC contexts to be used.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_font - '''An X-server resource for managing the different fonts.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (6 unique permissions)<br />
<br />
|-<br />
| add_glyph<br />
| Create glyph for cursor<br />
<br />
|-<br />
| create<br />
| Load a font.<br />
<br />
|-<br />
| destroy<br />
| Free a font.<br />
<br />
|-<br />
| getattr<br />
| Obtain font names, path, etc.<br />
<br />
|-<br />
| remove_glyph<br />
| Free glyph<br />
<br />
|-<br />
| use<br />
| Use a font.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_colormap - '''An X-server resource for managing colour mapping. A new colormap can be created using <tt>XCreateColormap</tt>.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (10 unique permissions)<br />
<br />
|-<br />
| add_color<br />
| Add a colour<br />
<br />
|-<br />
| create<br />
| Create a new Colormap.<br />
<br />
|-<br />
| destroy<br />
| Free a Colormap.<br />
<br />
|-<br />
| getattr<br />
| Get the color gamut of a screen.<br />
<br />
|-<br />
| install<br />
| Copy a virtual colormap into the display hardware.<br />
<br />
|-<br />
| read<br />
| Read color cells of colormap.<br />
<br />
|-<br />
| remove_color<br />
| Remove a colour<br />
<br />
|-<br />
| uninstall<br />
| Remove a virtual colormap from the display hardware.<br />
<br />
|-<br />
| use<br />
| Use a colormap<br />
<br />
|-<br />
| write<br />
| Change color cells in colormap.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_property - '''An InterClient Communications (ICC) service where each property has a name and ID (or Atom). Properties are attached to windows and can be uniquely identified by the <tt>windowID</tt> and <tt>propertyID</tt>. XSELinux supports polyinstantiation of properties.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (7 unique permissions)<br />
<br />
|-<br />
| append<br />
| Append a property.<br />
<br />
|-<br />
| create<br />
| Create property object.<br />
<br />
|-<br />
| destroy<br />
| Free (dereference) a property object.<br />
<br />
|-<br />
| getattr<br />
| Get attributes of a property.<br />
<br />
|-<br />
| read<br />
| Read a property.<br />
<br />
|-<br />
| setattr<br />
| Set attributes of a property.<br />
<br />
|-<br />
| write<br />
| Write a property.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_selection - '''An InterClient Communications (ICC) service that allows two parties to communicate about passing information. The information uses properties to define the the format (e.g. whether text or graphics). XSELinux supports polyinstantiation of selections.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (4 unique permissions)<br />
<br />
|-<br />
| getattr<br />
| Get selection owner (<tt>XGetSelectionOwner</tt>).<br />
<br />
|-<br />
| read<br />
| Read the information from the selection owner<br />
<br />
|-<br />
| setattr<br />
| Set the selection owner (<tt>XSetSelectionOwner</tt>).<br />
<br />
|-<br />
| write<br />
| Send the information to the selection requestor.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_cursor -''' The cursor on the screen<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (7 unique permissions)<br />
<br />
|-<br />
| create<br />
| Create an arbitrary cursor object.<br />
<br />
|-<br />
| destroy<br />
| Free (dereference) a cursor object.<br />
<br />
|-<br />
| getattr<br />
| Get attributes of the cursor.<br />
<br />
|-<br />
| read<br />
| Read the cursor.<br />
<br />
|-<br />
| setattr<br />
| Set attributes of the cursor.<br />
<br />
|-<br />
| use<br />
| Associate a cursor object with a window.<br />
<br />
|-<br />
| write<br />
| Write a cursor<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_client - '''The X-client connecting to the X-server.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (4 unique permissions)<br />
<br />
|-<br />
| destroy<br />
| Close down a client.<br />
<br />
|-<br />
| getattr<br />
| Get attributes of X-client.<br />
<br />
|-<br />
| manage<br />
| Required to create an X-client context. (source code)<br />
<br />
|-<br />
| setattr<br />
| Set attributes of X-client.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| <tt>'''x_device'''</tt> - These are any other devices used by the X-server as the keyboard and pointer devices have their own object classes.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 19 common <tt>x_device</tt> permissions)<br />
<br />
|-<br />
| [[#Common X_Device Permissions | Inherit Common X_Device Permissions]]<br />
| add, bell, create, destroy, force_cursor, freeze, get_property, getattr, getfocus, grab, list_property, manage, read, remove, set_property, setattr, setfocus, use, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_server - '''The X-server that manages the display, keyboard and pointer.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (6 unique permissions)<br />
<br />
|-<br />
| debug<br />
| <br />
<br />
|-<br />
| getattr<br />
| <br />
<br />
|-<br />
| grab<br />
| <br />
<br />
|-<br />
| manage<br />
| Required to create a context. (source code)<br />
<br />
|-<br />
| record<br />
| <br />
<br />
|-<br />
| setattr<br />
| <br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_extension -''' An X-Windows extension that can be added to the X-server (such as the XSELinux object manager itself).<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| query<br />
| Query for an extension.<br />
<br />
|-<br />
| use<br />
| Use the extensions services.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_resource - '''These consist of Windows, Pixmaps, Fonts, Colormaps etc. that are classed as resources.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| read<br />
| Allow reading a resource.<br />
<br />
|-<br />
| write<br />
| Allow writing to a resource.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_event -''' Manage X-server events.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| receive<br />
| Receive an event<br />
<br />
|-<br />
| send<br />
| Send an event<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_synthetic_event -''' Manage some X-server events (e.g. <tt>confignotify</tt>). Note the <tt>x_event</tt> permissions will still be required (its magic).<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| receive<br />
| Receive an event<br />
<br />
|-<br />
| send<br />
| Send an event<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''x_application_data -''' Not specifically used by XSELinux, however is used by userspace applications that need to manage copy and paste services (such as the <tt>CUT_BUFFER</tt>s).<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (3 unique permissions)<br />
<br />
|-<br />
| copy<br />
| Copy the data<br />
<br />
|-<br />
| paste<br />
| Paste the data<br />
<br />
|-<br />
| paste_after_confirm<br />
| Need to confirm that the paste is allowed.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| <tt>'''x_pointer'''</tt> - The mouse or other pointing device managed by the X-server.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 19 common <tt>x_device</tt> permissions)<br />
<br />
|-<br />
| [[#Common X_Device Permissions | Inherit Common X_Device Permissions]]<br />
| add, bell, create, destroy, force_cursor, freeze, get_property, getattr, getfocus, grab, list_property, manage, read, remove, set_property, setattr, setfocus, use, write<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| <tt>'''x_keyboard'''</tt> - The keyboard managed by the X-server.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description '''(Inherit 19 common <tt>x_device</tt> permissions)<br />
<br />
|-<br />
| [[#Common X_Device Permissions | Inherit Common X_Device Permissions]]<br />
| add, bell, create, destroy, force_cursor, freeze, get_property, getattr, getfocus, grab, list_property, manage, read, remove, set_property, setattr, setfocus, use, write<br />
<br />
|}<br />
<br />
<br />
== Database Object Classes ==<br />
These are userspace objects - The PostgreSQL database supports these with their SE- PostgreSQL database extension. The "[http://wiki.postgresql.org/wiki/SEPostgreSQL_Development Security-Enhanced PostgreSQL Security Wiki]<nowiki>" [2] explains the objects, their permissions and how they should be used in detail.</nowiki><br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_database'''<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| access<br />
| Required to connect to the database - this is the minimum permission required by an SE-PostgreSQL client.<br />
<br />
|-<br />
| install_module<br />
| Required to install a dynmic link library.<br />
<br />
|-<br />
| load_module<br />
| Required to load a dynmic link library.<br />
<br />
|}<br />
<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_table'''<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 5 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| delete<br />
| Required to delete from a table with a DELETE statement, or when removing the table contents with a TRUNCATE statement.<br />
<br />
|-<br />
| insert<br />
| Required to insert into a table with an INSERT statement, or when restoring it with a COPY FROM statement.<br />
<br />
|-<br />
| lock<br />
| Required to get a table lock with a LOCK statement.<br />
<br />
|-<br />
| select<br />
| Required to refer to a table with a SELECT statement or to dump the table contents with a COPY TO statement.<br />
<br />
|-<br />
| update<br />
| Required to update a table with an UPDATE statement.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_schema'''<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| search<br />
| Search for an object in the schema.<br />
<br />
|-<br />
| add_name<br />
| Add an object to the schema.<br />
<br />
|-<br />
| remove_name<br />
| Remove an object from the schema.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_procedure'''<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| entrypoint<br />
| Required for any functions defined as Trusted Procedures.<br />
<br />
|-<br />
| execute<br />
| Required for functions executed with SQL queries.<br />
<br />
|-<br />
| install<br />
| <br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_column'''<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| insert<br />
| Required to insert a new entry using the INSERT statement.<br />
<br />
|-<br />
| select<br />
| Required to reference columns.<br />
<br />
|-<br />
| update<br />
| Required to update a table with an UPDATE statement.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_tuple'''<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (7 unique)<br />
<br />
|-<br />
| delete<br />
| Required to delete entries with a DELETE or TRUNCATE statement.<br />
<br />
|-<br />
| insert<br />
| Required when inserting a entry with an INSERT statement, or restoring tables with a COPY FROM statement.<br />
<br />
|-<br />
| relabelfrom<br />
| The security context of an entry can be changed with an UPDATE to the security_context column at which time relabelfrom and relabelto permission is evaluated. The client must have relabelfrom permission to the security context before the entry is changed, and relabelto permission to the security context after the entry is changed.<br />
<br />
|-<br />
| relabelto<br />
<br />
|-<br />
| select<br />
| Required when: reading entries with a SELECT statement, returning entries that are subjects for updating queries with a RETURNING clause, or dumping tables with a COPY TO statement.<br />
<br />
Entries that the client does not have select permission on will be filtered from the result set.<br />
<br />
|-<br />
| update<br />
| Required when updating an entry with an UPDATE statement. Entries that the client does not have update permission on will not be updated.<br />
<br />
|-<br />
| use<br />
| Controls usage of system objects that require permission to "use" objects such as data types, tablespaces and operators.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_blob'''<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 4 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| export<br />
| Export a binary large object by calling the lo_export() function.<br />
<br />
|-<br />
| import<br />
| Import a file as a binary large object by calling the lo_import() function.<br />
<br />
|-<br />
| read<br />
| Read a binary large object the loread() function.<br />
<br />
|-<br />
| write<br />
| Write a binary large objecty with the lowrite() function. <br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_view'''<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 1 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| expand<br />
| Allows the expansion of a 'view'.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_sequence - '''A sequential number generator<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 3 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| get_value<br />
| Get a value from the sequence generator object.<br />
<br />
|-<br />
| next_value<br />
| Get and increment value.<br />
<br />
|-<br />
| set_value<br />
| Set an arbitrary value.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''db_language''' - Support for script languages such as Perl and Tcl for SQL Procedures<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (Inherit 6 common database permissions + 2 unique)<br />
<br />
|-<br />
| [[#Common_Database_Permissions | Inherit Common Database Permissions]]<br />
| create, drop, getattr, relabelfrom, relabelto, setattr<br />
<br />
|-<br />
| implement<br />
| Whether the language can be implemented or not for the SQL procedure.<br />
<br />
|-<br />
| execute<br />
| Allow the execution of a code block using a '<tt>DO</tt>' statement.<br />
<br />
|}<br />
<br />
<br />
== Miscellaneous Object Classes ==<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''passwd - '''This is a userspace object for controlling changes to passwd information.<br />
<br />
|-<br />
| '''Permissions'''<br />
| '''Description''' (5 unique permissions)<br />
<br />
|-<br />
| chfn<br />
| Change another users finger info.<br />
<br />
|-<br />
| chsh<br />
| Change another users shell.<br />
<br />
|-<br />
| crontab<br />
| crontab another user.<br />
<br />
|-<br />
| passwd<br />
| Change another users passwd.<br />
<br />
|-<br />
| rootok<br />
| pam_rootok check - skip authentication.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''nscd - '''This is a userspace object for the Name Service Cache Daemon.<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (12 unique permissions)<br />
<br />
|-<br />
| admin<br />
| Allow the nscd daemon to be shut down.<br />
<br />
|-<br />
| getgrp<br />
| Get group information.<br />
<br />
|-<br />
| gethost<br />
| Get host information.<br />
<br />
|-<br />
| getnetgrp<br />
| <br />
<br />
|-<br />
| getpwd<br />
| Get password information.<br />
<br />
|-<br />
| getserv<br />
| Get ?? information.<br />
<br />
|-<br />
| getstat<br />
| Get the AVC stats from the nscd daemon.<br />
<br />
|-<br />
| shmemgrp<br />
| Get shmem group file descriptor.<br />
<br />
|-<br />
| shmemhost<br />
| Get shmem host descriptor. ??<br />
<br />
|-<br />
| shmemnetgrp<br />
| <br />
<br />
|-<br />
| shmempwd<br />
| <br />
<br />
|-<br />
| shmemserv<br />
| <br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''dbus - '''This is a userspace object for the D-BUS Messaging service that is required to run various services.<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| acquire_svc<br />
| Open a virtual circuit (communications channel).<br />
<br />
|-<br />
| send_msg<br />
| Send a message.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''context''' - This is a userspace object for the translation daemon mcstransd. These permissions are required to allow translation and querying of level and ranges for MCS and MLS systems.<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (2 unique permissions)<br />
<br />
|-<br />
| contains<br />
| Calculate a MLS/MCS subset - Required to check what the configuration file contains.<br />
<br />
|-<br />
| translate<br />
| Translate a raw MLS/MCS label - Required to allow a domain to translate contexts.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''key''' - This is a kernel object to manage Keyrings.<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (7 unique permissions)<br />
<br />
|-<br />
| create<br />
| Create a keyring.<br />
<br />
|-<br />
| link<br />
| Link a key into the keyring.<br />
<br />
|-<br />
| read<br />
| Read a keyring.<br />
<br />
|-<br />
| search<br />
| Search a keyring.<br />
<br />
|-<br />
| setattr<br />
| Change permissions on a keyring.<br />
<br />
|-<br />
| view<br />
| View a keyring.<br />
<br />
|-<br />
| write<br />
| Add a key to the keyring.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''memprotect - '''This is a kernel object to protect lower memory blocks.<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (1 unique permission)<br />
<br />
|-<br />
| mmap_zero<br />
| Security check on mmap operations to see if the user is attempting to mmap to low area of the address space. The amount of space protected is indicated by a proc tunable (<tt>/proc/sys/vm/mmap_min_addr</tt>). Setting this value to 0 will disable the checks. The "[http://eparis.livejournal.com/891.html SELinux hardening for mmap_min_addr protections]<nowiki>" describes additional checks that will be added to the kernel to protect against some kernel exploits (by requiring </nowiki><tt>CAP_SYS_RAWIO</tt> (root) and the SELinux <tt>memprotect</tt> / <tt>mmap_zero</tt> permission instead of only one or the other).<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''service''' - This is a userspace object to manage <tt>systemd</tt> services.<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (8 unique permissions)<br />
<br />
|-<br />
| disable<br />
| Disable services.<br />
<br />
|-<br />
| enable<br />
| Enable services.<br />
<br />
|-<br />
| kill<br />
| Kill services.<br />
<br />
|-<br />
| load<br />
| Load services<br />
<br />
|-<br />
| reload<br />
| Restart systemd services.<br />
<br />
|-<br />
| start<br />
| Start systemd services.<br />
<br />
|-<br />
| status<br />
| Read service status.<br />
<br />
|-<br />
| stop<br />
| Stop systemd services.<br />
<br />
|}<br />
<br />
<br />
<br />
{| border="1"<br />
| '''Class'''<br />
| '''proxy''' - This is a userspace object for <tt>gssd</tt> services.<br />
<br />
|-<br />
| '''Permission'''<br />
| '''Description''' (1 unique permission)<br />
<br />
|-<br />
| read<br />
| Read credentials.<br />
<br />
|}<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[LibselinuxAPISummary | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_Overview | '''Next''']]</center><br />
|}<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaineshttp://selinuxproject.org/page/LibselinuxAPISummaryLibselinuxAPISummary2015-02-03T15:27:09Z<p>RichardHaines: </p>
<hr />
<div>= libselinux 2.3 Library Functions =<br />
These functions have been taken from the following header files of <tt>libselinux</tt> version 2.3:<br />
<br />
: /usr/include/selinux/avc.h<br />
: /usr/include/selinux/context.h<br />
: /usr/include/selinux/get_context_list.h<br />
: /usr/include/selinux/get_default_type.h<br />
: /usr/include/selinux/label.h<br />
: /usr/include/selinux/selinux.h<br />
<br />
The appropriate '''man'''(3) pages should consulted for detailed usage.<br />
<br />
<br />
{| border="1"<br />
! Function Name<br />
! Description<br />
! Header File<br />
<br />
|-<br />
| avc_add_callback<br />
| Register a callback for security events.<br />
| avc.h<br />
<br />
|-<br />
| avc_audit<br />
| Audit the granting or denial of permissions in accordance with the policy. This function is typically called by '''avc_has_perm'''(3) after a permission check, but can also be called directly by callers who use '''avc_has_perm_noaudit'''(3) in order to separate the permission check from the auditing. For example, this separation is useful when the permission check must be performed under a lock, to allow the lock to be released before calling the auditing code.<br />
| avc.h<br />
<br />
|-<br />
| avc_av_stats<br />
| Log AV table statistics. Logs a message with information about the size and distribution of the access vector table. The audit callback is used to print the message.<br />
| avc.h<br />
<br />
|-<br />
| avc_cache_stats<br />
| Get cache access statistics. Fill the supplied structure with information about AVC activity since the last call to '''avc_init'''(3) or '''avc_reset'''(3).<br />
| avc.h<br />
<br />
|-<br />
| avc_cleanup<br />
| Remove unused SIDs and AVC entries.<br />
<br />
Search the SID table for SID structures with zero reference counts, and remove them along with all AVC entries that reference them. This can be used to return memory to the system.<br />
| avc.h<br />
<br />
|-<br />
| avc_compute_create<br />
| Compute SID for labeling a new object. Call the security server to obtain a context for labeling a new object. Look up the context in the SID table, making a new entry if not found.<br />
| avc.h<br />
<br />
|-<br />
| avc_compute_member<br />
| Compute SID for polyinstantation.<br />
<br />
Call the security server to obtain a context for labeling an object instance. Look up the context in the SID table, making a new entry if not found.<br />
| avc.h<br />
<br />
|-<br />
| avc_context_to_sid<br />
<br />
avc_context_to_sid_raw<br />
| Get SID for context. Look up security context <tt>ctx</tt> in SID table, making a new entry if <tt>ctx</tt> is not found. Store a pointer to the SID structure into the memory referenced by <tt>sid</tt>, returning 0 on success or -1 on error with <tt>errno</tt> set.<br />
| avc.h<br />
<br />
|-<br />
| avc_destroy<br />
| Free all AVC structures.<br />
<br />
Destroy all AVC structures and free all allocated memory. User-supplied locking, memory, and audit callbacks will be retained, but security-event callbacks will not. All SID's will be invalidated. User must call '''avc_init'''(3) if further use of AVC is desired.<br />
| avc.h<br />
<br />
|-<br />
| avc_entry_ref_init<br />
| Initialize an AVC entry reference.<br />
<br />
Use this macro to initialize an avc entry reference structure before first use. These structures are passed to '''avc_has_perm'''(3), which stores cache entry references in them. They can increase performance on repeated queries.<br />
| avc.h<br />
<br />
|-<br />
| avc_get_initial_sid<br />
| Get SID for an initial kernel security identifier.<br />
<br />
Get the context for an initial kernel security identifier specified by name using '''security_get_initial_context'''(3) and then call '''avc_context_to_sid'''(3) to get the corresponding SID.<br />
| avc.h<br />
<br />
|-<br />
| avc_has_perm<br />
| Check permissions and perform any appropriate auditing.<br />
<br />
Check the AVC to determine whether the requested permissions are granted for the SID pair (ssid, tsid), interpreting the permissions based on tclass, and call the security server on a cache miss to obtain a new decision and add it to the cache. Update aeref to refer to an AVC entry with the resulting decisions. Audit the granting or denial of permissions in accordance with the policy. Return 0 if all requested permissions are granted, -1 with errno set to EACCES if any permissions are denied or to another value upon other errors.<br />
| avc.h<br />
<br />
|-<br />
| avc_has_perm_noaudit<br />
| Check permissions but perform no auditing. Check the AVC to determine whether the requested permissions are granted for the SID pair (ssid, tsid), interpreting the permissions based on tclass, and call the security server on a cache miss to obtain a new decision and add it to the cache. Update aeref to refer to an AVC entry with the resulting decisions, and return a copy of the decisions in avd. Return 0 if all requested permissions are granted, -1 with errno set to EACCES if any permissions are denied, or to another value upon other errors. This function is typically called by '''avc_has_perm'''(3), but may also be called directly to separate permission checking from auditing, e.g. in cases where a lock must be held for the check but should be released for the auditing.<br />
| avc.h<br />
<br />
|-<br />
| avc_init (deprecated)<br />
| Use <tt>avc_open</tt><br />
<br />
Initialize the AVC. Initialize the access vector cache. Return 0 on success or -1 with errno set on failure. If msgprefix is NULL, use "uavc". If any callback structure references are NULL, use default methods for those callbacks (see the definition of the callback structures).<br />
| avc.h<br />
<br />
|-<br />
| avc_netlink_acquire_fd<br />
| Create a netlink socket and connect to the kernel.<br />
| avc.h<br />
<br />
|-<br />
<br />
| avc_netlink_check_nb<br />
| Wait for netlink messages from the kernel.<br />
| avc.h<br />
<br />
|-<br />
<br />
| avc_netlink_close<br />
| Close the netlink socket.<br />
| avc.h<br />
<br />
|-<br />
<br />
| avc_netlink_loop<br />
| Acquire netlink socket fd. Allows the application to manage messages from the netlink socket in its own main loop.<br />
| avc.h<br />
<br />
|-<br />
<br />
| avc_netlink_open<br />
| Release netlink socket fd. Returns ownership of the netlink socket to the library.<br />
| avc.h<br />
<br />
|-<br />
<br />
| avc_netlink_release_fd<br />
| Check netlink socket for new messages. Called by the application when using <tt>'''avc_netlink_acquire_fd'''(3)</tt> to process kernel netlink events.<br />
| avc.h<br />
<br />
|-<br />
<br />
| avc_open<br />
| Initialize the AVC. This function is identical to '''avc_init'''(3) except the message prefix is set to "avc" and any callbacks desired should be specified via '''selinux_set_callback'''(3).<br />
| avc.h<br />
<br />
|-<br />
| avc_reset<br />
| Flush the cache and reset statistics. Remove all entries from the cache and reset all access statistics (as returned by '''avc_cache_stats'''(3)) to zero. The SID mapping is not affected. Return 0 on success, -1 with errno set on error.<br />
| avc.h<br />
<br />
|-<br />
| avc_sid_stats<br />
| Log SID table statistics. Log a message with information about the size and distribution of the SID table. The audit callback is used to print the message.<br />
| avc.h<br />
<br />
|-<br />
| avc_sid_to_context<br />
<br />
avc_sid_to_context_raw<br />
| Get copy of context corresponding to SID. Return a copy of the security context corresponding to the input sid in the memory referenced by ctx. The caller is expected to free the context with '''freecon'''(3). Return 0 on success, -1 on failure, with errno set to ENOMEM if insufficient memory was available to make the copy, or EINVAL if the input SID is invalid.<br />
| avc.h<br />
<br />
|-<br />
| checkPasswdAccess (deprecated)<br />
| Use <tt>'''selinux_check_passwd_access'''(3)</tt> or preferably <tt>'''selinux_check_access'''(3)</tt><br />
<br />
Check a permission in the passwd class. Return 0 if granted or -1 otherwise.<br />
| selinux.h<br />
<br />
|-<br />
| context_free<br />
| Free the storage used by a context.<br />
| context.h<br />
<br />
|-<br />
| context_new<br />
| Return a new context initialized to a context string.<br />
| context.h<br />
<br />
|-<br />
| context_range_get<br />
| Get a pointer to the range.<br />
| context.h<br />
<br />
|-<br />
| context_range_set<br />
| Set the range component. Returns nonzero if unsuccessful.<br />
| context.h<br />
<br />
|-<br />
| context_role_get<br />
| Get a pointer to the role.<br />
| context.h<br />
<br />
|-<br />
| context_role_set<br />
| Set the role component. Returns nonzero if unsuccessful.<br />
| context.h<br />
<br />
|-<br />
| context_str<br />
| Return a pointer to the string value of context_t. Valid until the next call to context_str or context_free for the same context_t*.<br />
| context.h<br />
<br />
|-<br />
| context_type_get<br />
| Get a pointer to the type.<br />
| context.h<br />
<br />
|-<br />
| context_type_set<br />
| Set the type component. Returns nonzero if unsuccessful.<br />
| context.h<br />
<br />
|-<br />
| context_user_get<br />
| Get a pointer to the user.<br />
| context.h<br />
<br />
|-<br />
| context_user_set<br />
| Set the user component. Returns nonzero if unsuccessful.<br />
| context.h<br />
<br />
|-<br />
| fgetfilecon<br />
<br />
fgetfilecon_raw<br />
| Wrapper for the xattr API - Get file context, and set <nowiki>*con</nowiki> to refer to it. Caller must free via freecon.<br />
| selinux.h<br />
<br />
|-<br />
| fini_selinuxmnt<br />
| Clear <tt>selinuxmnt</tt> variable and free allocated memory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
| freecon<br />
| Free the memory allocated for a context by any of the get* calls.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| freeconary<br />
| Free the memory allocated for a context array by '''security_compute_user'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| fsetfilecon<br />
<br />
fsetfilecon_raw<br />
| Wrapper for the xattr API - Set file context.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| get_default_context<br />
| Get the default security context for a user session for 'user' spawned by 'fromcon' and set <nowiki>*newcon</nowiki> to refer to it. The context will be one of those authorized by the policy, but the selection of a default is subject to user customizable preferences. If 'fromcon' is NULL, defaults to current context. Returns 0 on success or -1 otherwise. Caller must free via freecon. <br />
| get_context_list.h<br />
<br />
|-<br />
<br />
<br />
<br />
| get_default_context_with_level<br />
| Same as '''get_default_context'''(3), but use the provided MLS level rather than the default level for the user. <br />
| get_context_list.h<br />
<br />
|-<br />
<br />
<br />
<br />
| get_default_context_with_role<br />
| Same as '''get_default_context'''(3), but only return a context that has the specified role.<br />
| get_context_list.h<br />
<br />
|-<br />
<br />
<br />
<br />
| get_default_context_with_rolelevel<br />
| Same as '''get_default_context'''(3), but only return a context that has the specified role and level.<br />
| get_context_list.h<br />
<br />
|-<br />
<br />
<br />
<br />
| get_default_type<br />
| Get the default type (domain) for 'role' and set 'type' to refer to it. Caller must free via '''free'''(3). Return 0 on success or -1 otherwise. <br />
| get_default_type.h<br />
<br />
|-<br />
<br />
<br />
<br />
| get_ordered_context_list<br />
| Get an ordered list of authorized security contexts for a user session for 'user' spawned by 'fromcon' and set <nowiki>*conary</nowiki> to refer to the NULL-terminated array of contexts. Every entry in the list will be authorized by the policy, but the ordering is subject to user customizable preferences. Returns number of entries in <nowiki>*conary</nowiki>. If 'fromcon' is NULL, defaults to current context. Caller must free via '''freeconary'''(3).<br />
| get_context_list.h<br />
<br />
|-<br />
<br />
<br />
<br />
| get_ordered_context_list_with_level<br />
| Same as '''get_ordered_context_list'''(3), but use the provided MLS level rather than the default level for the user.<br />
| get_context_list.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getcon<br />
<br />
getcon_raw<br />
| Get current context, and set <nowiki>*con</nowiki> to refer to it. Caller must free via '''freecon'''(3). <br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getexeccon<br />
<br />
getexeccon_raw<br />
| Get exec context, and set <nowiki>*con</nowiki> to refer to it. Sets <nowiki>*con</nowiki> to NULL if no exec context has been set, i.e. using default. If non-NULL, caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getfilecon<br />
<br />
getfilecon_raw<br />
| Wrapper for the xattr API - Get file context, and set <nowiki>*con</nowiki> to refer to it. Caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getfscreatecon<br />
<br />
getfscreatecon_raw<br />
| Get fscreate context, and set <nowiki>*con</nowiki> to refer to it. Sets <nowiki>*con</nowiki> to NULL if no fs create context has been set, i.e. using default.If non-NULL, caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getkeycreatecon<br />
<br />
getkeycreatecon_raw<br />
| Get keycreate context, and set <nowiki>*con</nowiki> to refer to it. Sets <nowiki>*con</nowiki> to NULL if no key create context has been set, i.e. using default. If non-NULL, caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getpeercon<br />
<br />
getpeercon_raw<br />
| Wrapper for the socket API - Get context of peer socket, and set <nowiki>*con</nowiki> to refer to it. Caller must free via <tt>'''freecon'''(3)</tt>.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getpidcon<br />
<br />
getpidcon_raw<br />
| Get context of process identified by pid, and set <nowiki>*con</nowiki> to refer to it. Caller must free via <tt>'''freecon'''(3)</tt>.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getprevcon<br />
<br />
getprevcon_raw<br />
| Get previous context (prior to last exec), and set <nowiki>*con</nowiki> to refer to it. Caller must free via <tt>'''freecon'''</tt>(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getseuser<br />
| Get the SELinux username and level to use for a given Linux username and service. These values may then be passed into the get_ordered_context_list* and get_default_context* functions to obtain a context for the user. Returns 0 on success or -1 otherwise. Caller must free the returned strings via '''free'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getseuserbyname<br />
| Get the SELinux username and level to use for a given Linux username. These values may then be passed into the get_ordered_context_list* and get_default_context* functions to obtain a context for the user. Returns 0 on success or -1 otherwise. Caller must free the returned strings via '''free'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| getsockcreatecon<br />
<br />
getsockcreatecon_raw<br />
| Get sockcreate context, and set <nowiki>*con</nowiki> to refer to it. Sets <nowiki>*con</nowiki> to NULL if no socket create context has been set, i.e. using default. If non-NULL, caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| init_selinuxmnt<br />
| There is a man page for this, however it is not a user accessable function (internal use only - although the <tt>fini_selinuxmnt</tt> is reachable).<br />
| <center>-</center><br />
<br />
|-<br />
<br />
<br />
<br />
| is_context_customizable<br />
| Returns whether a file context is customizable, and should not be relabeled.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| is_selinux_enabled<br />
| Return 1 if running on a SELinux kernel, or 0 if not or -1 for error.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| is_selinux_mls_enabled<br />
| Return 1 if we are running on a SELinux MLS kernel, or 0 otherwise.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| lgetfilecon<br />
<br />
lgetfilecon_raw<br />
| Wrapper for the xattr API - Get file context, and set <nowiki>*con</nowiki> to refer to it. Caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| lsetfilecon<br />
<br />
lsetfilecon_raw<br />
| Wrapper for the xattr API- Set file context for symbolic link.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| manual_user_enter_context<br />
| Allow the user to manually enter a context as a fallback if a list of authorized contexts could not be obtained. Caller must free via '''freecon'''(3). Returns 0 on success or -1 otherwise. <br />
| get_context_list.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchmediacon<br />
| Match the specified media and against the media contexts configuration and set <nowiki>*con</nowiki> to refer to the resulting context. Caller must free con via freecon.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon<br />
| Match the specified pathname and mode against the file context sconfiguration and set <nowiki>*con</nowiki> to refer to the resulting context.'mode' can be 0 to disable mode matching. Caller must free via freecon. If '''matchpathcon_init'''(3) has not already been called, then this function will call it upon its first invocation with a NULL path.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon_checkmatches<br />
| Check to see whether any specifications had no matches and report them. The 'str' is used as a prefix for any warning messages.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon_filespec_add<br />
| Maintain an association between an inode and a specification index, and check whether a conflicting specification is already associated with the same inode (e.g. due to multiple hard links). If so, then use the latter of the two specifications based on their order in the file contexts configuration. Return the used specification index. <br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon_filespec_destroy<br />
| Destroy any inode associations that have been added, e.g. to restart for a new filesystem. <br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon_filespec_eval<br />
| Display statistics on the hash table usage for the associations.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon_fini<br />
| Free the memory allocated by matchpathcon_init.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon_index <br />
| Same as '''matchpathcon'''(3), but return a specification index for later use in a '''matchpathcon_filespec_add'''(3) call.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon_init<br />
| Load the file contexts configuration specified by 'path' into memory for use by subsequent matchpathcon calls. If 'path' is NULL, then load the active file contexts configuration, i.e. the path returned by '''selinux_file_context_path'''(3). Unless the MATCHPATHCON_BASEONLY flag has been set, this function also checks for a 'path'.homedirs file and a 'path'.local file and loads additional specifications from them if present.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| matchpathcon_init_prefix<br />
| Same as '''matchpathcon_init'''(3), but only load entries with regexes that have stems that are prefixes of 'prefix'.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| mode_to_security_class<br />
| Translate mode_t to a security class string name (e.g. <tt>S_ISREG</tt> = "<tt>file</tt>").<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| print_access_vector<br />
| Display an access vector in a string representation.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| query_user_context<br />
| Given a list of authorized security contexts for the user, query the user to select one and set <nowiki>*newcon</nowiki> to refer to it. Caller must free via '''freecon'''(3). Returns 0 on sucess or -1 otherwise. <br />
| get_context_list.h<br />
<br />
|-<br />
<br />
<br />
<br />
| realpath_not_final<br />
| Resolve all of the symlinks and relative portions of a pathname, but NOT the final component (same a <tt>'''realpath'''(3)</tt> unless the final component is a symlink. Resolved path must be a path of size <tt>PATH_MAX + 1</tt>.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| rpm_execcon<br />
| Execute a helper for rpm in an appropriate security context.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_av_perm_to_string<br />
| Convert access vector permissions to string names.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_av_string<br />
| Returns an access vector in a string representation. User must free the returned string via '''free'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_canonicalize_context<br />
<br />
security_canonicalize_context_raw<br />
| Canonicalize a security context. Returns a pointer to the canonical (primary) form of a security context in <tt>canoncon</tt> that the kernel is using rather than what is provided by the userspace application in <tt>con</tt>. <br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_check_context<br />
<br />
security_check_context_raw<br />
| Check the validity of a security context.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_class_to_string<br />
| Convert security class values to string names.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_commit_booleans<br />
| Commit the pending values for the booleans.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_compute_av<br />
<br />
security_compute_av_raw<br />
| Compute an access decision. <br />
<br />
Queries whether the policy permits the source context <tt>scon</tt> to access the target context <tt>tcon</tt> via class <tt>tclass</tt> with the <tt>requested</tt> access vector. The decision is returned in <tt>avd</tt>.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_compute_av_flags<br />
<br />
security_compute_av__flags_raw<br />
| Compute an access decision and return the flags. <br />
<br />
Queries whether the policy permits the source context <tt>scon</tt> to access the target context <tt>tcon</tt> via class <tt>tclass</tt> with the <tt>requested</tt> access vector. The decision is returned in <tt>avd</tt>. that has an additional <tt>'''flags'''</tt> entry. Currently the only flag defined is SELINUX_AVD_FLAGS_PERMISSIVE that indicates the decision was computed on a permissive domain (i.e. the <tt>'''permissive'''</tt> policy language statement has been used in policy or <tt>'''semanage'''(8)</tt> has been used to set the domain in permissive mode). Note this does not indicate that SELinux is running in permissive mode, only the <tt>scon</tt> domain.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_compute_create<br />
<br />
security_compute_create_raw<br />
| Compute a labeling decision and set <nowiki>*newcon</nowiki> to refer to it. Caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_compute_create_name<br />
<br />
security_compute_create_name_raw<br />
| This is identical to<tt> '''security_compute_create'''(3)</tt> but also takes the name of the new object in creation as an argument.<br />
<br />
When a [#5.7.6.type_transition |outline type_transition] </tt>rule on the given class and the <tt>scon</tt> / <tt>tcon</tt> pair has an object name extension, <tt>newcon</tt> will be returned according to the policy. Note that this interface is only supported on the kernels 2.6.40 or later. For older kernels the object name is ignored.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_compute_member<br />
<br />
security_compute_member_raw<br />
| Compute a polyinstantiation member decision and set <nowiki>*newcon</nowiki> to refer to it. Caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_compute_relabel<br />
<br />
security_compute_relabel_raw<br />
| Compute a relabeling decision and set <nowiki>*newcon</nowiki> to refer to it. Caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_compute_user<br />
<br />
security_compute_user_raw<br />
| Compute the set of reachable user contexts and set <nowiki>*con</nowiki> to refer to the NULL-terminated array of contexts. Caller must free via '''freeconary'''(3). <br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_deny_unknown<br />
| Get the behavior for undefined classes / permissions.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_disable<br />
| Disable SELinux at runtime (must be done prior to initial policy load).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_get_boolean_active<br />
| Get the active value for the boolean.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_get_boolean_names<br />
| Get the boolean names<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_get_boolean_pending<br />
| Get the pending value for the boolean.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_get_initial_context<br />
<br />
security_get_initial_context_raw<br />
| Get the context of an initial kernel security identifier by name. Caller must free via '''freecon'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_getenforce<br />
| Get the enforce flag value.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_load_booleans<br />
| Load policy boolean settings. Path may be NULL, in which case the booleans are loaded from the active policy boolean configuration file.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_load_policy<br />
| Load a policy configuration.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_policyvers<br />
| Get the policy version number.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_set_boolean<br />
| Set the pending value for the boolean.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_set_boolean_list<br />
| Save a list of booleans in a single transaction.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| security_setenforce<br />
| Set the enforce flag value.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selabel_close<br />
| Destroy the specified handle, closing files, freeing allocated memory, etc. The handle may not be further used after it has been closed.<br />
| label.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selabel_lookup<br />
<br />
selabel_lookup_raw<br />
| Perform a labeling lookup operation. Return 0 on success, -1 with errno set on failure. The <tt>key</tt> and <tt>type</tt> arguments are the inputs to the lookup operation; appropriate values are dictated by the backend in use. The result is returned in the memory pointed to by con and must be freed by freecon.<br />
| label.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selabel_open<br />
| Create a labeling handle.<br />
<br />
Open a labeling backend for use. The available backend identifiers are:<br />
<br />
SELABEL_CTX_FILE - file_contexts.<br />
<br />
SELABEL_CTX_MEDIA - media contexts.<br />
<br />
SELABEL_CTX_X - x_contexts.<br />
<br />
<tt>SELABEL_CTX_DB</tt> - SE-PostgreSQL contexts.<br />
<br />
SELABEL_CTX_ANDROID_PROP - <tt>property</tt>_contexts.<br />
<br />
Options may be provided via the opts parameter; available options are:<br />
<br />
SELABEL_OPT_UNUSED - no-op option, useful for unused slots in an array of options.<br />
<br />
SELABEL_OPT_VALIDATE - validate contexts before returning them (boolean value).<br />
<br />
SELABEL_OPT_BASEONLY - don't use local customizations to backend data (boolean value).<br />
<br />
SELABEL_OPT_PATH - specify an alternate path to use when loading backend data.<br />
<br />
SELABEL_OPT_SUBSET - select a subset of the search space as an optimization (file backend).<br />
<br />
Not all options may be supported by every backend. Return value is the created handle on success or NULL with errno set on failure.<br />
| label.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selabel_stats<br />
| Log a message with information about the number of queries performed, number of unused matching entries, or other operational statistics. Message is backend-specific, some backends may not output a message.<br />
| label.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_binary_policy_path<br />
| Return path to the binary policy file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_booleans_path<br />
| Return path to the booleans file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_boolean_sub<br />
| Reads the <tt>/etc/selinux/TYPE/booleans.subs_dist</tt> file looking for a record with <tt>boolean_name</tt>. If a record exists <tt>'''selinux_boolean_sub'''(3)</tt> returns the translated name otherwise it returns the original name. The returned value needs to be freed. On failure NULL will be returned.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_booleans_subs_path<br />
| Returns the path to the <tt>booleans.subs_dist</tt> configuration file.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_check_access<br />
| Used to check if the source context has the access permission for the specified class on the target context. Note that the permission and class are reference strings.<br />
<br />
The <tt>aux</tt> parameter may reference supplemental auditing information. <br />
<br />
Auditing is handled as described in <tt>'''avc_audit'''(3)</tt>.<br />
<br />
See <tt>'''security_deny_unknown'''(3)</tt> for how the <tt>deny_unknown</tt> flag can influence policy decisions.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_check_passwd_access<br />
| Check a permission in the passwd class. Return 0 if granted or -1 otherwise.<br />
<br />
Replaced by <tt>'''selinux_check_access'''(3)</tt><br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_check_securetty_context <br />
| Check if the tty_context is defined as a securetty<nowiki>. Return 0 if secure, < 0 otherwise.</nowiki><br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_colors_path<br />
| Return path to file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_contexts_path<br />
| Return path to contexts directory under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_current_policy_path<br />
| Return path to the current policy.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_customizable_types_path<br />
| Return path to customizable_types file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_default_context_path<br />
| Return path to default_context file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_default_type_path<br />
| Return path to <tt>default_type</tt> file.<br />
| get_default_type.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_failsafe_context_path<br />
| Return path to failsafe_context file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_file_context_cmp<br />
| Compare two file contexts, return 0 if equivalent.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_file_context_homedir_path<br />
| Return path to <tt>file_context.homedir</tt> file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_file_context_local_path<br />
| Return path to <tt>file_context.local</tt> file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_file_context_path<br />
| Return path to <tt>file_context</tt> file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_file_context_subs_path<br />
| Return path to <tt>file_context.subs</tt> file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_file_context_subs_dist_path<br />
| Return path to <tt>file_context.subs_dist</tt> file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_file_context_verify<br />
| Verify the context of the file 'path' against policy. Return 0 if correct.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_get_callback<br />
| Used to get a pointer to the callback function of the given <tt>type</tt>. Callback functions are set using <tt>'''selinux_set_callback'''(3)</tt>.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_getenforcemode<br />
| Reads the /etc/selinux/config file and determines whether the machine should be started in enforcing (1), permissive (0) or disabled (-1) mode. <br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_getpolicytype<br />
| Reads the /<tt>etc/selinux/config</tt> file and determines what the default policy for the machine is. Calling application must free <tt>policytype</tt>.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_homedir_context_path<br />
| Return path to file under the policy root directory. Note that this file will only appear in older versions of policy at this location. On systems that are managed using <tt>'''semanage'''(8)</tt> this is now in the policy store.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_init_load_policy<br />
| Perform the initial policy load.<br />
<br />
This function determines the desired enforcing mode, sets the the <nowiki>*enforce</nowiki> argument accordingly for the caller to use, sets the SELinux kernel enforcing status to match it, and loads the policy. It also internally handles the initial selinuxfs mount required to perform these actions.<br />
<br />
The function returns 0 if everything including the policy load succeeds. In this case, init is expected to re-exec itself in order to transition to the proper security context. Otherwise, the function returns -1, and init must check <nowiki>*enforce</nowiki> to determine how to proceed. If enforcing (<nowiki>*enforce</nowiki> > 0), then init should halt the system. Otherwise, init may proceed normally without a re-exec.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_lsetfilecon_default<br />
| This function sets the file context to the system defaults. Returns 0 on success.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_lxc_contexts_path<br />
| Return the path to the <tt>lxc_contexts</tt> configuration file.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_media_context_path<br />
| Return path to file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_mkload_policy<br />
| Make a policy image and load it. <br />
<br />
This function provides a higher level interface for loading policy than '''security_load_policy'''(3), internally determining the right policy version, locating and opening the policy file, mapping it into memory, manipulating it as needed for current boolean settings and/or local definitions, and then calling '''security_load_policy'''(3) to load it.<br />
<br />
'preservebools' is a boolean flag indicating whether current policy boolean values should be preserved into the new policy (if 1) or reset to the saved policy settings (if 0). The former case is the default for policy reloads, while the latter case is an option for policy reloads but is primarily for the initial policy load.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_netfilter_context_path<br />
| Returns path to the netfilter_context file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_path<br />
| Returns path to the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_policy_root<br />
| Reads the /etc/selinux/config file and returns the top level directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_raw_context_to_color<br />
| Perform context translation between security contexts and display colors. Returns a space-separated list of ten ten hex RGB triples prefixed by hash marks, e.g. "<nowiki>#ff0000</nowiki>". Caller must free the resulting string via '''free'''(3). Returns -1 upon an error or 0 otherwise.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_raw_to_trans_context<br />
| Perform context translation between the human-readable format ("translated") and the internal system format ("raw"). Caller must free the resulting context via '''freecon'''(3). Returns -1 upon an error or 0 otherwise. If passed NULL, sets the returned context to NULL and returns 0.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_removable_context_path<br />
| Return path to <tt>removable_context</tt> file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_securetty_types_path<br />
| Return path to the securetty_types file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_sepgsql_context_path<br />
| Return path to <tt>sepgsql_context</tt> file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_set_callback<br />
| Sets the callback according to the type: <tt>SELINUX_CB_LOG</tt>, <tt>SELINUX_CB_AUDIT</tt>, <tt>SELINUX_CB_VALIDATE</tt>, <tt>SELINUX_CB_SETENFORCE</tt>, <tt>SELINUX_CB_POLICYLOAD</tt><br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_set_mapping<br />
| Userspace class mapping support that establishes a mapping from a user-provided ordering of object classes and permissions to the numbers actually used by the loaded system policy.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_set_policy_root<br />
| Sets an alternate policy root directory path under which the compiled policy file and context configuration files exist.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_status_open<br />
| Open and map SELinux kernel status page.<br />
| avc.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_status_close<br />
| Unmap and close kernel status page.<br />
| avc.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_status_updated<br />
| Inform whether the kernel status has been updated.<br />
| avc.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_status_getenforce<br />
| Get the enforce flag value.<br />
| avc.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_status_policyload<br />
| Get the number of policy loads.<br />
| avc.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_status_deny_unknown<br />
| Get behaviour for undefined classes/permissions.<br />
| avc.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_systemd_contexts_path<br />
| Returns the path to the <tt>systemd_contexts</tt> configuration file.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_reset_config<br />
| Force a reset of the loaded configuration. '''WARNING''': This is not thread safe. Be very sure that no other threads are calling into <tt>libselinux</tt> when this is called.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_trans_to_raw_context<br />
| Perform context translation between the human-readable format ("translated") and the internal system format ("raw"). Caller must free the resulting context via '''freecon'''(3). Returns -1 upon an error or 0 otherwise. If passed NULL, sets the returned context to NULL and returns 0.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_translations_path<br />
| Return path to setrans.conf file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_user_contexts_path<br />
| Return path to file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_users_path<br />
| Return path to file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_usersconf_path<br />
| Return path to file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_virtual_domain_context_path<br />
| Return path to file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_virtual_image_context_path<br />
| Return path to file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinux_x_context_path<br />
| Return path to x_context file under the policy root directory.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| selinuxfs_exists<br />
| Check if selinuxfs exists as a kernel filesystem.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| set_matchpathcon_canoncon<br />
| Same as '''set_matchpathcon_invalidcon'''(3), but also allows canonicalization of the context, by changing <nowiki>*context</nowiki> to refer to the canonical form. If not set, and invalidcon is also not set, then this defaults to calling '''security_canonicalize_context'''(3).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| set_matchpathcon_flags<br />
| Set flags controlling operation of '''matchpathcon_init'''(3) or '''matchpathcon'''(3): <br />
<br />
MATCHPATHCON_BASEONLY - Only process the base file_contexts file. <br />
<br />
MATCHPATHCON_NOTRANS - Do not perform any context translation.<br />
<br />
MATCHPATHCON_VALIDATE - Validate/canonicalize contexts at init time.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| set_matchpathcon_invalidcon<br />
| Set the function used by '''matchpathcon_init'''(3) when checking the validity of a context in the file_contexts configuration. If not set, then this defaults to a test based on '''security_check_context'''(3). The function is also responsible for reporting any such error, and may include the 'path' and 'lineno' in such error messages.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| set_matchpathcon_printf<br />
| Set the function used by '''matchpathcon_init'''(3) when displaying errors about the file_contexts configuration. If not set, then this defaults to fprintf(stderr, fmt, ...).<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| set_selinuxmnt <br />
| Set the path to the selinuxfs mount point explicitly. Normally, this is determined automatically during libselinux initialization, but this is not always possible, e.g. for /sbin/init which performs the initial mount of selinuxfs.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| setcon<br />
<br />
setcon_raw<br />
| Set the current security context to con.<br />
<br />
Note that use of this function requires that the entire application be trusted to maintain any desired separation between the old and new security contexts, unlike exec-based transitions performed via '''setexeccon'''(3). When possible, decompose your application and use '''setexeccon'''(3)+'''execve'''(3) instead. Note that the application may lose access to its open descriptors as a result of a '''setcon'''(3) unless policy allows it to use descriptors opened by the old context. <br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| setexeccon<br />
<br />
setexeccon_raw<br />
| Set exec security context for the next '''execve'''(3). Call with NULL if you want to reset to the default.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| setexecfilecon<br />
| Set an appropriate security context based on the filename of a helper program, falling back to a new context with the specified type.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| setfilecon<br />
<br />
setfilecon_raw<br />
| Wrapper for the xattr API - Set file context.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| setfscreatecon<br />
<br />
setfscreatecon_raw<br />
| Set the fscreate security context for subsequent file creations. Call with NULL if you want to reset to the default.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| setkeycreatecon<br />
<br />
setkeycreatecon_raw<br />
| Set the keycreate security context for subsequent key creations. Call with NULL if you want to reset to the default.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| setsockcreatecon<br />
<br />
setsockcreatecon_raw<br />
| Set the sockcreate security context for subsequent socket creations. Call with NULL if you want to reset to the default.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| sidget (deprecated)<br />
| From 2.0.86 this is a no-op.<br />
| avc.h<br />
<br />
|-<br />
<br />
<br />
<br />
| sidput (deprecated)<br />
| From 2.0.86 this is a no-op.<br />
| avc.h<br />
<br />
|-<br />
<br />
<br />
<br />
| string_to_av_perm<br />
| Convert string names to access vector permissions.<br />
| selinux.h<br />
<br />
|-<br />
<br />
<br />
<br />
| string_to_security_class<br />
| Convert string names to security class values.<br />
| selinux.h<br />
<br />
|}<br />
<br />
<br />
<br />
{| style="width: 100%;" border="0"<br />
|-<br />
| [[NB_SEforAndroid_2 | '''Previous''']]<br />
| <center>[[NewUsers | '''Home''']]</center><br />
| <center>[[NB_ObjectClassesPermissions | '''Next''']]</center><br />
|}<br />
<br />
<br />
<br />
----<br />
<references/><br />
<br />
[[Category:Notebook]]</div>RichardHaines