1This directory contains the core Android SELinux policy configuration. 2It defines the domains and types for the AOSP services and apps common to 3all devices. Device-specific policy should be placed under a 4separate device/<vendor>/<board>/sepolicy subdirectory and linked 5into the policy build as described below. 6 7Policy Generation: 8 9Additional, per device, policy files can be added into the 10policy build. These files should have each line including the 11final line terminated by a newline character (0x0A). This 12will allow files to be concatenated and processed whenever 13the m4(1) macro processor is called by the build process. 14Adding the newline will also make the intermediate text files 15easier to read when debugging build failures. The sets of file, 16service and property contexts files will automatically have a 17newline inserted between each file as these are common failure 18points. 19 20These device policy files can be configured through the use of 21the BOARD_VENDOR_SEPOLICY_DIRS variable. This variable should be set 22in the BoardConfig.mk file in the device or vendor directories. 23 24BOARD_VENDOR_SEPOLICY_DIRS contains a list of directories to search 25for additional policy files. Order matters in this list. 26For example, if you have 2 instances of widget.te files in the 27BOARD_VENDOR_SEPOLICY_DIRS search path, then the first one found (at the 28first search dir containing the file) will be concatenated first. 29Reviewing out/target/product/<device>/obj/ETC/sepolicy_intermediates/policy.conf 30will help sort out ordering issues. 31 32Example BoardConfig.mk Usage: 33From the Tuna device BoardConfig.mk, device/samsung/tuna/BoardConfig.mk 34 35BOARD_VENDOR_SEPOLICY_DIRS += device/samsung/tuna/sepolicy 36 37Alongside vendor sepolicy dirs, OEMs can also amend the public and private 38policy of the product and system_ext partitions: 39 40SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS += device/acme/roadrunner-sepolicy/systemext/public 41SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS += device/acme/roadrunner-sepolicy/systemext/private 42PRODUCT_PUBLIC_SEPOLICY_DIRS += device/acme/roadrunner-sepolicy/product/public 43PRODUCT_PRIVATE_SEPOLICY_DIRS += device/acme/roadrunner-sepolicy/product/private 44 45The old BOARD_PLAT_PUBLIC_SEPOLICY_DIR and BOARD_PLAT_PRIVATE_SEPOLICY_DIR 46variables have been deprecated in favour of SYSTEM_EXT_*. 47 48Additionally, OEMs can specify BOARD_SEPOLICY_M4DEFS to pass arbitrary m4 49definitions during the build. A definition consists of a string in the form 50of macro-name=value. Spaces must NOT be present. This is useful for building modular 51policies, policy generation, conditional file paths, etc. It is supported in 52the following file types: 53 * All *.te and SE Linux policy files as passed to checkpolicy 54 * file_contexts 55 * service_contexts 56 * property_contexts 57 * keys.conf 58 59Example BoardConfig.mk Usage: 60BOARD_SEPOLICY_M4DEFS += btmodule=foomatic \ 61 btdevice=/dev/gps 62 63SPECIFIC POLICY FILE INFORMATION 64 65mac_permissions.xml: 66 ABOUT: 67 The mac_permissions.xml file is used for controlling the mmac solutions 68 as well as mapping a public base16 signing key with an arbitrary seinfo 69 string. Details of the files contents can be found in a comment at the 70 top of that file. The seinfo string, previously mentioned, is the same string 71 that is referenced in seapp_contexts. 72 73 It is important to note the final processed version of this file 74 is stripped of comments and whitespace. This is to preserve space on the 75 system.img. If one wishes to view it in a more human friendly format, 76 the "tidy" or "xmllint" command will assist you. 77 78 TOOLING: 79 insertkeys.py 80 Is a helper script for mapping arbitrary tags in the signature stanzas of 81 mac_permissions.xml to public keys found in pem files. This script takes 82 a mac_permissions.xml file(s) and configuration file in order to operate. 83 Details of the configuration file (keys.conf) can be found in the subsection 84 keys.conf. This tool is also responsible for stripping the comments and 85 whitespace during processing. 86 87 keys.conf 88 The keys.conf file is used for controlling the mapping of "tags" found in 89 the mac_permissions.xml signature stanzas with actual public keys found in 90 pem files. The configuration file is processed via m4. 91 92 The script allows for mapping any string contained in TARGET_BUILD_VARIANT 93 with specific path to a pem file. Typically TARGET_BUILD_VARIANT is either 94 user, eng or userdebug. Additionally, one can specify "ALL" to map a path to 95 any string specified in TARGET_BUILD_VARIANT. All tags are matched verbatim 96 and all options are matched lowercase. The options are "tolowered" automatically 97 for the user, it is convention to specify tags and options in all uppercase 98 and tags start with @. The option arguments can also use environment variables 99 via the familiar $VARIABLE syntax. This is often useful for setting a location 100 to ones release keys. 101 102 Often times, one will need to integrate an application that was signed by a separate 103 organization and may need to extract the pem file for the insertkeys/keys.conf tools. 104 Extraction of the public key in the pem format is possible via openssl. First you need 105 to unzip the apk, once it is unzipped, cd into the META_INF directory and then execute 106 openssl pkcs7 -inform DER -in CERT.RSA -out CERT.pem -outform PEM -print_certs 107 On some occasions CERT.RSA has a different name, and you will need to adjust for that. 108 After extracting the pem, you can rename it, and configure keys.conf and 109 mac_permissions.xml to pick up the change. You MUST open the generated pem file in a text 110 editor and strip out anything outside the opening and closing scissor lines. Failure to do 111 so WILL cause a compile time issue thrown by insertkeys.py 112 113 NOTE: The pem files are base64 encoded and PackageManagerService, mac_permissions.xml 114 and setool all use base16 encodings. 115