On Wed, Feb 18, 2015 at 1:08 PM, Webb, Russell <[email protected]> wrote:
> 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. > Yes for most things taht works, just make sure to use the eng or userdebug macro to make sure its stripped on user builds. > > > 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]> > 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 > -- 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].
