Update to docs

Update to docs

[William Roberts]

Can I get the documentation on the wiki updated under "SE Android
policy" the second paragraph. I would like to update that you can
specify genfs_context files and seapp_context files...maybe something
like below will be sufficient:

Device-specific additions for the policy configuration can be placed
in a sepolicy.te file (for kernel TE policy rules), a sepolicy.fc file
(for file_contexts entries), a sepolicy.pc file (for property_contexts
entries), a sepolicy.genfs_contexts file (for genfs entries), or
seapp_contexts (for seapp rule entries) under any of the
target/board/<device>, device/<vendor>/<device>, or
vendor/<vendor>/<device> directories. These files if present are
merged into the policy during the build.

-- 
Respectfully,

William C Roberts

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to docs

[Stephen Smalley]

On Thu, 2012-09-13 at 16:58 -0700, William Roberts wrote:
> Can I get the documentation on the wiki updated under "SE Android
> policy" the second paragraph. I would like to update that you can
> specify genfs_context files and seapp_context files...maybe something
> like below will be sufficient:
> 
> Device-specific additions for the policy configuration can be placed
> in a sepolicy.te file (for kernel TE policy rules), a sepolicy.fc file
> (for file_contexts entries), a sepolicy.pc file (for property_contexts
> entries), a sepolicy.genfs_contexts file (for genfs entries), or
> seapp_contexts (for seapp rule entries) under any of the
> target/board/<device>, device/<vendor>/<device>, or
> vendor/<vendor>/<device> directories. These files if present are
> merged into the policy during the build.

Updated.  However, this is starting to get unwieldy.  I was wondering
whether we should switch over to a model where we permit a sepolicy
subdirectory under the device directories that can contain any kind of
policy file (without requiring a sepolicy. prefix on each one since they
will be in a subdirectory).  Just need to decide how we would merge
multiple .te files with the same name, i.e. concatenate/union vs.
replace/override.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to docs

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2012-09-13 at 16:58 -0700, William Roberts wrote:
>> Can I get the documentation on the wiki updated under "SE Android
>> policy" the second paragraph. I would like to update that you can
>> specify genfs_context files and seapp_context files...maybe something
>> like below will be sufficient:
>>
>> Device-specific additions for the policy configuration can be placed
>> in a sepolicy.te file (for kernel TE policy rules), a sepolicy.fc file
>> (for file_contexts entries), a sepolicy.pc file (for property_contexts
>> entries), a sepolicy.genfs_contexts file (for genfs entries), or
>> seapp_contexts (for seapp rule entries) under any of the
>> target/board/<device>, device/<vendor>/<device>, or
>> vendor/<vendor>/<device>  directories. These files if present are
>> merged into the policy during the build.
>
> Updated.  However, this is starting to get unwieldy.  I was wondering
> whether we should switch over to a model where we permit a sepolicy
> subdirectory under the device directories that can contain any kind of
> policy file (without requiring a sepolicy. prefix on each one since they
> will be in a subdirectory).  Just need to decide how we would merge
> multiple .te files with the same name, i.e. concatenate/union vs.
> replace/override.
>

I'd prefer something like POLICY_FILES += some-policy-file.te.

The reason is that under my maguro directory I now have a full_maguro.mk 
that builds a more-or-less upstream maguro and a tresys_maguro.mk that 
adds stuff we are doing. Right now the policies are all merged because 
there isn't another option but with a POLICY_FILES variable we could 
have custom policy per product.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Update to docs

[Radzykewycz, T (Radzy)]

There have been a couple times when I wanted to remove a rule from the system policy for a specific BSP.  So I guess I would vote for override if I need to choose one or the other.  But would it be reasonable to allow both overrides and concatenates ?  That would be my preference.

________________________________________
From: owner-selinux@tycho.nsa.gov [owner-selinux@tycho.nsa.gov] on behalf of Stephen Smalley [sds@tycho.nsa.gov]
Sent: Friday, September 14, 2012 5:51 AM
To: William Roberts
Cc: selinux@tycho.nsa.gov
Subject: Re: Update to docs

On Thu, 2012-09-13 at 16:58 -0700, William Roberts wrote:
> Can I get the documentation on the wiki updated under "SE Android
> policy" the second paragraph. I would like to update that you can
> specify genfs_context files and seapp_context files...maybe something
> like below will be sufficient:
>
> Device-specific additions for the policy configuration can be placed
> in a sepolicy.te file (for kernel TE policy rules), a sepolicy.fc file
> (for file_contexts entries), a sepolicy.pc file (for property_contexts
> entries), a sepolicy.genfs_contexts file (for genfs entries), or
> seapp_contexts (for seapp rule entries) under any of the
> target/board/<device>, device/<vendor>/<device>, or
> vendor/<vendor>/<device> directories. These files if present are
> merged into the policy during the build.

Updated.  However, this is starting to get unwieldy.  I was wondering
whether we should switch over to a model where we permit a sepolicy
subdirectory under the device directories that can contain any kind of
policy file (without requiring a sepolicy. prefix on each one since they
will be in a subdirectory).  Just need to decide how we would merge
multiple .te files with the same name, i.e. concatenate/union vs.
replace/override.

--
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to docs

[Stephen Smalley]

On Fri, 2012-09-14 at 16:19 +0000, Radzykewycz, T (Radzy) wrote:
> There have been a couple times when I wanted to remove a rule from the
> system policy for a specific BSP.  So I guess I would vote for
> override if I need to choose one or the other.  But would it be
> reasonable to allow both overrides and concatenates ?  That would be
> my preference.

Maybe we could provide two variables definitions in the makefiles, one
for policy files that should replace/override and one for policy files
that should concatenate/union with the base policy files?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to docs

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

Yeah it is a bit unwieldy, currently I use the include mechanism to include
stuff in a device/sepolicy folder. Right now, the only thing I have
modified in the base policy that I don't have upstream is commenting out
inits transition rule to shell domain on exec of shell_exec.

It would be really nice to do something like seapp_contexts but for the
selinux policies.

Bill


On Fri, Sep 14, 2012 at 9:29 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Fri, 2012-09-14 at 16:19 +0000, Radzykewycz, T (Radzy) wrote:
> > There have been a couple times when I wanted to remove a rule from the
> > system policy for a specific BSP.  So I guess I would vote for
> > override if I need to choose one or the other.  But would it be
> > reasonable to allow both overrides and concatenates ?  That would be
> > my preference.
>
> Maybe we could provide two variables definitions in the makefiles, one
> for policy files that should replace/override and one for policy files
> that should concatenate/union with the base policy files?
>
> --
> Stephen Smalley
> National Security Agency
>
>


-- 
Respectfully,

William C Roberts

[-- Attachment #2: Type: text/html, Size: 1629 bytes --]

RE: Update to docs

[Radzykewycz, T (Radzy)]

Sounds good.  I haven't thought about the implementation at all.

________________________________________
From: Stephen Smalley [sds@tycho.nsa.gov]
Sent: Friday, September 14, 2012 9:29 AM
To: Radzykewycz, T (Radzy)
Cc: William Roberts; selinux@tycho.nsa.gov; Craig, Robert P.
Subject: Re: Update to docs

On Fri, 2012-09-14 at 16:19 +0000, Radzykewycz, T (Radzy) wrote:
> There have been a couple times when I wanted to remove a rule from the
> system policy for a specific BSP.  So I guess I would vote for
> override if I need to choose one or the other.  But would it be
> reasonable to allow both overrides and concatenates ?  That would be
> my preference.

Maybe we could provide two variables definitions in the makefiles, one
for policy files that should replace/override and one for policy files
that should concatenate/union with the base policy files?

--
Stephen Smalley
National Security Agency



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to docs

[Robert Craig]

[-- Attachment #1.1: Type: text/plain, Size: 2367 bytes --]

Attached is a patch to help address the need for better per-device
maintainability.
Here are some general notes concerning functionality.

- An 'sepolicy' subdirectory is now required under device directories.
- Two per-device product variables are now available:
PRODUCT_SEPOLICY_REPLACE and PRODUCT_SEPOLICY_UNION.
  These variables should be set somewhere within one of your device
specific makefiles.
- No longer allow an 'sepolicy.' prefix (except *te files). Under the
sepolicy directory, names revert back to their original
  forms( i.e. file_contexts, property_contexts, genfs_contexts). te files
may be named with whatever prefix is deemed
  appropriate but must end with '.te'.
- When listing a policy file in PRODUCT_SEPOLICY_REPLACE the entire
original file is replaced. This patch doesn't offer any
  type of surgical strike inside policy files. So in most case you'll have
to copy over the original file first then make your
  rule/label change(s).
- Unions work just as with the previous functionality, appended to the end.

As always, I welcome any additional ideas or comments.

On Fri, Sep 14, 2012 at 4:28 PM, Radzykewycz, T (Radzy) <radzy@windriver.com
> wrote:

> Sounds good.  I haven't thought about the implementation at all.
>
> ________________________________________
> From: Stephen Smalley [sds@tycho.nsa.gov]
> Sent: Friday, September 14, 2012 9:29 AM
> To: Radzykewycz, T (Radzy)
> Cc: William Roberts; selinux@tycho.nsa.gov; Craig, Robert P.
> Subject: Re: Update to docs
>
> On Fri, 2012-09-14 at 16:19 +0000, Radzykewycz, T (Radzy) wrote:
> > There have been a couple times when I wanted to remove a rule from the
> > system policy for a specific BSP.  So I guess I would vote for
> > override if I need to choose one or the other.  But would it be
> > reasonable to allow both overrides and concatenates ?  That would be
> > my preference.
>
> Maybe we could provide two variables definitions in the makefiles, one
> for policy files that should replace/override and one for policy files
> that should concatenate/union with the base policy files?
>
> --
> Stephen Smalley
> National Security Agency
>
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith
> the words "unsubscribe selinux" without quotes as the message.
>

[-- Attachment #1.2: Type: text/html, Size: 3139 bytes --]

[-- Attachment #2: external_sepolicy.patch --]
[-- Type: application/octet-stream, Size: 4978 bytes --]

diff --git a/Android.mk b/Android.mk
index d3b21bb..93e888e 100644
--- a/Android.mk
+++ b/Android.mk
@@ -15,15 +15,48 @@ MLS_SENS=1
 MLS_CATS=1024
 
 LOCAL_POLICY_DIRS := $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/ device/*/$(TARGET_DEVICE)/ vendor/*/$(TARGET_DEVICE)/
-
-LOCAL_POLICY_FC := $(wildcard $(addsuffix sepolicy.fc, $(LOCAL_POLICY_DIRS)))
-LOCAL_POLICY_TE := $(wildcard $(addsuffix sepolicy.te, $(LOCAL_POLICY_DIRS)))
-LOCAL_POLICY_PC := $(wildcard $(addsuffix sepolicy.pc, $(LOCAL_POLICY_DIRS)))
-LOCAL_POLICY_FS_USE := $(wildcard $(addsuffix sepolicy.fs_use, $(LOCAL_POLICY_DIRS)))
-LOCAL_POLICY_PORT_CONTEXTS := $(wildcard $(addsuffix sepolicy.port_contexts, $(LOCAL_POLICY_DIRS)))
-LOCAL_POLICY_GENFS_CONTEXTS := $(wildcard $(addsuffix sepolicy.genfs_contexts, $(LOCAL_POLICY_DIRS)))
-LOCAL_POLICY_INITIAL_SID_CONTEXTS := $(wildcard $(addsuffix sepolicy.initial_sid_contexts, $(LOCAL_POLICY_DIRS)))
-LOCAL_POLICY_SC := $(wildcard $(addsuffix seapp_contexts, $(LOCAL_POLICY_DIRS)))
+LOCAL_SEPOLICY_DIRS := $(addsuffix sepolicy, $(LOCAL_POLICY_DIRS))
+
+# Quick edge case error detection for PRODUCT_SEPOLICY_REPLACE.
+# Builds the singular path for each replace file.
+LOCAL_SEPOLICY_REPLACE_PATHS :=
+$(foreach pf, $(PRODUCT_SEPOLICY_REPLACE), \
+  $(if $(filter $(pf), $(PRODUCT_SEPOLICY_UNION)), \
+    $(error Ambiguous request for sepolicy $(pf). Appears in both \
+      PRODUCT_SEPOLICY_REPLACE and PRODUCT_SEPOLICY_UNION), \
+  ) \
+  $(eval _paths := $(wildcard $(addsuffix /$(pf), $(LOCAL_SEPOLICY_DIRS)))) \
+  $(eval _occurences := $(words $(_paths))) \
+  $(if $(filter 0,$(_occurences)), \
+    $(error No sepolicy file found for $(pf) in $(LOCAL_SEPOLICY_DIRS)), \
+  ) \
+  $(if $(filter 1, $(_occurences)), \
+    $(eval LOCAL_SEPOLICY_REPLACE_PATHS += $(_paths)), \
+    $(error Multiple occurences of replace file $(pf) in $(_paths)) \
+  ) \
+  $(if $(filter 0, $(words $(wildcard $(addsuffix /$(pf), $(LOCAL_PATH))))), \
+    $(error Specified the sepolicy file $(pf) in PRODUCT_SEPOLICY_REPLACE, \
+      but none found in $(LOCAL_PATH)), \
+  ) \
+)
+
+# Builds paths for all requested policy files w.r.t
+# both PRODUCT_SEPOLICY_REPLACE and PRODUCT_SEPOLICY_UNION
+# product variables.
+# $(1): the set of policy name paths to build
+build_policy = $(foreach type, $(1), \
+  $(foreach expanded_type, $(notdir $(wildcard $(addsuffix /$(type), $(LOCAL_PATH)))), \
+    $(if $(filter $(expanded_type), $(PRODUCT_SEPOLICY_REPLACE)), \
+      $(wildcard $(addsuffix $(expanded_type), $(dir $(LOCAL_SEPOLICY_REPLACE_PATHS)))), \
+      $(LOCAL_PATH)/$(expanded_type) \
+    ) \
+  ) \
+  $(foreach union_policy, $(wildcard $(addsuffix /$(type), $(LOCAL_SEPOLICY_DIRS))), \
+    $(if $(filter $(notdir $(union_policy)), $(PRODUCT_SEPOLICY_UNION)), \
+      $(union_policy), \
+    ) \
+  ) \
+)
 
 ##################################
 include $(CLEAR_VARS)
@@ -38,7 +71,7 @@ include $(BUILD_SYSTEM)/base_rules.mk
 sepolicy_policy.conf := $(intermediates)/policy.conf
 $(sepolicy_policy.conf): PRIVATE_MLS_SENS := $(MLS_SENS)
 $(sepolicy_policy.conf): PRIVATE_MLS_CATS := $(MLS_CATS)
-$(sepolicy_policy.conf) : $(wildcard $(addprefix $(LOCAL_PATH)/,security_classes initial_sids access_vectors global_macros mls_macros mls policy_capabilities te_macros attributes *.te) $(LOCAL_POLICY_TE) $(addprefix $(LOCAL_PATH)/, roles users initial_sid_contexts) $(LOCAL_POLICY_INITIAL_SID_CONTEXTS) $(addprefix $(LOCAL_PATH)/,fs_use) $(LOCAL_POLICY_FS_USE) $(addprefix $(LOCAL_PATH)/,genfs_contexts) $(LOCAL_POLICY_GENFS_CONTEXTS) $(addprefix $(LOCAL_PATH)/,port_contexts) $(LOCAL_POLICY_PORT_CONTEXTS))
+$(sepolicy_policy.conf) : $(call build_policy, security_classes initial_sids access_vectors global_macros mls_macros mls policy_capabilities te_macros attributes *.te roles users initial_sid_contexts fs_use genfs_contexts port_contexts)
 	@mkdir -p $(dir $@)
 	$(hide) m4 -D mls_num_sens=$(PRIVATE_MLS_SENS) -D mls_num_cats=$(PRIVATE_MLS_CATS) -s $^ > $@
 
@@ -58,7 +91,7 @@ LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT)
 include $(BUILD_SYSTEM)/base_rules.mk
 
 file_contexts := $(intermediates)/file_contexts
-$(file_contexts): $(LOCAL_PATH)/file_contexts $(LOCAL_POLICY_FC)
+$(file_contexts): $(call build_policy, file_contexts)
 	@mkdir -p $(dir $@)
 	$(hide) m4 -s $^ > $@
 
@@ -74,7 +107,7 @@ LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT)
 include $(BUILD_SYSTEM)/base_rules.mk
 
 seapp_contexts.tmp := $(intermediates)/seapp_contexts.tmp
-$(seapp_contexts.tmp): $(LOCAL_PATH)/seapp_contexts $(LOCAL_POLICY_SC)
+$(seapp_contexts.tmp): $(call build_policy, seapp_contexts)
 	@mkdir -p $(dir $@)
 	$(hide) m4 -s $^ > $@
 
@@ -94,7 +127,7 @@ LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT)
 include $(BUILD_SYSTEM)/base_rules.mk
 
 property_contexts := $(intermediates)/property_contexts
-$(property_contexts): $(LOCAL_PATH)/property_contexts $(LOCAL_POLICY_PC)
+$(property_contexts): $(call build_policy, property_contexts)
 	@mkdir -p $(dir $@)
 	$(hide) m4 -s $^ > $@