On Thu, Aug 26, 2010 at 10:18 AM, Tauren <[email protected]> wrote:
> Apps are thoroughly reviewed (supposedly) and
> request what kind of permissions are in use.
Permission enforcement doesn't not require review, it is done at runtime by
the platform.
> Sandboxing is not
> unbeatable as proven by existing exploits, for example the Iphones
> jail break me escaped the sandbox of the browser after a PDF was
> rendered and used a kernel vulnerability to run its "jail break code"
> this could easily have been "Pwn me" code and it would have been done
> with.
>
Browser sandboxing is actually very different than the sandboxing that
Android uses. A browser sandbox is a large amount of code implementing the
HTML/JavaScript/etc that prevents it from doing anything malicious. Because
this code is so complicated, the browser sandbox is notoriously porous as
new bugs are discovered in the code. (Same thing applies to code that
handles media codecs.)
In addition, PDF is not inside of the "browser sandbox." PDF is its own
thing, implementing its own sandbox as part of interpreting PDF code.
Traditionally on a desktop the browser runs as you, and can do anything you
can. You are protected from malicious web sites by the browser preventing
them from directly running code in its implementation. Likewise a PDF
viewer, flash, etc. If someone finds a bug somewhere in that code to escape
the sandbox, then it has as much access to the computer as you do... which
is a lot.
On Android in addition to the browser's sandbox, the platform implements a
sandbox for each app. App's don't run as you, they run as their own user
which can only do the things they are allowed by the permissions they
request. So if someone escapes the browser's sandbox, they are still
contained within the platform's app sandbox, so they can only get access to
the browser app itself (its cookies, history, etc) and the few things it is
allowed to do with the outside world:
<uses-permission
android:name="android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission
android:name="android.permission.ACCESS_DOWNLOAD_MANAGER"/>
<uses-permission
android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission
android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
<uses-permission
android:name="com.android.launcher.permission.INSTALL_SHORTCUT"/>
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.SET_WALLPAPER" />
<uses-permission android:name="android.permission.WAKE_LOCK"/>
<uses-permission
android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission
android:name="com.android.browser.permission.READ_HISTORY_BOOKMARKS"/>
<uses-permission
android:name="com.android.browser.permission.WRITE_HISTORY_BOOKMARKS"/>
<uses-permission
android:name="android.permission.SEND_DOWNLOAD_COMPLETED_INTENTS" />
This same rule applies to other things -- media codecs run under a different
user with their own set of limited permissions, etc.
This is somewhat like Chrome's process sandboxing, but applied to the entire
platform.
Of course there will sometimes be bugs in the platform's sandboxing (there
are always bugs). Having multiple layers of security however makes it less
easy to do damage.
--
Dianne Hackborn
Android framework engineer
[email protected]
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google Groups
"Android Security Discussions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/android-security-discuss?hl=en.
