On Thu, Jan 3, 2013 at 8:24 PM, Peck, Michael A <[email protected]> wrote:
> Hi,**** > > ** ** > > Thanks for introducing Intent MAC. I think it will provide good > opportunities to address some common app security issues.**** > > ** ** > > I have a couple of comments so far on the current implementation.**** > > ** ** > > Background: I have a Document Manager app. It stores documents, and when > a document is clicked on, uses an implicit intent to attempt to invoke an > activity in a separate Document Viewer app to view the document. The > intent has action set to android.intent.action.VIEW and there is also a > content URI and a content MIME type.**** > > ** ** > > Comment 1:**** > > I added Intent MAC policies to allow android.intent.action.VIEW from the > Document Manager app to two different Document Viewer apps.**** > > However, the intents kept getting denied, and I eventually realized that > it is because of IntentFilter’s data test behavior.**** > > See the “Data test” section almost half way down in > http://developer.android.com/guide/components/intents-filters.html**** > > Since the intent has the data URI and type filled in, the corresponding > intent filter in intent_mac.xml also needs to have a data type in order to > match – leaving the data type empty in the intent filter will result in no > match.**** > > To get this to work, I modified IntentMAC.java to parse <data> in > intent_mac.xml so that a data mimeType could be set in the intent filter > then added this entry to my intent_mac.xml:**** > > <intent>**** > > <filter>**** > > <action name="android.intent.action.VIEW"/>**** > > <data mimeType="application/*" />**** > > <data mimeType="text/*" />**** > > </filter>**** > > <allow name="view1" src="docmgr1" dst="docviewer1"/>**** > > <allow name="view2" src="docmgr1" dst="docviewer2"/>**** > > </intent>**** > > This is a drawback of sorts of now using IntentFilter to perform the > matching. > Very true. The Intent Filter stuff was introduced in commit 175b214 and can be backed out if desired. The purpose of using Intent Filters was to simplify the filter check and reuse existing code, since we also wanted to support filtering on Category strings and other fields in the Intent. Unfortunately I don't have a device in front of me right now, but I do wonder what value the IntentFilter match() method returns in the case where the data tag doesn't exist. If it is IntentFilter.NO_MATCH_DATA, a more complicated check could be implemented in IntentMac's intentFilterMatch(). > **** > > ** ** > > Comment 2:**** > > If there are two Document Viewer activities eligible to handle the intent > (including passing the Intent MAC rules), Android brings up > android/com.android.internal.app.ResolverActivity for the user to choose a > viewer.**** > > But it looks like the ResolverActivity is generating two INTENT_DENIALs, > one for each eligible destination activity, and when enforcing mode is on, > the ResolverActivity tells the user there are no available apps to handle > the action.**** > > To fix this problem it looks like the “android” package needs full access > to send any intent to anywhere? (Unless there is some way to pass through > the true source app’s identity) **** > > I fixed it by adding rules under allow-all to allow the “android” package > to send intents to the two document viewers.**** > > ** ** > > E/PackageManager( 391): INTENT_DENIAL: > {"intent":{"action":"android.intent.action.VIEW", > "data":"content:\/\/org.mitre.mocsii.DocContentProvider\/Summer.txt"}, > "callingPid":1074, > "callingPkgs":["com.android.seandroid_manager","android","com.android.keychain","com.android.inputdevices","com.android.settings", > **** > > "com.android.providers.settings"], > "callingTypes":["phone_state_perm","settings_app","system_server","nfc_handler"], > "destPkgs":["com.mobisystems.office"], > "destTypes":["phone_state_perm","docviewer2"]}**** > > I/ActivityManager( 391): Displayed > android/com.android.internal.app.ResolverActivity: +254ms > That is very curious. Based on that list of packages, it seems like 1074 is the pid of the system_server. IntentMAC.java's checkAllowAllBooleans() should have allowed that under the persist.mac_intent_allowSystem boolean. (This should also make the allow-all rule for the "android" package redundant.) Can you verify the pid of the system_server and the value of the persist.mac_intent_allowSystem property? (getprop on the shell should get that value.) **** > > **** > > ** ** > > Thanks,**** > > Mike**** > > ** ** > > --**** > > Michael Peck**** > > The MITRE Corporation**** > > 410-272-5959**** > > ** ** > Thanks for playing with Intent MAC, Joman
