Richard,
This puts your previous comments regarding the comment above the
checkPolicy() call in AMS.java in better context. I agree with the
assessment. I'll take another look at the patch you sent and get
something pushed in the future regarding this. Thanks.
Bob
On 07/15/2013 12:38 PM, Richard Haines wrote:
Thanks for the update.
I'm using a cp_mac build from mid June and initially has the standard apps etc.
I then add my own stuff but the problem is really com.android.inputmethod.latin
and its dictionary.
After more digging it seems that CheckPolicy in ActivityManagerService.java
calls pm.checkPolicy with the app info for "com.android.inputmethod.latin",
however the destinationProvider is null, therefore ContentSecurityManager.java:
if (destinationProvider == null) {
return false;
}
This is because the dictionary pack is not yet loaded so the calling app gets
killed. With the patch it lets the provider load, then checks if valid or not.
The content_permissions.xml entries are not required for this because the
the app and dictionary pack are one (they never even get checked in the
unpatched version anyway due to destinationProvider == null = death).
Hope this helps
Richard
----- Original Message -----
From: rpcraig <[email protected]>
To: Richard Haines <[email protected]>
Cc: seandroid <[email protected]>
Sent: Monday, 15 July 2013, 15:59
Subject: Re: CP_MAC - Fix activity manager content provider permission check
Richard,
I'm finding the content authority 'com.android.inputmethod.latin.dictionarypack' to
be part of the Gapp LatinImeDictionaryPack.apk. I'm not seeing this app or content
authority in AOSP. Are you including any other non-AOSP apps in your build or am I
missing something. And, while
packages/inputmethods/LatinIME/java/src/com/android/inputmethod/latin/BinaryDictionary.java
seems to define the string "com.android.inputmethod.latin.dictionarypack", the
actual content provider is implemented in LatinImeDictionaryPack.apk (just using apktool
to dump the manifest and looking for the provider tag reveals this). If this is all true,
the best approach is to add a content_permissions.xml under the device or vendor tree and
UNION it in.
Bob
On 07/15/2013 06:46 AM, rpcraig wrote:
On 07/14/2013 08:25 AM, Richard Haines wrote:
In the ActivityManagerService.java source there is the following comment:
// Is this the best spot for this? Should we specifically let the
// other tests below try first and then right before a return
// is made do we try to apply our checks? That approach might
// make sense becuase maybe that provider doesn't even exist.
The author is correct in that this is not the correct place. This is because
apps like "com.android.inputmethod.latin" can never run as it needs to load a
dictionary CP as a part of its process. I've therefore added the checkPolicy
call to various return points in the process. It may be that the call should
be added to more places, however the patch works with my simple tests.
The original checkPolicy() covers you're three new places already, so I'm not
sure what you're actually gaining by removing the old check. The reason you're
getting a denial is because there is presently no policy in place to deal with
this specific provider; a minor oversight on our behalf as we probably didn't
exercise all the apps. I think the correct course of action is to address the
denial by just creating a new policy entry in content_permissions.xml. Maybe
try something like the following; we'll probably have to create a more
appropriate type in the future. Or, we could even try to add this specific
provider to an already existing type stanza protected by a signature.
<type name="com.android.inputmethod.latin.dictionarypack">
<provider value="com.android.inputmethod.latin.dictionarypack"/>
</type>
<allow source="shared" destination="com.android.inputmethod.latin.dictionarypack"
permission="use;rw"/>
On a side note, did you have to create any new policy for this content provider
after you moved the existing checkPolicy() hooks? If not, doesn't that seem a
bit suspicious? I would expect one of your new hooks to throw a denial.
The attached patches:
frameworks/base/services/java/com/android/server/am/ActivityManager.java
The main symptom is that the popup keyboards did not work when editing text
and is shown in the logs as:
D/ActivityManager( 336): Denied USE permission between caller=xxx and content
authority=com.android.inputmethod.latin.dictionarypack
Where caller=xxx is the pid of the com.android.inputmethod.latin app
"com.android.inputmethod.latin.dictionarypack" is defined in:
packages/inputmethods/LatinIME/java/src/com/android/inputmethod/latin/BinaryDictionary.java
String DICTIONARY_PACK_AUTHORITY =
"com.android.inputmethod.latin.dictionarypack";
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.
--
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.
