diff options
Diffstat (limited to 'en/security')
| -rw-r--r-- | en/security/authentication/gatekeeper.html | 2 | ||||
| -rw-r--r-- | en/security/bulletin/2017-06-01.html | 55 | ||||
| -rw-r--r-- | en/security/encryption/file-based.html | 14 | ||||
| -rw-r--r-- | en/security/encryption/full-disk.html | 2 | ||||
| -rw-r--r-- | en/security/keystore/implementer-ref.html | 16 | ||||
| -rw-r--r-- | en/security/keystore/index.html | 2 | ||||
| -rw-r--r-- | en/security/selinux/concepts.html | 12 | ||||
| -rw-r--r-- | en/security/selinux/customize.html | 6 | ||||
| -rw-r--r-- | en/security/selinux/device-policy.html | 14 | ||||
| -rw-r--r-- | en/security/selinux/implement.html | 24 | ||||
| -rw-r--r-- | en/security/selinux/validate.html | 24 | ||||
| -rw-r--r-- | en/security/trusty/index.html | 8 | ||||
| -rw-r--r-- | en/security/verifiedboot/dm-verity.html | 2 | ||||
| -rw-r--r-- | en/security/verifiedboot/verified-boot.html | 2 |
14 files changed, 101 insertions, 82 deletions
diff --git a/en/security/authentication/gatekeeper.html b/en/security/authentication/gatekeeper.html index 94661684..692212c5 100644 --- a/en/security/authentication/gatekeeper.html +++ b/en/security/authentication/gatekeeper.html @@ -128,7 +128,7 @@ in GateKeeper.</p> only the addition of device-specific routines to be complete. To implement a TEE Gatekeeper with device-specific code for your TEE, please refer to the functions and comments in the following file:</p> -<pre> +<pre class="devsite-click-to-copy"> system/gatekeeper/include/gatekeeper/gatekeeper.h </pre> diff --git a/en/security/bulletin/2017-06-01.html b/en/security/bulletin/2017-06-01.html index 8c3f8faf..02a2578a 100644 --- a/en/security/bulletin/2017-06-01.html +++ b/en/security/bulletin/2017-06-01.html @@ -20,7 +20,7 @@ See the License for the specific language governing permissions and limitations under the License. --> -<p><em>Published June 5, 2017</em></p> +<p><em>Published June 5, 2017 | Updated June 7, 2017</em></p> <p>The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of June 05, 2017 or later @@ -31,8 +31,8 @@ level.</p> <p>Partners were notified of the issues described in the bulletin at least a month ago. Source code patches for these issues will be released to the Android -Open Source Project (AOSP) repository in the next 48 hours. We will revise this -bulletin with the AOSP links when they are available.</p> +Open Source Project (AOSP) repository and linked from this bulletin. This +bulletin also includes links to patches outside of AOSP.</p> <p>The most severe of these issues is a critical security vulnerability in Media Framework that could enable a remote attacker using a specially crafted file to @@ -132,21 +132,21 @@ to access data outside of its permission levels.</p> </tr> <tr> <td>CVE-2017-0639</td> - <td>A-35310991</td> + <td><a href="https://android.googlesource.com/platform/packages/apps/Bluetooth/+/f196061addcc56878078e5684f2029ddbf7055ff">A-35310991</a></td> <td>ID</td> <td>High</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0645</td> - <td>A-35385327</td> + <td><a href="https://android.googlesource.com/platform/packages/apps/Bluetooth/+/14b7d7e1537af60b7bca6c7b9e55df0dc7c6bf41">A-35385327</a></td> <td>EoP</td> <td>Moderate</td> <td>6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0646</td> - <td>A-33899337</td> + <td><a href="https://android.googlesource.com/platform/system/bt/+/2bcdf8ec7db12c5651c004601901f1fc25153f2c">A-33899337</a></td> <td>ID</td> <td>Moderate</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> @@ -172,70 +172,70 @@ unprivileged process.</p> </tr> <tr> <td>CVE-2015-8871</td> - <td>A-35443562</td> + <td>A-35443562<a href="#asterisk">*</a></td> <td>RCE</td> <td>High</td> <td>5.0.2, 5.1.1, 6.0, 6.0.1</td> </tr> <tr> <td>CVE-2016-8332</td> - <td>A-37761553</td> + <td>A-37761553<a href="#asterisk">*</a></td> <td>RCE</td> <td>High</td> <td>5.0.2, 5.1.1, 6.0, 6.0.1</td> </tr> <tr> <td>CVE-2016-5131</td> - <td>A-36554209</td> + <td><a href="https://android.googlesource.com/platform/external/libxml2/+/0eff71008becb7f2c2b4509708da4b79985948bb">A-36554209</a></td> <td>RCE</td> <td>High</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2016-4658</td> - <td>A-36554207</td> + <td><a href="https://android.googlesource.com/platform/external/libxml2/+/8ea80f29ea5fdf383ee3ae59ce35e55421a339f8">A-36554207</a></td> <td>RCE</td> <td>High</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0663</td> - <td>A-37104170</td> + <td><a href="https://android.googlesource.com/platform/external/libxml2/+/521b88fbb6d18312923f0df653d045384b500ffc">A-37104170</a></td> <td>RCE</td> <td>High</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-7376</td> - <td>A-36555370</td> + <td><a href="https://android.googlesource.com/platform/external/libxml2/+/51e0cb2e5ec18eaf6fb331bc573ff27b743898f4">A-36555370</a></td> <td>RCE</td> <td>High</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-5056</td> - <td>A-36809819</td> + <td><a href="https://android.googlesource.com/platform/external/libxml2/+/3f571b1bb85cf56903f06bab3a820182115c5541">A-36809819</a></td> <td>RCE</td> <td>Moderate</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-7375</td> - <td>A-36556310</td> + <td><a href="https://android.googlesource.com/platform/external/libxml2/+/308396a55280f69ad4112d4f9892f4cbeff042aa">A-36556310</a></td> <td>RCE</td> <td>Moderate</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0647</td> - <td>A-36392138</td> + <td><a href="https://android.googlesource.com/platform/system/core/+/3d6a43155c702bce0e7e2a93a67247b5ce3946a5">A-36392138</a></td> <td>ID</td> <td>Moderate</td> <td>5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2016-1839</td> - <td>A-36553781</td> + <td><a href="https://android.googlesource.com/platform/external/libxml2/+/ff20cd797822dba8569ee518c44e6864d6b4ebfa">A-36553781</a></td> <td>DoS</td> <td>Moderate</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> @@ -261,49 +261,49 @@ data processing.</p> </tr> <tr> <td>CVE-2017-0637</td> - <td>A-34064500</td> + <td><a href="https://android.googlesource.com/platform/external/libhevc/+/ebaa71da6362c497310377df509651974401d258">A-34064500</a></td> <td>RCE</td> <td>Critical</td> <td>5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0391</td> - <td>A-32322258</td> + <td><a href="https://android.googlesource.com/platform/external/libhevc/+/14bc1678a80af5be7401cf750ab762ae8c75cc5a">A-32322258</a></td> <td>DoS</td> <td>High</td> <td>5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0640</td> - <td>A-33129467</td> + <td>A-33129467<a href="#asterisk">*</a></td> <td>DoS</td> <td>High</td> <td>6.0, 6.0.1, 7.0, 7.1.1</td> </tr> <tr> <td>CVE-2017-0641</td> - <td>A-34360591</td> + <td><a href="https://android.googlesource.com/platform/external/libvpx/+/698796fc930baecf5c3fdebef17e73d5d9a58bcb">A-34360591</a></td> <td>DoS</td> <td>High</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0642</td> - <td>A-34819017</td> + <td><a href="https://android.googlesource.com/platform/external/libhevc/+/913d9e8d93d6b81bb8eac3fc2c1426651f5b259d">A-34819017</a></td> <td>DoS</td> <td>High</td> <td>5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0643</td> - <td>A-35645051</td> + <td>A-35645051<a href="#asterisk">*</a></td> <td>DoS</td> <td>High</td> <td>5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1</td> </tr> <tr> <td>CVE-2017-0644</td> - <td>A-35472997</td> + <td>A-35472997<a href="#asterisk">*</a></td> <td>DoS</td> <td>High</td> <td>4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1</td> @@ -329,7 +329,7 @@ unprivileged process.</p> </tr> <tr> <td>CVE-2017-0638</td> - <td>A-36368305</td> + <td><a href="https://android.googlesource.com/platform/external/libgdx/+/a98943dd4aece3024f023f00256607d50dcbcd1e">A-36368305</a></td> <td>RCE</td> <td>High</td> <td>7.1.1, 7.1.2</td> @@ -400,7 +400,7 @@ using a specially crafted file to gain access to sensitive information.</p> </tr> <tr> <td>CVE-2015-7995</td> - <td>A-36810065</td> + <td>A-36810065<a href="#asterisk">*</a></td> <td>ID</td> <td>Moderate</td> <td>4.4.4</td> @@ -1395,6 +1395,11 @@ site</a>.</p> <td>June 5, 2017</td> <td>Bulletin published.</td> </tr> + <tr> + <td>1.1</td> + <td>June 7, 2017</td> + <td>Bulletin revised to include AOSP links.</td> + </tr> </table> </body> </html> diff --git a/en/security/encryption/file-based.html b/en/security/encryption/file-based.html index f1471519..37750fa0 100644 --- a/en/security/encryption/file-based.html +++ b/en/security/encryption/file-based.html @@ -254,7 +254,9 @@ into FBE mode as is the case in the developer preview. It is also possible to enable FBE from fastboot using this command: </p> <p> -<code>$ fastboot --wipe-and-use-fbe</code> +<pre class="devsite-terminal devsite-click-to-copy"> +fastboot --wipe-and-use-fbe +</pre> </p> <p> This is intended solely for development purposes as a platform for demonstrating @@ -302,9 +304,7 @@ created and the encryption policy links these keys to those directories. In the current AOSP implementation, the encryption policy is hardcoded into this location: </p> -<p> -<code>/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp</code> -</p> +<pre class="devsite-click-to-copy">/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp</pre> <p> It is possible to add exceptions in this file to prevent certain directories from being encrypted at all, by adding to the <code>directories_to_exclude</code> @@ -330,7 +330,7 @@ can be set at the application level. The system apps. The <code>directBootAware</code> attribute is available to all. </p> -<pre> +<pre class="devsite-click-to-copy"> <application android:directBootAware="true" android:defaultToDeviceProtectedStorage="true"> @@ -422,8 +422,8 @@ order to test with <a hre="https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/plain/quick-start?h=META"> xfstest</a> by using: </p> -<pre> -$ kvm-xfstests -c encrypt -g auto +<pre class="devsite-terminal devsite-click-to-copy"> +kvm-xfstests -c encrypt -g auto </pre> <p> In addition, device manufacturers may perform these manual tests. On a device diff --git a/en/security/encryption/full-disk.html b/en/security/encryption/full-disk.html index 21ede79b..a855b650 100644 --- a/en/security/encryption/full-disk.html +++ b/en/security/encryption/full-disk.html @@ -615,7 +615,7 @@ lost, and give the user a button to reboot the system.</td> </table> <h2 id=init_actions>Init actions</h2> -<pre> +<pre class="devsite-click-to-copy"> on post-fs-data on nonencrypted on property:vold.decrypt=trigger_reset_main diff --git a/en/security/keystore/implementer-ref.html b/en/security/keystore/implementer-ref.html index 16f56b88..c0b2ad93 100644 --- a/en/security/keystore/implementer-ref.html +++ b/en/security/keystore/implementer-ref.html @@ -37,7 +37,7 @@ key generation to specify key characteristics.</p> <p>Possible values are defined by the following enumeration:</p> -<pre> +<pre class="devsite-click-to-copy"> typedef enum { KM_PURPOSE_ENCRYPT = 0, KM_PURPOSE_DECRYPT = 1, @@ -58,7 +58,7 @@ key, the operation must fail with <code>KM_ERROR_INCOMPATIBLE_PURPOSE</code>.</p <p>Possible values are defined by the following enumeration:</p> -<pre> +<pre class="devsite-click-to-copy"> typedef enum { KM_ALGORITHM_RSA = 1, KM_ALGORITHM_EC = 3, @@ -85,7 +85,7 @@ only relevant to AES keys.</p> <p>Possible values are defined by the following enumeration:</p> -<pre> +<pre class="devsite-click-to-copy"> typedef enum { KM_MODE_ECB = 1, KM_MODE_CBC = 2, @@ -107,7 +107,7 @@ HMAC keys.</p> <p>Possible values are defined by the following enumeration:</p> -<pre> +<pre class="devsite-click-to-copy"> typedef enum { KM_DIGEST_NONE = 0, KM_DIGEST_MD5 = 1, @@ -132,7 +132,7 @@ relevant to RSA and AES keys.</p> <p>Possible values are defined by the following enumeration:</p> -<pre> +<pre class="devsite-click-to-copy"> typedef enum { KM_PAD_NONE = 1, KM_PAD_RSA_OAEP = 2, @@ -210,7 +210,7 @@ key to be used.</p> <p>Possible values are defined by the following enumeration:</p> -<pre> +<pre class="devsite-click-to-copy"> typedef enum { KM_BLOB_STANDALONE = 0, KM_BLOB_REQUIRES_FILE_SYSTEM = 1, @@ -357,7 +357,7 @@ network-ordered integers to host-ordered integers and <p>The value is a 32-bit integer bitmask of values from the enumeration:</p> -<pre> +<pre class="devsite-click-to-copy"> typedef enum { HW_AUTH_NONE = 0, HW_AUTH_PASSWORD = 1 << 0, @@ -445,7 +445,7 @@ by the trustlet.</p> <p>The possible values are defined in <code>keymaster_origin_t</code>:</p> -<pre> +<pre class="devsite-click-to-copy"> typedef enum { KM_ORIGIN_GENERATED = 0, KM_ORIGIN_IMPORTED = 2, diff --git a/en/security/keystore/index.html b/en/security/keystore/index.html index 54a6f83b..8ce4b7a4 100644 --- a/en/security/keystore/index.html +++ b/en/security/keystore/index.html @@ -73,7 +73,7 @@ reached through some kernel interface. The resulting architecture looks like the following:</p> <div align="center"> - <img src="../images/access-to-keymaster.png" alt="Access to Keymaster" id="figure1" /> + <img src="/security/images/access-to-keymaster.png" alt="Access to Keymaster" id="figure1" /> </div> <p class="img-caption"><strong>Figure 1.</strong> Access to Keymaster</p> diff --git a/en/security/selinux/concepts.html b/en/security/selinux/concepts.html index 543a1dc4..227a3c53 100644 --- a/en/security/selinux/concepts.html +++ b/en/security/selinux/concepts.html @@ -116,7 +116,9 @@ for each class are represented by permissions. </p> </ul> <p>And so an example use of this would follow the structure:</p> -<code>allow appdomain app_data_file:file rw_file_perms;</code> +<pre class="devsite-click-to-copy"> +allow appdomain app_data_file:file rw_file_perms; +</pre> <p>This says that all application domains are allowed to read and write files labeled app_data_file. Note that this rule relies upon macros defined in the @@ -129,13 +131,13 @@ failures due to denials on related permissions.</p> <p>Use the syntax above to create avc rules that comprise the essence of an SELinux policy. A rule takes the form: -<pre> -<rule variant> <source_types> <target_types> : <classes> <permissions> +<pre class="devsite-click-to-copy"> +<var>RULE_VARIANT SOURCE_TYPES TARGET_TYPES</var> : <var>CLASSES PERMISSIONS</var> </pre> <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> -<pre> +<pre class="devsite-click-to-copy"> allow domain null_device:chr_file { open }; </pre> @@ -143,7 +145,7 @@ allow domain null_device:chr_file { open }; <p> 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> -<pre> +<pre class="devsite-click-to-copy"> allow domain null_device:chr_file { getattr open read ioctl lock append write}; </pre> diff --git a/en/security/selinux/customize.html b/en/security/selinux/customize.html index c8ead37c..294d4040 100644 --- a/en/security/selinux/customize.html +++ b/en/security/selinux/customize.html @@ -100,7 +100,7 @@ should supply the modifications to the default SELinux policy as a <a href="/sou <p>In the following example, all domains are granted access to read from or write to <code>/dev/null</code> and read from <code>/dev/zero</code>.</p> -<pre> +<pre class="devsite-click-to-copy"> # Allow read / write access to /dev/null allow domain null_device:chr_file { getattr open read ioctl lock append write}; @@ -111,7 +111,7 @@ allow domain zero_device:chr_file { getattr open read ioctl lock }; <p>This same statement can be written with SELinux <code>*_file_perms</code> macros (shorthand):</p> -<pre> +<pre class="devsite-click-to-copy"> # Allow read / write access to /dev/null allow domain null_device:chr_file rw_file_perms; @@ -123,7 +123,7 @@ allow domain zero_device:chr_file r_file_perms; <p>Here is a complete example policy for DHCP, which we examine below:</p> -<pre> +<pre class="devsite-click-to-copy"> type dhcp, domain; permissive dhcp; type dhcp_exec, exec_type, file_type; diff --git a/en/security/selinux/device-policy.html b/en/security/selinux/device-policy.html index 82e6c4b1..6fe8b209 100644 --- a/en/security/selinux/device-policy.html +++ b/en/security/selinux/device-policy.html @@ -62,7 +62,9 @@ After modifying the command line, perform <code>make clean</code>, then <p>After that, confirm permissive mode with:</p> -<p><code>adb getenforce</code></p> +<pre class="devsite-terminal devsite-click-to-copy"> +adb getenforce +</pre> <p>Two weeks is a reasonable amount of time to be in global permissive mode. After @@ -104,7 +106,7 @@ scratch on a new device, which include:</p> <p>Denials generated by core services are typically addressed by file labeling. For example:</p> -<pre class="no-pretty-print"> +<pre> avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0” dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1 @@ -164,7 +166,7 @@ permissions.</p> <p>The service is launched in our device’s <code>init.<target>.rc</code> file as:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> service foo /system/bin/foo class core </pre> @@ -175,7 +177,7 @@ service foo /system/bin/foo <p>Create the file <code>device/<oem>/<target>/sepolicy/foo.te</code> with the following contents:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> # foo service type foo, domain; type foo_exec, exec_type, file_type; @@ -193,7 +195,7 @@ init_daemon_domain(foo) <p>Add the following to <code>device/<oem>/<target>/sepolicy/ file_contexts</code>:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> /system/bin/foo u:object_r:foo_exec:s0 </pre> @@ -231,7 +233,7 @@ device-specific policies.</p> <p>The following example rule is like locking the front door but leaving the windows open:</p> -<p><code>allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms</code>.</p> +<pre>allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms</pre> <p>The intent is clear: everyone but third-party apps may have access to the debug device. </p> diff --git a/en/security/selinux/implement.html b/en/security/selinux/implement.html index e899eb4d..11473906 100644 --- a/en/security/selinux/implement.html +++ b/en/security/selinux/implement.html @@ -127,7 +127,7 @@ containing the sepolicy subdirectory - to reference the sepolicy subdirectory and each policy file once created, as shown below. The BOARD_SEPOLICY variables and their meaning is documented in the system/sepolicy/README file.</p> -<pre> +<pre class="devsite-click-to-copy"> BOARD_SEPOLICY_DIRS += \ <root>/device/manufacturer/device-name/sepolicy @@ -195,7 +195,9 @@ SELinux to protect your devices:</p> <li>Enable SELinux in the kernel: <code>CONFIG_SECURITY_SELINUX=y</code> <li>Change the kernel_cmdline parameter so that:<br/> -<code>BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive</code>. +<pre class="devsite-click-to-copy"> +BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive +</pre> <br/> This is only for initial development of policy for the device. Once you have an initial bootstrap policy, remove this parameter so that your device is @@ -203,10 +205,14 @@ enforcing or it will fail CTS. <li>Boot up the system in permissive and see what denials are encountered on boot:<br/> On Ubuntu 14.04 or newer: <br/> -<code>adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/<em>board</em>/root/sepolicy</code> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/<var>BOARD</var>/root/sepolicy +</pre> <br/> -On Ubuntu 12.04: -<code>adb shell su -c dmesg | grep denied | audit2allow</code> +On Ubuntu 12.04:<br/> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell su -c dmesg | grep denied | audit2allow +</pre> <li>Evaluate the output. See <a href="validate.html">Validation</a> for instructions and tools. <li>Identify devices, and other new files that need labeling. <li>Use existing or new labels for your objects. @@ -216,8 +222,12 @@ to assign a new one. Ideally, this will be an existing label which will fit into policy, but sometimes a new label will be needed, and rules for access to that label will be needed, as well. <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/> -<code>$ adb shell su -c ps -Z | grep init</code><br/> -<code>$ adb shell su -c dmesg | grep 'avc: '</code> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell su -c ps -Z | grep init +</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell su -c dmesg | grep 'avc: ' +</pre> <li>Review init.<device>.rc to identify any which are without a type. These should be given domains EARLY in order to avoid adding rules to init or otherwise diff --git a/en/security/selinux/validate.html b/en/security/selinux/validate.html index ba3e6ec8..93ecc050 100644 --- a/en/security/selinux/validate.html +++ b/en/security/selinux/validate.html @@ -73,9 +73,9 @@ run at the time the denial was generated. In this case, it’s a pretty good hin </ul> <p>And here is another example:</p> - +<pre class="devsite-terminal devsite-click-to-copy">adb shell su root dmesg | grep 'avc: '</pre> +<p>Output:</p> <pre> -$ adb shell su root dmesg | grep 'avc: ' <5> type=1400 audit: avc: denied { read write } for pid=177 comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0 tcontext=u:object_r:kmem_device:s0 tclass=chr_file @@ -101,18 +101,18 @@ tcontext=u:object_r:kmem_device:s0 tclass=chr_file on production devices. CTS tests confirm enforcing mode is enabled.</p> -<p>To turn a device’s SELinux enforcement into globally permissive via ADB, as -root issue:</p> - -<pre> -$ adb shell su root setenforce 0 +<p>SELinux enforcement can be disabled via ADB on userdebug or eng builds. To do so, +first switch ADB to root by running <code>adb root</code>. Then, to disable SELinux +enforcement, run: +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell setenforce 0 </pre> <p>Or at the kernel command line (during early device bring-up):</p> -<pre> -androidboot.selinux=permissive -androidboot.selinux=enforcing +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">androidboot.selinux=permissive</code> +<code class="devsite-terminal">androidboot.selinux=enforcing</code> </pre> <h2 id=using_audit2allow>Using audit2allow</h2> @@ -125,8 +125,8 @@ is compiled automatically when you build Android from source.</p> <p>To use it, run:</p> -<pre> -$ adb shell su root dmesg | audit2allow -p $OUT/root/sepolicy +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell su root dmesg | audit2allow -p $OUT/root/sepolicy </pre> <p>Nevertheless, care must be taken to examine each potential addition for diff --git a/en/security/trusty/index.html b/en/security/trusty/index.html index a6f60512..dbdba9a3 100644 --- a/en/security/trusty/index.html +++ b/en/security/trusty/index.html @@ -147,10 +147,10 @@ trusted by the user of the product on which the application runs.</p> <a href="https://android.googlesource.com/kernel/common/+/android-trusty-3.18">https://android.googlesource.com/kernel/common/+/android-trusty-3.18</a></p> <p>To make Trusty, run the following commands (assuming the Android toolchain is already in the path):</p> -<pre> -$ repo init -u https://android.googlesource.com/trusty/manifest -$ repo sync -$ make -j24 generic-arm64 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">repo init -u https://android.googlesource.com/trusty/manifest</code> +<code class="devsite-terminal">repo sync</code> +<code class="devsite-terminal">make -j24 generic-arm64</code> </pre> <p>You may select another supported build target from: <code>device/*/*/project/*</code></p> diff --git a/en/security/verifiedboot/dm-verity.html b/en/security/verifiedboot/dm-verity.html index 763b2e4c..07e7821d 100644 --- a/en/security/verifiedboot/dm-verity.html +++ b/en/security/verifiedboot/dm-verity.html @@ -82,7 +82,7 @@ integral to dm-verity. The <a href="https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity">cryptsetup</a> tool will generate a hash tree for you. Alternatively, a compatible one is defined here:</p> -<pre> +<pre class="devsite-click-to-copy"> <your block device name> <your block device name> <block size> <block size> <image size in blocks> <image size in blocks + 8> <root hash> <salt> </pre> diff --git a/en/security/verifiedboot/verified-boot.html b/en/security/verifiedboot/verified-boot.html index 856263de..e907dcb0 100644 --- a/en/security/verifiedboot/verified-boot.html +++ b/en/security/verifiedboot/verified-boot.html @@ -434,7 +434,7 @@ message, which can be parsed with a decoder similar to the one found at: <a href="https://android.googlesource.com/platform/bootable/recovery/+/f4a6ab27b335b69fbc419a9c1ef263004b561265/asn1_decoder.cpp">platform/bootable/recovery/asn1_decoder.cpp</a><br/> The message format itself is as follows:</p> -<pre> +<pre class="devsite-click-to-copy"> AndroidVerifiedBootSignature DEFINITIONS ::= BEGIN FormatVersion ::= INTEGER |