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.

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

Thanks,
Mike

--
Michael Peck
The MITRE Corporation
410-272-5959

Reply via email to