1 This directory contains a number of tools related to policy, some of 2 which are used in building and validating the policy and others are 3 available for help in auditing and analyzing policy. The tools are 4 described further below. 5 6 checkfc 7 A utility for checking the validity of a file_contexts or a 8 property_contexts configuration file. Used as part of the policy 9 build to validate both files. Requires the sepolicy file as an 10 argument in order to check the validity of the security contexts 11 in the file_contexts or property_contexts file. 12 13 Usage: 14 checkfc sepolicy file_contexts 15 checkfc -p sepolicy property_contexts 16 17 checkseapp 18 A utility for merging together the main seapp_contexts 19 configuration and the device-specific one, and simultaneously 20 checking the validity of the configurations. Used as part of the 21 policy build process to merge and validate the configuration. 22 23 Usage: 24 checkseapp -p sepolicy input_seapp_contexts0 [input_seapp_contexts1...] -o seapp_contexts 25 26 insertkeys.py 27 A helper script for mapping tags in the signature stanzas of 28 mac_permissions.xml to public keys found in pem files. This 29 script is described further in the top-level sepolicy/README. 30 31 post_process_mac_perms 32 A tool to help modify an existing mac_permissions.xml with additional app 33 certs not already found in that policy. This becomes useful when a directory 34 containing apps is searched and the certs from those apps are added to the 35 policy not already explicitly listed. 36 37 Usage: 38 post_process_mac_perms [-h] -s SEINFO -d DIR -f POLICY 39 40 -s SEINFO, --seinfo SEINFO seinfo tag for each generated stanza 41 -d DIR, --dir DIR Directory to search for apks 42 -f POLICY, --file POLICY mac_permissions.xml policy file 43 44 sepolicy-check 45 A tool for auditing a sepolicy file for any allow rule that grants 46 a given permission. 47 48 Usage: 49 sepolicy-check -s <domain> -t <type> -c <class> -p <permission> -P out/target/product/<board>/root/sepolicy 50 51 sepolicy-analyze 52 A tool for performing various kinds of analysis on a sepolicy 53 file. The current kinds of analysis that are currently supported 54 include: 55 56 TYPE EQUIVALENCE 57 sepolicy-analyze -e -P out/target/product/<board>/root/sepolicy 58 59 Display all type pairs that are "equivalent", i.e. they are 60 identical with respect to allow rules, including indirect allow 61 rules via attributes and default-enabled conditional rules 62 (i.e. default boolean values yield a true conditional expression). 63 64 Equivalent types are candidates for being coalesced into a single 65 type. However, there may be legitimate reasons for them to remain 66 separate, for example: - the types may differ in a respect not 67 included in the current analysis, such as default-disabled 68 conditional rules, audit-related rules (auditallow or dontaudit), 69 default type transitions, or constraints (e.g. mls), or - the 70 current policy may be overly permissive with respect to one or the 71 other of the types and thus the correct action may be to tighten 72 access to one or the other rather than coalescing them together, 73 or - the domains that would in fact have different accesses to the 74 types may not yet be defined or may be unconfined in the policy 75 you are analyzing. 76 77 TYPE DIFFERENCE 78 sepolicy-analyze -d -P out/target/product/<board>/root/sepolicy 79 80 Display type pairs that differ and the first difference found 81 between the two types. This may be used in looking for similar 82 types that are not equivalent but may be candidates for coalescing. 83 84 DUPLICATE ALLOW RULES 85 sepolicy-analyze -D -P out/target/product/<board>/root/sepolicy 86 87 Displays duplicate allow rules, i.e. pairs of allow rules that 88 grant the same permissions where one allow rule is written 89 directly in terms of individual types and the other is written in 90 terms of attributes associated with those same types. The rule 91 with individual types is a candidate for removal. The rule with 92 individual types may be directly represented in the source policy 93 or may be a result of expansion of a type negation (e.g. domain 94 -foo -bar is expanded to individual allow rules by the policy 95 compiler). Domains with unconfineddomain will typically have such 96 duplicate rules as a natural side effect and can be ignored. 97
