b4f17069b3
With changes I431c1ab22fc53749f623937154b9ec43469d9645 and Ia54aa263f2245c7090f4b9d9703130c19f11bd28, it is no longer legitimate to use BOARD_SEPOLICY_IGNORE or REPLACE with any of the *_contexts files since the CTS requires the AOSP entries to be present in the device files. Further, these changes render BOARD_SEPOLICY_IGNORE unusable for most policy files since all domains and types referenced within any of the AOSP *_contexts entries must be defined in the kernel policy, so you cannot use BOARD_SEPOLICY_IGNORE to exclude any .te file that defines a type referenced in any of those *_contexts files. There does not seem to be a significant need for such a facility, as AOSP policy is small and only domains and types used by most devices should be defined in external/sepolicy. BOARD_SEPOLICY_REPLACE is commonly misused to eliminate neverallow rules from AOSP policy, which will only lead to CTS failures, especially since change Iefe508df265f62efa92f8eb74fc65542d39e3e74 introduced neverallow checking on the entire policy via sepolicy-analyze. The only remaining legitimate function of BOARD_SEPOLICY_REPLACE is to support overriding AOSP .te files with more restrictive rule sets. However, the need for this facility has been significantly reduced by the fact that AOSP policy is now fully confined + enforcing for all domains, and further restrictions beyond AOSP carry a compatibility risk. Builders of custom policies and custom ROMs still have the freedom to apply patches on top of external/sepolicy to tighten rule sets (which are likely more maintainable than maintaining a completely separate copy of the file via BOARD_SEPOLICY_REPLACE) and/or of using their own separate policy build system as exemplified by https://bitbucket.org/quarksecurity/build-policies Change-Id: I2611e983f7cbfa15f9d45ec3ea301e94132b06fa Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
101 lines
4.8 KiB
Text
101 lines
4.8 KiB
Text
This directory contains the core Android SELinux policy configuration.
|
|
It defines the domains and types for the AOSP services and apps common to
|
|
all devices. Device-specific policy should be placed under a
|
|
separate device/<vendor>/<board>/sepolicy subdirectory and linked
|
|
into the policy build as described below.
|
|
|
|
Policy Generation:
|
|
|
|
Additional, per device, policy files can be added into the
|
|
policy build.
|
|
|
|
They can be configured through the use of two variables,
|
|
they are:
|
|
1. BOARD_SEPOLICY_UNION
|
|
2. BOARD_SEPOLICY_DIRS
|
|
|
|
The variables should be set in the BoardConfig.mk file in
|
|
the device or vendor directories.
|
|
|
|
BOARD_SEPOLICY_UNION is a list of files that will be
|
|
"unioned", IE concatenated, at the END of their respective
|
|
file in external/sepolicy. Note, to add a unique file you
|
|
would use this variable.
|
|
|
|
BOARD_SEPOLICY_DIRS contains a list of directories to search
|
|
for BOARD_SEPOLICY_UNION files. Order matters in this list.
|
|
eg.) If you have BOARD_SEPOLICY_UNION += widget.te and have 2
|
|
instances of widget.te files on BOARD_SEPOLICY_DIRS search path.
|
|
The first one found (at the first search dir containing the file)
|
|
gets processed first.
|
|
Reviewing out/target/product/<device>/etc/sepolicy_intermediates/policy.conf
|
|
will help sort out ordering issues.
|
|
|
|
It is an error to specify a BOARD_POLICY_UNION file that
|
|
doesn't appear in any of the BOARD_SEPOLICY_DIRS locations.
|
|
|
|
Example BoardConfig.mk Usage:
|
|
From the Tuna device BoardConfig.mk, device/samsung/tuna/BoardConfig.mk
|
|
|
|
BOARD_SEPOLICY_DIRS += \
|
|
device/samsung/tuna/sepolicy
|
|
|
|
BOARD_SEPOLICY_UNION += \
|
|
genfs_contexts \
|
|
file_contexts \
|
|
sepolicy.te
|
|
|
|
SPECIFIC POLICY FILE INFORMATION
|
|
|
|
mac_permissions.xml:
|
|
ABOUT:
|
|
The mac_permissions.xml file is used for controlling the mmac solutions
|
|
as well as mapping a public base16 signing key with an arbitrary seinfo
|
|
string. Details of the files contents can be found in a comment at the
|
|
top of that file. The seinfo string, previously mentioned, is the same string
|
|
that is referenced in seapp_contexts.
|
|
|
|
This file can be appended to by using the BOARD_SEPOLICY_UNION
|
|
variable. It is important to note the final processed version of this file
|
|
is stripped of comments and whitespace. This is to preserve space on the
|
|
system.img. If one wishes to view it in a more human friendly format,
|
|
the "tidy" or "xmllint" command will assist you.
|
|
|
|
TOOLING:
|
|
insertkeys.py
|
|
Is a helper script for mapping arbitrary tags in the signature stanzas of
|
|
mac_permissions.xml to public keys found in pem files. This script takes
|
|
a mac_permissions.xml file(s) and configuration file in order to operate.
|
|
Details of the configuration file (keys.conf) can be found in the subsection
|
|
keys.conf. This tool is also responsible for stripping the comments and
|
|
whitespace during processing.
|
|
|
|
keys.conf
|
|
The keys.conf file is used for controlling the mapping of "tags" found in
|
|
the mac_permissions.xml signature stanzas with actual public keys found in
|
|
pem files. The configuration file can be used in BOARD_SEPOLICY_UNION
|
|
variables and is processed via m4.
|
|
|
|
The script allows for mapping any string contained in TARGET_BUILD_VARIANT
|
|
with specific path to a pem file. Typically TARGET_BUILD_VARIANT is either
|
|
user, eng or userdebug. Additionally, one can specify "ALL" to map a path to
|
|
any string specified in TARGET_BUILD_VARIANT. All tags are matched verbatim
|
|
and all options are matched lowercase. The options are "tolowered" automatically
|
|
for the user, it is convention to specify tags and options in all uppercase
|
|
and tags start with @. The option arguments can also use environment variables
|
|
via the familiar $VARIABLE syntax. This is often useful for setting a location
|
|
to ones release keys.
|
|
|
|
Often times, one will need to integrate an application that was signed by a separate
|
|
organization and may need to extract the pem file for the insertkeys/keys.conf tools.
|
|
Extraction of the public key in the pem format is possible via openssl. First you need
|
|
to unzip the apk, once it is unzipped, cd into the META_INF directory and then execute
|
|
openssl pkcs7 -inform DER -in CERT.RSA -out CERT.pem -outform PEM -print_certs
|
|
On some occasions CERT.RSA has a different name, and you will need to adjust for that.
|
|
After extracting the pem, you can rename it, and configure keys.conf and
|
|
mac_permissions.xml to pick up the change. You MUST open the generated pem file in a text
|
|
editor and strip out anything outside the opening and closing scissor lines. Failure to do
|
|
so WILL cause a compile time issue thrown by insertkeys.py
|
|
|
|
NOTE: The pem files are base64 encoded and PackageManagerService, mac_permissions.xml
|
|
and setool all use base16 encodings.
|