Reading this thread again, I feel like clarifying a few points.
On 06/29/2011 10:03 PM, Nick Copeland wrote:
You are confusing a real lot of things here.
The APK package signature have nothing to do with accessing another package data
files or libraries.
I am not talking about accessing system libraries. I am talking about one
application accessing the shared libraries provided by a third-party application.
When an application gets installed, the Android Manager installs the libraries
that it provides into the application data directory, in the lib/ subfolder. And
these libraries are world readable and executable.
In the past I was also puzzled by this, and thought it was risky to rely on it,
but I discussed this many times on the android-ndk mailing list, with Android
lead developers, and it came out to be reliable.
These are not suppositions. There have been numerous discussions. And here's the
conclusion about accessing another app's libraries, by Dianne Hackborn ("a
Software Engineer who sits very near the exact center of everything Android"),
answering my questions:
Now, on Andraudio, I have indicated that there's a security issue. Indeed,
Dianne insists a lot on the fact that altough loading and running a third party
.so is absolutely feasible, it happens at 100% under the responsibility of the
app which executes the code.
What this means is that, if an app loads a malicious plugin, then it could be
reported as a malicious app, and be banned from the Market, etc...
> Perhaps I have missed the point, Android security prevents you accessing
Yes, you misunderstand the permission system and the Android security model.
I'm not implying any kind of rooting and all that. I'm talking about plain
non-rooted standard Android.
On Android, the security model regarding applications is based on sandboxing.
Such sandboxing in turn relies on the fact that each application gets assigned a
unique user ID. And permissions (internet access, sdcard write access, etc...)
are bound to the user ID.
Reading data from another application directory or APK is not affected by this
permission at all. Actually, preventing such read access is considered "futile":
But this doesn't allow a given application to perform what another application
has the permissions to do. App A can read/execute the data and code provided by
app B, but it doesn't grant the permissions of app B to A, because of user ID
For this very purpose, an application can actually define custom permissions,
that third party apps have to request explicitly (and the user agree), so that
another app can for example call a restricted remote API through (Binder) IPC.
Linux-audio-dev mailing list