1 page.title=Implementing SELinux 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>SELinux is set up to default-deny, which means that every single access for 28 which it has a hook in the kernel must be explicitly allowed by policy. This 29 means a policy file is comprised of a large amount of information regarding 30 rules, types, classes, permissions, and more. A full consideration of SELinux 31 is out of the scope of this document, but an understanding of how to write 32 policy rules is now essential when bringing up new Android devices. There is a 33 great deal of information available regarding SELinux already. See <a 34 href="{@docRoot}devices/tech/security/selinux/index.html#supporting_documentation">Supporting 35 documentation</a> for suggested resources.</p> 36 37 <h2 id=summary_of_steps>Summary of steps</h2> 38 39 <p>Here is a brief summary of the steps needed to implement SELinux on your 40 Android device:</p> 41 42 <ol> 43 <li>Add SELinux support in the kernel and configuration. 44 <li>Grant each service (process or daemon) started from <code>init</code> its own domain. 45 <li>Identify these services by: 46 <ul> 47 <li>Reviewing the init.<device>.rc file and finding all services. 48 <li>Examining warnings of the form <em>init: Warning! Service name needs a SELinux domain defined; please fix!</em> in <code>dmesg</code> output. 49 <li>Checking <code>ps -Z | grep init</code> output to see which services are running in the init domain. 50 </ul> 51 <li>Label all new processes, drivers, sockets, etc. 52 All objects need to be labeled 53 properly to ensure they interact properly with the policies you apply. See the 54 labels used in AOSP for examples to follow in label name creation. 55 <li>Institute security policies that fully cover all labels and restrict 56 permissions to their absolute minimum. 57 </ol> 58 59 <p>Ideally, OEMs start with the policies in the AOSP and then build upon them for 60 their own customizations.</p> 61 62 <h2 id=key_files>Key files</h2> 63 64 <p>SELinux for Android is accompanied by everything you need to enable SELinux 65 now. You merely need to integrate the <a href="https://android.googlesource.com/kernel/common/">latest Android kernel</a> and then incorporate the files found in the <a href="https://android.googlesource.com/platform/external/sepolicy/">external/sepolicy</a> directory:</p> 66 67 <p><a href="https://android.googlesource.com/kernel/common/">https://android.googlesource.com/kernel/common/ </a></p> 68 69 <p><a href="https://android.googlesource.com/platform/external/sepolicy/">https://android.googlesource.com/platform/external/sepolicy/</a></p> 70 71 <p>Those files when compiled comprise the SELinux kernel security policy and cover 72 the upstream Android operating system. You should not need to modify the 73 external/sepolicy files directly. Instead, add your own device-specific policy 74 files within the /device/manufacturer/device-name/sepolicy directory.</p> 75 76 <p>Here are the files you must create or edit in order to implement SELinux:</p> 77 78 <ul> 79 <li><em>New SELinux policy source (*.te) files</em> - Located in the 80 <root>/device/manufacturer/device-name/sepolicy directory. These files define 81 domains and their labels. The new policy files get 82 concatenated with the existing policy files during compilation into a single 83 SELinux kernel policy file. 84 <p class="caution"><strong>Important:</strong> Do not alter the app.te file 85 provided by the Android Open Source Project. 86 Doing so risks breaking all third-party applications.</p> 87 <li><em>Updated BoardConfig.mk makefile</em> - Located in the <device-name> 88 directory containing the sepolicy subdirectory. It must be updated to reference 89 the sepolicy subdirectory once created if it 90 wasnt in initial implementation. 91 <li><em>file_contexts</em> - Located in the sepolicy subdirectory. This file 92 assigns labels to files and is used by various userspace components. As you 93 create new policies, create or update this file to 94 assign new labels to files. In order to apply new file_contexts, you must 95 rebuild the filesystem image or run <code>restorecon</code> on the file to be 96 relabeled. On upgrades, changes to file_contexts are automatically applied to 97 the system and userdata partitions as part of the upgrade. Changes can also be 98 automatically applied on upgrade to other partitions by adding 99 restorecon_recursive calls to your init.<em>board</em>.rc file after the 100 partition has been mounted read-write. 101 <li><em>genfs_contexts</em> - Located in the sepolicy subdirectory. This file 102 assigns labels to filesystems such as proc or vfat that do not support extended 103 attributes. This configuration is loaded as part of the kernel policy but 104 changes may not take effect for in-core inodes, requiring a reboot or 105 unmounting and re-mounting the filesystem to fully apply the change. Specific 106 labels may also be assigned to specific mounts such as vfat using the context= 107 mount option. 108 <li><em>property_contexts</em> - Located in the sepolicy subdirectory. This 109 file assigns labels to Android system properties to control what processes can 110 set them. This configuration is read by the init process during startup and 111 whenever the selinux.reload_policy property is set to 1. 112 <li><em>service_contexts</em> - Located in the sepolicy subdirectory. This 113 file assigns labels to Android binder services to control what processes can 114 add (register) and find (lookup) a binder reference for the service. This 115 configuration is read by the servicemanager process during startup and whenever 116 the selinux.reload_policy property is set to 1. 117 <li><em>seapp_contexts</em> - Located in the sepolicy subdirectory. This file 118 assigns labels to app processes and /data/data directories. This configuration 119 is read by the zygote process on each app launch and by installd during startup 120 and whenever the selinux.reload_policy property is set to 1. 121 <li><em>mac_permissions.xml</em> - Located in the sepolicy subdirectory. This 122 file assigns a seinfo tag to apps based on their signature and optionally their 123 package name. The seinfo tag can then be used as a key in the seapp_contexts 124 file to assign a specific label to all apps with that seinfo tag. This 125 configuration is read by system_server during startup. 126 </ul> 127 128 <p>Then just update your BoardConfig.mk makefile - located in the directory 129 containing the sepolicy subdirectory - to reference the sepolicy subdirectory 130 and each policy file once created, as shown below. The BOARD_SEPOLICY variables 131 and their meaning is documented in the external/sepolicy/README file.</p> 132 133 <pre> 134 BOARD_SEPOLICY_DIRS += \ 135 <root>/device/manufacturer/device-name/sepolicy 136 137 BOARD_SEPOLICY_UNION += \ 138 genfs_contexts \ 139 file_contexts \ 140 sepolicy.te 141 </pre> 142 143 <p class="note"><strong>Note:</strong> As of the M release, 144 BOARD_SEPOLICY_UNION is no longer required as all policy files found within any 145 directory included in the BOARD_SEPOLICY_DIRS variable are joined with the 146 base policy automatically.</p> 147 148 <p>After rebuilding your device, it is enabled with SELinux. You can now either 149 customize your SELinux policies to accommodate your own additions to the 150 Android operating system as described in <a 151 href="customize.html">Customization</a> or verify your existing setup as 152 covered in <a href="validate.html">Validation</a>.</p> 153 154 <p>Once the new policy files and BoardConfig.mk updates are in place, the new 155 policy settings are automatically built into the final kernel policy file.</p> 156 157 <h2 id=use_cases>Use cases</h2> 158 159 <p>Here are specific examples of exploits to consider when crafting your own 160 software and associated SELinux policies:</p> 161 162 <p><strong>Symlinks</strong> - Because symlinks appear as files, they are often read just as that. This can 163 lead to exploits. For instance, some privileged components such as init change 164 the permissions of certain files, sometimes to be excessively open.</p> 165 166 <p>Attackers might then replace those files with symlinks to code they control, 167 allowing the attacker to overwrite arbitrary files. But if you know your 168 application will never traverse a symlink, you can prohibit it from doing so 169 with SELinux.</p> 170 171 <p><strong>System files</strong> - Consider the class of system files that should only be modified by the 172 system server. Still, since netd, init, and vold run as root, they can access 173 those system files. So if netd became compromised, it could compromise those 174 files and potentially the system server itself.</p> 175 176 <p>With SELinux, you can identify those files as system server data files. 177 Therefore, the only domain that has read/write access to them is system server. 178 Even if netd became compromised, it could not switch domains to the system 179 server domain and access those system files although it runs as root.</p> 180 181 <p><strong>App data</strong> - Another example is the class of functions that must run as root but should 182 not get to access app data. This is incredibly useful as wide-ranging 183 assertions can be made, such as certain domains unrelated to application data 184 being prohibited from accessing the internet.</p> 185 186 <p><strong>setattr</strong> - For commands such as chmod and chown, you could identify the set of files 187 where the associated domain can conduct setattr. Anything outside of that could 188 be prohibited from these changes, even by root. So an application might run 189 chmod and chown against those labeled app_data_files but not shell_data_files 190 or system_data_files.</p> 191 192 <h2 id=steps_in_detail>Steps in detail</h2> 193 194 <p>Here is a detailed view of how Android recommends you employ and customize 195 SELinux to protect your devices:</p> 196 197 <ol> 198 <li>Enable SELinux in the kernel: 199 <code>CONFIG_SECURITY_SELINUX=y</code> 200 <li>Change the kernel_cmdline parameter so that:<br/> 201 <code>BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive</code>. 202 <br/> 203 This is only for initial development of policy for the device. Once you have 204 an initial bootstrap policy, remove this parameter so that your device is 205 enforcing or it will fail CTS. 206 <li>Boot up the system in permissive and see what denials are encountered on boot:<br/> 207 On Ubuntu 14.04 or newer: 208 <br/> 209 <code>adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/<em>board</em>/root/sepolicy</code> 210 <br/> 211 On Ubuntu 12.04: 212 <code>adb shell su -c dmesg | grep denied | audit2allow</code> 213 <li>Evaluate the output. See <a href="validate.html">Validation</a> for instructions and tools. 214 <li>Identify devices, and other new files that need labeling. 215 <li>Use existing or new labels for your objects. 216 Look at the *_contexts files to 217 see how things were previously labeled and use knowledge of the label meanings 218 to assign a new one. Ideally, this will be an existing label which will fit 219 into policy, but sometimes a new label will be needed, and rules for access to 220 that label will be needed, as well. 221 <li>Identify domains/processes that should have their own security domains. A policy will likely need to be written for each of these from scratch. All services spawned from <code>init</code>, for instance, should have their own. The following commands help reveal those that remain running (but ALL services need such a treatment):<br/> 222 <code>$ adb shell su -c ps -Z | grep init</code><br/> 223 <code>$ adb shell su -c dmesg | grep 'avc: '</code> 224 <li>Review init.<device>.rc to identify any which are without a type. 225 These should 226 be given domains EARLY in order to avoid adding rules to init or otherwise 227 confusing <code>init</code> accesses with ones that are in their own policy. 228 <li>Set up <code>BOARD_CONFIG.mk</code> to use <code>BOARD_SEPOLICY_*</code> variables. See 229 the README in external/sepolicy for details on setting this up. 230 <li> Examine the init.<device>.rc and fstab.<device> file and make sure every use of mount 231 corresponds to a properly labeled filesystem or that a context= mount option is specified. 232 <li> Go through each denial and create SELinux policy to properly handle each. See 233 the examples within <a href="customize.html">Customization</a>. 234 </ol> 235
