On Wed, Feb 18, 2015 at 10:56 AM, Webb, Russell <[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]> 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]] > *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]> wrote: > > > > > > On Wed, Feb 18, 2015 at 10:10 AM, Elena Reshetova < > [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] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to > [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].
