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 Linuxs 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> 113 <li><em>Domain</em> - A label for the process or set of processes. 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 122 <p>This says an application is allowed to read and write files labeled 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 125 file. Macros are provided for common groupings of classes, permissions and 126 rules, and should be used whenever possible to help reduce the likelihood of 127 failures due to denials on related permissions. During compilation, those 128 overrides are concatenated to the existing SELinux settings and into a single 129 security policy. These overrides add to the base security policy rather than 130 subtract from existing settings.</p> 131 132 <p>Use the syntax above to create avc rules that comprise the essence of an 133 SELinux policy. A rule takes the form: 134 <pre> 135 <rule variant> <source_type> <target_type> : <class> <permission> 136 </pre> 137 138 <p>The rule indicates what should happen when an object labeled with the <em>source_type </em>attempts an action corresponding to <em>permission </em>on an object of class <em>class </em>which has the <em>target_type </em>label. The most common example of one of these rules is an allow rule, e.g.:</p> 139 140 <pre> 141 allow domain null_device:chr_file { open }; 142 </pre> 143 144 145 <p> 146 This rule allows a process with <em>source_type</em> of domainto take the action described by the <em>permission</em> open on an object of <em>class</em> chr_file that has the <em>target_type</em> label of null_device. In practice, this rule may be extended to include other permissions: </p> 147 148 <pre> 149 allow domain null_device:chr_file { getattr open read ioctl lock append write}; 150 </pre> 151 152 <p>When combined with the knowledge that domain is a label for all processes and 153 that null_device is the label for the chr_file /dev/null, this rule basically 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 158 <p>For example, a typical Android app is running it its own process and has the 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 162 a distinct set of permissions. System apps that are part of the core Android 163 system run under the system_app label for yet another set of privileges.</p> 164 165 <p>These generic labels require further specification:</p> 166 167 <ul> 168 <li> socket_device 169 <li> device 170 <li> block_device 171 <li> default_service 172 <li> system_data_type 173 <li> tmpfs 174 </ul> 175
