Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 1 | page.title=SELinux concepts |
| 2 | @jd:body |
| 3 | |
| 4 | <!-- |
| 5 | Copyright 2014 The Android Open Source Project |
| 6 | |
| 7 | Licensed under the Apache License, Version 2.0 (the "License"); |
| 8 | you may not use this file except in compliance with the License. |
| 9 | You may obtain a copy of the License at |
| 10 | |
| 11 | http://www.apache.org/licenses/LICENSE-2.0 |
| 12 | |
| 13 | Unless required by applicable law or agreed to in writing, software |
| 14 | distributed under the License is distributed on an "AS IS" BASIS, |
| 15 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 16 | See the License for the specific language governing permissions and |
| 17 | limitations under the License. |
| 18 | --> |
| 19 | <div id="qv-wrapper"> |
| 20 | <div id="qv"> |
| 21 | <h2>In this document</h2> |
| 22 | <ol id="auto-toc"> |
| 23 | </ol> |
| 24 | </div> |
| 25 | </div> |
| 26 | |
| 27 | <p>Review this page to become familar with the concepts at play within SELinux.</p> |
| 28 | |
| 29 | <h2 id=mandatory_access_control>Mandatory access control</h2> |
| 30 | |
| 31 | <p>Security Enhanced Linux (SELinux), is a mandatory access control (MAC) system |
| 32 | for the Linux operating system. As a MAC system, it differs from Linux’s |
| 33 | familiar discretionary access control (DAC) system. In a DAC system, a concept |
| 34 | of ownership exists, whereby an owner of a particular resource controls access |
| 35 | permissions associated with it. This is generally coarse-grained and subject |
| 36 | to unintended privilege escalation. A MAC system, however, consults a central |
| 37 | authority for a decision on all access attempts.</p> |
| 38 | |
| 39 | <p>SELinux has been implemented as part of the Linux Security Module (LSM) |
| 40 | framework, which recognizes various kernel objects, and sensitive actions |
| 41 | performed on them. At the point at which each of these actions would be |
| 42 | performed, an LSM hook function is called to determine whether or not the |
| 43 | action should be allowed based on the information for it stored in an opaque |
| 44 | security object. SELinux provides an implementation for these hooks and |
| 45 | management of these security objects, which combine with its own policy, to |
| 46 | determine the access decisions.</p> |
| 47 | |
| 48 | <p>In conjunction with other Android security measures, Android's access control |
| 49 | policy greatly limits the potential damage of compromised machines and |
| 50 | accounts. Using tools like Android's discretionary and mandatory access |
| 51 | controls gives you a structure to ensure your software runs only at the minimum |
| 52 | privilege level. This mitigates the effects of attacks and reduces the |
| 53 | likelihood of errant processes overwriting or even transmitting data.</p> |
| 54 | |
| 55 | <p>Starting in Android 4.3, SELinux provides a mandatory access control (MAC) |
| 56 | umbrella over traditional discretionary access control (DAC) environments. For |
| 57 | instance, software must typically run as the root user account to write to raw |
| 58 | block devices. In a traditional DAC-based Linux environment, if the root user |
| 59 | becomes compromised that user can write to every raw block device. However, |
| 60 | SELinux can be used to label these devices so the process assigned the root |
| 61 | privilege can write to only those specified in the associated policy. In this |
| 62 | way, the process cannot overwrite data and system settings outside of the |
| 63 | specific raw block device.</p> |
| 64 | |
| 65 | <p>See <a href="implement.html#use_cases">Use Cases</a> for more examples of threats and ways to address them with SELinux.</p> |
| 66 | |
| 67 | <h2 id=enforcement_levels>Enforcement levels</h2> |
| 68 | |
| 69 | <p>Become familiar with the following terms to understand how SELinux can be |
| 70 | implemented to varying strengths.</p> |
| 71 | |
| 72 | <ul> |
| 73 | <li><em>Permissive</em> - SELinux security policy is not enforced, only logged. |
| 74 | <li><em>Enforcing</em> - Security policy is enforced and logged. Failures appear as EPERM errors. |
| 75 | </ul> |
| 76 | |
| 77 | <p>This choice is binary and determines whether your policy takes action or merely |
| 78 | allows you to gather potential failures. Permissive is especially useful during |
| 79 | implementation.</p> |
| 80 | |
| 81 | <ul> |
| 82 | <li><em>Unconfined</em> - A very light policy that prohibits certain tasks and provides a temporary |
| 83 | stop-gap during development. Should not be used for anything outside of the |
| 84 | Android Open Source Project (AOSP). |
| 85 | <li><em>Confined</em> - A custom-written policy designed for the service. That policy should define |
| 86 | precisely what is allowed. |
| 87 | </ul> |
| 88 | |
| 89 | <p>Unconfined policies are available to help implement SELinux in Android quickly. |
| 90 | They are suitable for most root-level applications. But they should be |
| 91 | converted to confined policies wherever possible over time to restrict each |
| 92 | application to precisely the resources it needs.</p> |
| 93 | |
| 94 | <p>Ideally, your policy is both in enforcing mode and confined. Unconfined |
| 95 | policies in enforcement mode can mask potential violations that would have been |
| 96 | logged in permissive mode with a confined policy. Therefore, we strongly |
| 97 | recommend partners implement true confined policies.</p> |
| 98 | |
| 99 | <h2 id=labels_rules_and_domains>Labels, rules and domains</h2> |
| 100 | |
| 101 | <p>SELinux depends upon <em>labels</em> to match actions and policies. Labels determine what is allowed. Sockets, |
| 102 | files, and processes all have labels in SELinux. SELinux decisions are based |
| 103 | fundamentally on labels assigned to these objects and the policy defining how |
| 104 | they may interact. In SELinux, a label takes the form: |
| 105 | user:role:type:mls_level, where the type is the primary component of the access |
| 106 | decisions, which may be modified by the other sections components which make up |
| 107 | the label. The objects are mapped to classes and the different types of access |
| 108 | for each class are represented by permissions. </p> |
| 109 | |
| 110 | <p>The policy rules come in the form: allow <em>domains</em> <em>types</em>:<em>classes</em> <em>permissions</em>;, where:</p> |
| 111 | |
| 112 | <ul> |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 113 | <li><em>Domain</em> - A label for the process or set of processes. Also called a domain type as it is just a type for a process. |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 114 | <li><em>Type</em> - A label for the object (e.g. file, socket) or set of objects. |
| 115 | <li><em>Class</em> - The kind of object (e.g. file, socket) being accessed. |
| 116 | <li><em>Permission</em> - The operation (e.g. read, write) being performed. |
| 117 | </ul> |
| 118 | |
| 119 | <p>And so an example use of this would follow the structure:</p> |
| 120 | <code>allow appdomain app_data_file:file rw_file_perms;</code> |
| 121 | |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 122 | <p>This says that all application domains are allowed to read and write files labeled |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 123 | app_data_file. Note that this rule relies upon macros defined in the |
| 124 | global_macros file, and other helpful macros can also be found in the te_macros |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 125 | file, both of which can be found in the <a href="https://android.googlesource.com/platform/external/sepolicy/">external/sepolicy</a> directory in the AOSP source tree. Macros are provided for common groupings of classes, permissions and |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 126 | rules, and should be used whenever possible to help reduce the likelihood of |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 127 | failures due to denials on related permissions.</p> |
| 128 | |
| 129 | <p>In addition to individually listing domains or types in a rule, one can also refer to a set of domains or types via an <em>attribute</em>. An attribute is simply a name for a set of domains or types. Each domain or type can be associated with any number of attributes. When a rule is written that specifies an attribute name, that name is automatically expanded to the list of domains or types associated with the attribute. For example, the <em>domain</em> attribute is associated with all process domains, and the <em>file_type</em> attribute is associated with all file types.</p> |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 130 | |
| 131 | <p>Use the syntax above to create avc rules that comprise the essence of an |
| 132 | SELinux policy. A rule takes the form: |
| 133 | <pre> |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 134 | <rule variant> <source_types> <target_types> : <classes> <permissions> |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 135 | </pre> |
| 136 | |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 137 | <p>The rule indicates what should happen when a subject labeled with any of the <em>source_types</em> attempts an action corresponding to any of the <em>permissions</em> on an object with any of the class <em>classes</em> which has any of the <em>target_types</em> label. The most common example of one of these rules is an allow rule, e.g.:</p> |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 138 | |
| 139 | <pre> |
| 140 | allow domain null_device:chr_file { open }; |
| 141 | </pre> |
| 142 | |
| 143 | |
| 144 | <p> |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 145 | This rule allows a process with any <em>domain</em> associated with the ‘domain’ attribute to take the action described by the <em>permission</em> ‘open’ on an object of <em>class</em> ‘chr_file’ (character device file) that has the <em>target_type</em> label of ‘null_device.’ In practice, this rule may be extended to include other permissions: </p> |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 146 | |
| 147 | <pre> |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 148 | allow domain null_device:chr_file { getattr open read ioctl lock append write}; |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 149 | </pre> |
| 150 | |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 151 | <p>When combined with the knowledge that ‘domain’ is an attribute assigned to |
| 152 | all process domains and |
| 153 | that null_device is the label for the character device /dev/null, this rule basically |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 154 | permits reading and writing to <code>/dev/null</code>.</p> |
| 155 | |
| 156 | <p>A <em>domain</em> generally corresponds to a process and will have a label associated with it.</p> |
| 157 | |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 158 | <p>For example, a typical Android app is running in its own process and has the |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 159 | label of untrusted_app that grants it certain restricted permissions.</p> |
| 160 | |
| 161 | <p>Platform apps built into the system run under a separate label and are granted |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 162 | a distinct set of permissions. System UID apps that are part of the core Android |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 163 | system run under the system_app label for yet another set of privileges.</p> |
| 164 | |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 165 | <p>Access to the following generic labels should never be directly allowed to domains; instead, a more specific type should be created for the object or objects:</p> |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 166 | |
| 167 | <ul> |
| 168 | <li> socket_device |
| 169 | <li> device |
| 170 | <li> block_device |
| 171 | <li> default_service |
Stephen Smalley | f410f65 | 2015-02-12 11:09:51 -0500 | [diff] [blame] | 172 | <li> system_data_file |
Clay Murphy | 29a7b5b | 2014-10-14 19:04:29 -0700 | [diff] [blame] | 173 | <li> tmpfs |
| 174 | </ul> |