Thanks for the fast response.
1) It looks like the match method in IntentFilter.java (line 1103) checks
action, data ,and then category, and each of those checks immediately returns
if it fails. So claiming success on a NO_MATCH_DATA response will still need
to handle the case of the category not matching.
2) I just tried it again - it's not the system_server process, it's this
process:
u:r:system_app:s0 system 1281 130 system:ui
My persist.mac_intent_allowSystem system property is not set
(so it should be defaulting to true).
The system_server process is a lower pid:
u:r:system:s0 system 391 130
system_server
E/PackageManager( 391): INTENT_DENIAL:
{"intent":{"action":"android.intent.action.VIEW",
"data":"content:\/\/org.mitre.mocsii.DocContentProvider\/Summer.txt"},
"callingPid":1281,
"callingPkgs":["com.android.seandroid_manager","com.android.keychain","android","com.android.inputdevices","com.android.settings","com.andro
id.providers.settings"],
"callingTypes":["phone_state_perm","settings_app","system_server","nfc_handler"],
"destPkgs":["com.mobisystems.office"],
"destTypes":["docviewer2","phone_state_perm"]}
From: Joman Chu [mailto:[email protected]]
Sent: Friday, January 04, 2013 1:03 AM
To: Peck, Michael A
Cc: [email protected]
Subject: Re: Intent MAC comments
On Thu, Jan 3, 2013 at 8:24 PM, Peck, Michael A
<[email protected]<mailto:[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<tel:410-272-5959>
Thanks for playing with Intent MAC,
Joman
