2012-11-01 19:33:04 +01:00
|
|
|
LOCAL_PATH:= $(call my-dir)
|
|
|
|
|
|
|
|
|
|
include $(CLEAR_VARS)
|
|
|
|
|
|
|
|
|
|
LOCAL_MODULE := checkseapp
|
|
|
|
|
LOCAL_MODULE_TAGS := optional
|
|
|
|
|
LOCAL_C_INCLUDES := external/libsepol/include/
|
2013-11-01 15:24:36 +01:00
|
|
|
LOCAL_CFLAGS := -DLINK_SEPOL_STATIC -Wall -Werror
|
2012-11-01 19:33:04 +01:00
|
|
|
LOCAL_SRC_FILES := check_seapp.c
|
|
|
|
|
LOCAL_STATIC_LIBRARIES := libsepol
|
|
|
|
|
|
|
|
|
|
include $(BUILD_HOST_EXECUTABLE)
|
|
|
|
|
|
|
|
|
|
###################################
|
|
|
|
|
include $(CLEAR_VARS)
|
|
|
|
|
|
|
|
|
|
LOCAL_MODULE := checkfc
|
|
|
|
|
LOCAL_MODULE_TAGS := optional
|
|
|
|
|
LOCAL_C_INCLUDES := external/libsepol/include \
|
|
|
|
|
external/libselinux/include
|
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 14:22:26 +01:00
|
|
|
LOCAL_CFLAGS := -Wall -Werror
|
2012-11-01 19:33:04 +01:00
|
|
|
LOCAL_SRC_FILES := checkfc.c
|
|
|
|
|
LOCAL_STATIC_LIBRARIES := libsepol libselinux
|
|
|
|
|
|
|
|
|
|
include $(BUILD_HOST_EXECUTABLE)
|
2013-03-26 23:19:03 +01:00
|
|
|
|
|
|
|
|
##################################
|
|
|
|
|
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)
|
2013-08-23 03:23:37 +02:00
|
|
|
###################################
|
|
|
|
|
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 14:22:26 +01:00
|
|
|
LOCAL_C_INCLUDES := external/libsepol/include
|
|
|
|
|
LOCAL_CFLAGS := -Wall -Werror
|
2013-08-23 03:23:37 +02:00
|
|
|
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 14:22:26 +01:00
|
|
|
LOCAL_STATIC_LIBRARIES := libsepol
|
|
|
|
|
|
|
|
|
|
include $(BUILD_HOST_EXECUTABLE)
|
|
|
|
|
|
2014-10-20 18:52:55 +02:00
|
|
|
include $(call all-makefiles-under,$(LOCAL_PATH))
|
