1 <html devsite> 2 <head> 3 <title>Validating SELinux</title> 4 <meta name="project_path" value="/_project.yaml" /> 5 <meta name="book_path" value="/_book.yaml" /> 6 </head> 7 <body> 8 <!-- 9 Copyright 2017 The Android Open Source Project 10 11 Licensed under the Apache License, Version 2.0 (the "License"); 12 you may not use this file except in compliance with the License. 13 You may obtain a copy of the License at 14 15 http://www.apache.org/licenses/LICENSE-2.0 16 17 Unless required by applicable law or agreed to in writing, software 18 distributed under the License is distributed on an "AS IS" BASIS, 19 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 20 See the License for the specific language governing permissions and 21 limitations under the License. 22 --> 23 24 25 26 <p>Android strongly encourages OEMs to test their SELinux implementations 27 thoroughly. As manufacturers implement SELinux, they should apply the new 28 policy to a test pool of devices first.</p> 29 30 <p>Once applied, make sure SELinux is running in the correct mode on the device by 31 issuing the command:getenforce</p> 32 33 <p>This will print the global SELinux mode: either Enforcing or 34 Permissive. Please note, this command shows only the global SELinux mode. To 35 determine the SELinux mode for each domain, you must examine the corresponding 36 files or run the latest version of <code>sepolicy-analyze</code> with the 37 appropriate (-p) flag, present in /platform/system/sepolicy/tools/.</p> 38 39 <h2 id=reading_denials>Reading denials</h2> 40 41 <p>Then check for errors. Errors are routed as event logs to dmesg and 42 <code>logcat</code> and are viewable locally on the device. Manufacturers 43 should examine the SELinux output to dmesg on these devices and refine settings prior to public 44 release in permissive mode and eventual switch to enforcing mode. SELinux log 45 messages contain "avc:" and so may easily be found with <code>grep</code>. It is 46 possible to capture the ongoing denial logs by running <code>cat /proc/kmsg</code> 47 or to capture denial logs from the previous boot by running cat <code>/proc/last_kmsg</code>.</p> 48 49 <p>With this output, manufacturers can readily identify when system users or 50 components are in violation of SELinux policy. Manufacturers can then repair 51 this bad behavior, either by changes to the software, SELinux policy, or both.</p> 52 53 <p>Specifically, these log messages indicate what processes would fail under 54 enforcing mode and why. Here is an example:</p> 55 56 <pre> 57 avc: denied { connectto } for pid=2671 comm="ping" path="/dev/socket/dnsproxyd" 58 scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket 59 </pre> 60 61 <p>Interpret this output like so:</p> 62 63 <ul> 64 <li> The <code>{ connectto }</code> above represents the action being taken. Together with the 65 <code>tclass</code> at the end (<code>unix_stream_socket</code>), it tells you roughly what was being done 66 to what. In this case, something was trying to connect to a unix stream socket. 67 <li> The <code>scontext (u:r:shell:s0)</code> tells you what context initiated the action. In 68 this case this is something running as the shell. 69 <li> The <code>tcontext (u:r:netd:s0)</code> tells you the context of the actions target. In 70 this case, thats a unix_stream_socket owned by <code>netd</code>. 71 <li> The <code>comm="ping"</code> at the top gives you an additional hint about what was being 72 run at the time the denial was generated. In this case, its a pretty good hint. 73 </ul> 74 75 <p>And here is another example:</p> 76 <pre class="devsite-terminal devsite-click-to-copy">adb shell su root dmesg | grep 'avc: '</pre> 77 <p>Output:</p> 78 <pre> 79 <5> type=1400 audit: avc: denied { read write } for pid=177 80 comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0 81 tcontext=u:object_r:kmem_device:s0 tclass=chr_file 82 </pre> 83 84 85 <p>Here are the key elements from this denial:</p> 86 87 <ul> 88 <li><em>Action</em> - the attempted action is highlighted in brackets, 89 <code>read write</code> or <code>setenforce</code>. 90 <li><em>Actor</em> - The <code>scontext</code> (source context) entry represents 91 the actor, in this case the<code> rmt_storage</code> daemon. 92 <li><em>Object</em> - The <code>tcontext</code> (target context) entry represents 93 the object being acted upon, in this case kmem. 94 <li><em>Result</em> - The <code>tclass</code> (target class) entry indicates the type 95 of object being acted upon, in this case a <code>chr_file</code> (character device). 96 </ul> 97 98 <h2 id=switching_to_permissive>Switching to permissive</h2> 99 100 <p class="caution"><strong>Important:</strong> Permissive mode is not supported 101 on production devices. CTS tests confirm 102 enforcing mode is enabled.</p> 103 104 <p>SELinux enforcement can be disabled via ADB on userdebug or eng builds. To do so, 105 first switch ADB to root by running <code>adb root</code>. Then, to disable SELinux 106 enforcement, run: 107 <pre class="devsite-terminal devsite-click-to-copy"> 108 adb shell setenforce 0 109 </pre> 110 111 <p>Or at the kernel command line (during early device bring-up):</p> 112 113 <pre class="devsite-click-to-copy"> 114 <code class="devsite-terminal">androidboot.selinux=permissive</code> 115 <code class="devsite-terminal">androidboot.selinux=enforcing</code> 116 </pre> 117 118 <h2 id=using_audit2allow>Using audit2allow</h2> 119 120 <p>The <code>selinux/policycoreutils/audit2allow</code> tool takes 121 <code>dmesg</code> denials and converts them into corresponding SELinux policy 122 statements. As such, it can greatly speed SELinux development. 123 <code>audit2allow</code> is shipped as part of the Android source tree and 124 is compiled automatically when you build Android from source.</p> 125 126 <p>To use it, run:</p> 127 128 <pre class="devsite-click-to-copy"> 129 <code class="devsite-terminal">adb pull /sys/fs/selinux/policy</code> 130 <code class="devsite-terminal">adb logcat -b all -d | audit2allow -p policy</code> 131 </pre> 132 133 <p class="note"><strong>Note</strong>: Running these commands does not change 134 bugreport.txt because all logs are already there, including the ones from 135 before the last reboot. On devices running an OTA or development flash, old 136 and new violations are mixed until another reboot. To address this, reboot 137 the device again or filter LAST_KMSG and LAST_LOGCAT from your bugreport. 138 </p> 139 140 <p>Nevertheless, care must be taken to examine each potential addition for 141 overreaching permissions. For example, feeding audit2allow the 142 <code>rmt_storage</code> denial shown earlier results in the following 143 suggested SELinux policy statement:</p> 144 145 <pre> 146 #============= shell ============== 147 allow shell kernel:security setenforce; 148 #============= rmt ============== 149 allow rmt kmem_device:chr_file { read write }; 150 </pre> 151 152 153 <p>This would grant <code>rmt</code> the ability to write kernel memory, a 154 glaring security hole. Often the <code>audit2allow</code> statements are only a 155 starting point. After employing these statements, you may need to change the 156 source domain and the label of the target, as well as incorporate proper 157 macros, to arrive at a good policy. Sometimes the denial being examined should 158 not result in any policy changes at all; rather the offending application 159 should be changed.</p> 160 161 </body> 162 </html> 163
