Thanks for the quick response, I'll add it as pre-installed and check what happens, but guess it should then work. Do you think intent MAC will go the same way ?
--- On Sun, 7/4/13, Robert Craig <[email protected]> wrote: From: Robert Craig <[email protected]> Subject: Re: Install MMAC problems using 4.2.2 To: "Richard Haines" <[email protected]> Cc: "[email protected]" <[email protected]> Date: Sunday, 7 April, 2013, 17:23 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] with the words "unsubscribe seandroid-list" without quotes as the message. -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
