Hi,
Reading this thread again, I feel like clarifying a few points.
On 06/29/2011 10:03 PM, Nick Copeland wrote:
No,
technically, an app can load a native shared library provided by
another
without caring about any kind of signature. An
app can freely dlopen()
a library
provided by another app.
Hm, are the issues related to that library being in an APK? I don't see
how you can
have Android give you access to somebody else's library unless you have
been signed
with the same private key. If you are saying 'technically' accessing
system libraries
then I agree but in that case you have an issue with distributing the
library as you
cannot distribute system libraries via the Android processes.
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:
http://groups.google.com/group/android-ndk/msg/05aae4aafb266cf1
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
resources
that you have not been given a priori permission to use to ensure the
system cannot
be compromised by malicious code. If you want to root your device and
hack it to get
to the point where you can overcome that security then that can be
achieved but that
comes back to another point I made:
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":
http://groups.google.com/group/android-ndk/msg/15a412a317a034bf
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
sandboxing.
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.
--
Olivier