README 5.3 KB

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