On Sun, Apr 7, 2013 at 9:23 AM, Richard Haines < [email protected]> wrote:
> I've had the following problems concerning install MMAC after sync on > Friday (6th April): > > 1) After adding new entries in mac_permissions.xml to allow an app access > the install fails. In log: > W/SELinuxMMAC( 307): MMAC_DENIAL: Policy blacklisted permission > android.permission.WRITE_EXTERNAL_STORAGE for package > com.example.seandroiddemo > W/PackageManager( 307): Installing application package > com.example.seandroiddemo failed due to policy. > W/PackageManager( 307): Package couldn't be installed in > /data/app/com.example.seandroiddemo-1.apk > > The new mac_permissions.xml entry is: > <signer signature="sig-removed for email"> > <package name="com.example.seandroiddemo"> > <allow-permission name="android.permission.READ_EXTERNAL_STORAGE" /> > <allow-permission name="android.permission.SEND_SMS" /> > <allow-permission name="android.permission.WRITE_EXTERNAL_STORAGE" /> > <allow-permission > name="com.example.seandroiddemo.permission.DEADLY_ACTIVITY" /> > </package> > </signer> > > I'm sure this did work on a previous release a few weeks ago. The log > states that the mac_permissions were processed ok: > I/SELinuxMMAC( 303): <package> inner tag: (com.example.seandroiddemo) > assigned allowed-permissions => > I/SELinuxMMAC( 303): [android.permission.READ_EXTERNAL_STORAGE, > I/SELinuxMMAC( 303): android.permission.SEND_SMS, > I/SELinuxMMAC( 303): android.permission.WRITE_EXTERNAL_STORAGE, > I/SELinuxMMAC( 303): com.example.seandroiddemo.permission.DEADLY_ACTIVITY] > > > AOSP recently merged in our SELinuxMMAC changes which supports the seinfo labeling of apps. This is a subset of the entire install-time mac suite which is only supported by SE Android at this time. Based on recommendations received by Google engineers, the SELinuxMMAC logic that is supported has subsequently changed a bit. A single policy is now applied to all third party apps which is in contrast to our prior efforts, as you have noted. In the platform we do not allow different policies to be applied to different third party apps based on hard-coded (or configured) certificates or package names in the platform. So all third party installs will always be checked against the 'default' stanza. Whereas any pre-installed app, as well as their updates, will be checked against the entire mac_permissions.xml file. In your situation you are seeing the 'seandroiddemo' app being checked against the default policy and thus failing on the WRITE_EXTERNAL_STORAGE deny rule in the default stanza. This new situation certainly raises issues about the utility of the setool program. The tool, in its current state, can't distinguish between apps that are pre-installed, system apps versus third party apps. Because of this, some confusion about the pass and fail of apps being installed is certainly possible. Some options are still being worked out in this area. > > 3) This is not a bug but a suggestion. As you now allow multiple > mmac_types.xml files in sepolicy/Android.mk, will multiple > intent_mac.xml files be supported as each mmac_types entry will > generally require a corresponding intent_mac entry. > > I don't see why we can't make that quick change for everyone. Should be an easy adjustment. Note however, we are very active working with the intent_mac code base. We are working on some new and different ideas surrounding the mmac typing system as well as the middleware policy logic surrounding Android's component pieces (i.e. intents, broadcasts, content providers, ...). We are including some of the suggestions and ideas brought up by people on this list as well. If you have any other suggestions or ideas, we'd be glad to hear them. We expect a release in the near future *fingers-crossed*. > Richard > > > > -- > This message was distributed to subscribers of the seandroid-list mailing > list. > If you no longer wish to subscribe, send mail to [email protected] > the words "unsubscribe seandroid-list" without quotes as the message. >
