On 01/08/2013 02:40 PM, Peck, Michael A wrote:
I'm curious what kinds of per-app compatibility issues have occurred?
Android recently deprecated Context.MODE_WORLD_READABLE and
MODE_WORLD_WRITABLE, which could help in making an argument that they really
don't want apps to be able to access the internal storage directories of other
apps?
http://developer.android.com/reference/android/content/Context.html#MODE_WORLD_READABLE
I did run into an app that shares world readable (and encrypted) files in its
internal storage directory with other apps -- that would be one example of a
compatibility issue. (I'd argue that they should use a Content Provider
instead.)
We started with levelFromUid=true (now levelFrom=app) for all app
domains (user=_app) in seapp_contexts. But CTS testing and code
examination indicated numerous cases where apps share files. We tried
liberalizing the mls constraints to only constrain open, not read/write,
for app data files so that apps could still voluntarily pass around open
files via Binder but not access one another's files by pathname. But we
saw numerous cases where they do that as well, e.g. for shared_prefs and
the like. So we backed off to only applying levelFromUid=true /
levelFrom=app to third party apps, the current state of seapp_contexts.
Even that is going to run up against examples like the one you describe.
If you have a good test suite of apps, then it might be interesting to
see how often that pattern is violated.
--
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.
