Apologies for being confused on the current state of aosp/master. I was looking at the lollipop release branch. Thanks for your patience and for pointing us at your patch!
In practice, we have found that some tools can’t run in unconfined. It looks like Stephen’s suggestion of using permissive instead of permissive_or_unconfined works just fine for our immediate purposes. Thanks!! Russell From: William Roberts [mailto:[email protected]] Sent: Wednesday, February 18, 2015 11:05 AM To: Webb, Russell Cc: Elena Reshetova; seandroid-list Subject: Re: Question about FORCE_PERMISSIVE_TO_UNCONFINED in Android.mk On Wed, Feb 18, 2015 at 10:56 AM, Webb, Russell <[email protected]<mailto:[email protected]>> wrote: We have lots of tools that we run only on userdebug and eng builds and are now being forced to write (ugly) policy for tools we never intend to ship (my company restricts making changes to AOSP projects so changing this internally isn’t as simple as it could be). Would you be open to a patch that sets this variable with ?= so that board files can override? Any chance this change, marked prominently with “DO NOT MERGE”, was not actually intended to be merged and can be reverted? I am bit confused, the only difference is wether its permissive or unconfined which is fairly similair (things have been removed from unconfined and the goal is to make it go away). So in theory, the only difference one sees is the log-spew of a permissive domain over an unconfined domain. Becuase of some never allows, however, any execs by init are forced into a specific domain, however, there is nothing stopping you from running them all in a custom domain that is essentially unconfined, however, I am not sure of any arising conflicts on neverallows and will likely need to be massaged to avoid conficts. The change to override FORCE_PERMISSIVE_TO_UNCONFINED on everything but user builds has been submitted. see https://android-review.googlesource.com/#/c/116836/ commit 754f5ea7ee4bb252e6f84b2b1228d5e210abe0ce Author: William Roberts <[email protected]<mailto:[email protected]>> Date: Wed Dec 3 10:50:00 2014 -0800 Allow overiding FORCE_PERMISSIVE_TO_UNCONFINED It's beneficial to be able to overide this in a device makefile if you need to get the domains into an unconfined state to keep the logs from filling up on kernel entries without having to add rules into device specific policy. Change-Id: I7778be01256ac601f247e4d6e12573d0d23d12a1 Thanks! Russell From: Elena Reshetova [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, February 18, 2015 10:34 AM To: William Roberts Cc: seandroid-list; Webb, Russell Subject: Re: Question about FORCE_PERMISSIVE_TO_UNCONFINED in Android.mk > So permissive domains are allowed on everything BUT user builds, but if you > wanted to make permissive domains unconfined for some reason, notably to > silence the logs, you can override FORCE_PERMISSIVE_TO_UNCONFINED Yes, this makes sense and this is the desired behaviour. Just the commit 2aa727e3f01f814384bd4a49281c7c 39cf562ff6 was very confusing. Best Regards, Elena. On Wed, Feb 18, 2015 at 10:23 AM, William Roberts <[email protected]<mailto:[email protected]>> wrote: On Wed, Feb 18, 2015 at 10:10 AM, Elena Reshetova <[email protected]<mailto:[email protected]>> wrote: Hi, In Android.mk under sepolicy/external, there is a definition that seems illogical to us: FORCE_PERMISSIVE_TO_UNCONFINED:=true ifeq ($(TARGET_BUILD_VARIANT),user) # User builds are always forced unconfined+enforcing FORCE_PERMISSIVE_TO_UNCONFINED:=true endif Would it be instead better to have it this way: FORCE_PERMISSIVE_TO_UNCONFINED:=true ifeq ($(TARGET_BUILD_VARIANT),userdebug) # Userdebug builds are not forced to unconfined+enforcing FORCE_PERMISSIVE_TO_UNCONFINED:=false endif It would allow userdebug builds to have permissive domains, which greatly helps if you need to run some special debug/logging utilities and don't want to waste time on creating policies for them. Opinions? The most up-to-date in Android.mk is as follows: # Force permissive domains to be unconfined+enforcing? # # During development, this should be set to false. # Permissive means permissive. # # When we're close to a release and SELinux new policy development # is frozen, we should flip this to true. This forces any currently # permissive domains into unconfined+enforcing. # FORCE_PERMISSIVE_TO_UNCONFINED ?= false ifeq ($(TARGET_BUILD_VARIANT),user) # User builds are always forced unconfined+enforcing FORCE_PERMISSIVE_TO_UNCONFINED := true endif So permissive domains are allowed on everything BUT user builds, but if you wanted to make permissive domains unconfined for some reason, notably to silence the logs, you can override FORCE_PERMISSIVE_TO_UNCONFINED This then gets pased to m4 as a macro definition in the Android.mk as: -D force_permissive_to_unconfined=$(FORCE_PERMISSIVE_TO_UNCONFINED) \ Which later is expanded in te_macros: ##################################### # permissive_or_unconfined # Returns "permissive $1" if FORCE_PERMISSIVE_TO_UNCONFINED is false, # and "unconfined($1)" otherwise. # # This is used for experimental domains, where we want to ensure # the domain is unconfined+enforcing once new SELinux policy development # has ceased. # define(`permissive_or_unconfined', ifelse(force_permissive_to_unconfined, `false', permissive $1;, unconfined_domain($1))) So if you want domains to follow this, make sure to use permissive_or_unconfined macro on that domain type. Best Regards, Elena. _______________________________________________ Seandroid-list mailing list [email protected]<mailto:[email protected]> To unsubscribe, send email to [email protected]<mailto:[email protected]>. To get help, send an email containing "help" to [email protected]<mailto:[email protected]>. -- Respectfully, William C Roberts -- Respectfully, William C Roberts
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
