android_system_sepolicy/tools/Android.mk

63 lines
1.4 KiB
Makefile
Raw Normal View History

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := checkseapp
LOCAL_MODULE_TAGS := optional
LOCAL_CFLAGS := -DLINK_SEPOL_STATIC -Wall -Werror
LOCAL_SRC_FILES := check_seapp.c
LOCAL_STATIC_LIBRARIES := libsepol
LOCAL_WHOLE_STATIC_LIBRARIES := libpcre2
LOCAL_CXX_STL := none
include $(BUILD_HOST_EXECUTABLE)
###################################
include $(CLEAR_VARS)
LOCAL_MODULE := checkfc
LOCAL_MODULE_TAGS := optional
Add sepolicy-analyze tool. And also remove the unnecessary references to libselinux for sepolicy-check, as it has no dependencies on libselinux. Also enable -Wall -Werror on building all of these tools and fix up all such errors. Usage: $ sepolicy-analyze -e -P out/target/product/<device>/root/sepolicy or $ sepolicy-analyze -d -P out/target/product/<device>/root/sepolicy The first form will display all type pairs that are "equivalent", i.e. they are identical with respect to allow rules, including indirect allow rules via attributes and default-enabled conditional rules (i.e. default boolean values yield a true conditional expression). Equivalent types are candidates for being coalesced into a single type. However, there may be legitimate reasons for them to remain separate, for example: - the types may differ in a respect not included in the current analysis, such as default-disabled conditional rules, audit-related rules (auditallow or dontaudit), default type transitions, or constraints (e.g. mls), or - the current policy may be overly permissive with respect to one or the other of the types and thus the correct action may be to tighten access to one or the other rather than coalescing them together, or - the domains that would in fact have different accesses to the types may not yet be defined or may be unconfined in the policy you are analyzing (e.g. in AOSP policy). The second form will display type pairs that differ and the first difference found between the two types. This output can be long. We have plans to explore further enhancements to this tool, including support for identifying isomorphic types. That will be required to identify similar domains since all domains differ in at least their entrypoint type and in their tmpfs type and thus will never show up as equivalent even if they are in all other respects identical to each other. Change-Id: If0ee00188469d2a1e165fdd52f235c705d22cd4e Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2013-10-31 06:22:26 -07:00
LOCAL_CFLAGS := -Wall -Werror
LOCAL_SRC_FILES := checkfc.c
LOCAL_STATIC_LIBRARIES := libsepol libselinux
LOCAL_CXX_STL := none
include $(BUILD_HOST_EXECUTABLE)
##################################
include $(CLEAR_VARS)
LOCAL_MODULE := insertkeys.py
LOCAL_SRC_FILES := insertkeys.py
LOCAL_MODULE_CLASS := EXECUTABLES
LOCAL_IS_HOST_MODULE := true
LOCAL_MODULE_TAGS := optional
include $(BUILD_PREBUILT)
###################################
include $(CLEAR_VARS)
LOCAL_MODULE := sepolicy-check
LOCAL_MODULE_TAGS := optional
Add sepolicy-analyze tool. And also remove the unnecessary references to libselinux for sepolicy-check, as it has no dependencies on libselinux. Also enable -Wall -Werror on building all of these tools and fix up all such errors. Usage: $ sepolicy-analyze -e -P out/target/product/<device>/root/sepolicy or $ sepolicy-analyze -d -P out/target/product/<device>/root/sepolicy The first form will display all type pairs that are "equivalent", i.e. they are identical with respect to allow rules, including indirect allow rules via attributes and default-enabled conditional rules (i.e. default boolean values yield a true conditional expression). Equivalent types are candidates for being coalesced into a single type. However, there may be legitimate reasons for them to remain separate, for example: - the types may differ in a respect not included in the current analysis, such as default-disabled conditional rules, audit-related rules (auditallow or dontaudit), default type transitions, or constraints (e.g. mls), or - the current policy may be overly permissive with respect to one or the other of the types and thus the correct action may be to tighten access to one or the other rather than coalescing them together, or - the domains that would in fact have different accesses to the types may not yet be defined or may be unconfined in the policy you are analyzing (e.g. in AOSP policy). The second form will display type pairs that differ and the first difference found between the two types. This output can be long. We have plans to explore further enhancements to this tool, including support for identifying isomorphic types. That will be required to identify similar domains since all domains differ in at least their entrypoint type and in their tmpfs type and thus will never show up as equivalent even if they are in all other respects identical to each other. Change-Id: If0ee00188469d2a1e165fdd52f235c705d22cd4e Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2013-10-31 06:22:26 -07:00
LOCAL_CFLAGS := -Wall -Werror
LOCAL_SRC_FILES := sepolicy-check.c
Add sepolicy-analyze tool. And also remove the unnecessary references to libselinux for sepolicy-check, as it has no dependencies on libselinux. Also enable -Wall -Werror on building all of these tools and fix up all such errors. Usage: $ sepolicy-analyze -e -P out/target/product/<device>/root/sepolicy or $ sepolicy-analyze -d -P out/target/product/<device>/root/sepolicy The first form will display all type pairs that are "equivalent", i.e. they are identical with respect to allow rules, including indirect allow rules via attributes and default-enabled conditional rules (i.e. default boolean values yield a true conditional expression). Equivalent types are candidates for being coalesced into a single type. However, there may be legitimate reasons for them to remain separate, for example: - the types may differ in a respect not included in the current analysis, such as default-disabled conditional rules, audit-related rules (auditallow or dontaudit), default type transitions, or constraints (e.g. mls), or - the current policy may be overly permissive with respect to one or the other of the types and thus the correct action may be to tighten access to one or the other rather than coalescing them together, or - the domains that would in fact have different accesses to the types may not yet be defined or may be unconfined in the policy you are analyzing (e.g. in AOSP policy). The second form will display type pairs that differ and the first difference found between the two types. This output can be long. We have plans to explore further enhancements to this tool, including support for identifying isomorphic types. That will be required to identify similar domains since all domains differ in at least their entrypoint type and in their tmpfs type and thus will never show up as equivalent even if they are in all other respects identical to each other. Change-Id: If0ee00188469d2a1e165fdd52f235c705d22cd4e Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2013-10-31 06:22:26 -07:00
LOCAL_STATIC_LIBRARIES := libsepol
LOCAL_CXX_STL := none
Add sepolicy-analyze tool. And also remove the unnecessary references to libselinux for sepolicy-check, as it has no dependencies on libselinux. Also enable -Wall -Werror on building all of these tools and fix up all such errors. Usage: $ sepolicy-analyze -e -P out/target/product/<device>/root/sepolicy or $ sepolicy-analyze -d -P out/target/product/<device>/root/sepolicy The first form will display all type pairs that are "equivalent", i.e. they are identical with respect to allow rules, including indirect allow rules via attributes and default-enabled conditional rules (i.e. default boolean values yield a true conditional expression). Equivalent types are candidates for being coalesced into a single type. However, there may be legitimate reasons for them to remain separate, for example: - the types may differ in a respect not included in the current analysis, such as default-disabled conditional rules, audit-related rules (auditallow or dontaudit), default type transitions, or constraints (e.g. mls), or - the current policy may be overly permissive with respect to one or the other of the types and thus the correct action may be to tighten access to one or the other rather than coalescing them together, or - the domains that would in fact have different accesses to the types may not yet be defined or may be unconfined in the policy you are analyzing (e.g. in AOSP policy). The second form will display type pairs that differ and the first difference found between the two types. This output can be long. We have plans to explore further enhancements to this tool, including support for identifying isomorphic types. That will be required to identify similar domains since all domains differ in at least their entrypoint type and in their tmpfs type and thus will never show up as equivalent even if they are in all other respects identical to each other. Change-Id: If0ee00188469d2a1e165fdd52f235c705d22cd4e Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2013-10-31 06:22:26 -07:00
include $(BUILD_HOST_EXECUTABLE)
###################################
include $(CLEAR_VARS)
LOCAL_MODULE := version_policy
LOCAL_MODULE_TAGS := optional
LOCAL_CFLAGS := -Wall -Werror
LOCAL_SRC_FILES := version_policy.c
LOCAL_SHARED_LIBRARIES := libsepol
LOCAL_CXX_STL := none
include $(BUILD_HOST_EXECUTABLE)
include $(call all-makefiles-under,$(LOCAL_PATH))