More Applications on SDCARD

150 views
Skip to first unread message

lbcoder

unread,
Oct 22, 2009, 1:47:44 PM10/22/09
to android-platform
In looking through the various threads, I see that there are some
questions on how to handle application storage on SDCARD safely and
securely.

I would like to propose a mechanism for handling this in a manner that
is fair, safe, and secure, however there are bound to be questions
and or unforseen issues.

First, in simplest form, the minimum requirements:

1) Application and all application data to be stored externally on
sdcard.
2) SDCARD must be able to be removed and replaced at will, including
possibility of being replaced with a different sdcard.
3) Contingency must be made for possibility of installing application
both internally as well as on sdcard.
4) Protected applications installed to sdcard must remain secure.
5) Insertion of sdcard into another device should allow application to
function in other device except in the case where the application is
"protected".
6) SDCARD must be protected from MS-hostility, i.e. mounting sdcard to
a computer (via usb to phone) must not prompt non-expert users that
they should format it.

Scheme:
i) Need to segregate a group of user id's for use as sdcard-UIDs (i.e.
20000-29999).
ii) Need app, app-private, data, and dalvik-cache directory on sdcard.
iii) Need a packages.xml on sdcard.
iv) Upon unmount need to (in order):
a) kill all running sdcard processes.
b) refresh package list (modify the package manager to update package
status by rereading /data/system/packages.xml and sdcard's
packages.xml).
c) actually unmount the partition.
v) Need to modify installer to prompt for where to install to (if
sdcard is available).

Problems:
1) When sdcard is yanked-without-unmount by non-expert user, running
application may crash.
2) Multiple current installations of the same application -- how to
select between?
3) Copying of protected applications is trivial.
4) How to control per-process permissions on a card from an unknown
source?
5) How to safely allow sdcard to be mounted to a separate computer
without non-expert user reformatting.
6) SDCARD applications added to the home screen.

Solutions:
1) Android already kills off background processes to free up memory.
This can be extended to kill off ALL background processes running on
SDCARD. The problem here is in the event that a running/foreground app
is forcibly removed. SDCARD removal (forcefully) should kill all
processes that would safely be killed off for memory cleanup, and
forcefully (kill -9) all processes that can't be safely killed. Should
also show the user an error message that says something like "You
removed the sdcard without unmounting, the following sdcard
applications were running and had to be killed. All unsaved data has
been lost." There is no need to get fancy and save the application
states.
1b) In the event that the user chose to safely unmount the sdcard, IF
there are running applications, show a message like "The following
applications on the SDCARD are currently running: ... If you continue,
these applications will be killed. Would you like to proceed?"
2) In the event of multiple of the same applications installed
(internal and sdcard), choose to run the one on INTERNAL (do not add
the external one to the application manager). I.e., when scanning the
applications on the sdcard, if (application exists on internal memory)
do not add to application manager. The assumption being that if you
have it installed internally, then the REASON is that you want it to
be available when you remove or change sdcard.
3) Two possible solutions to this;
a) (I don't like this one) -- don't allow protected apps to be
installed to sdcard at all. This would be perceived as hostile to
software vendors wishing their apps to be copy protected.
b) encrypt protected app's apk and dalvik cache using a key stored
internally. If the card is inserted into another device, it will not
have the necessary decryption key and therefore can either not show
the application at all, or it can show the application as "not
licensed for this device".
(*) note: it is not necessary to secure non-protected apps, free or
priced, since it is by the seller choice that there is no copy
protection on the app.
4) THIS IS A BIG ONE... Insertion and removal of other sdcards,
particularly given the possibility that the sdcard belongs to someone
else and/or stands the possibility that it has been tampered with. I
suggest that there be a group of secure databases on the sdcard, one
for each device that the card has been inserted into, this database is
encrypted by the devices encryption key (the same one as 3(b)). If you
insert an sdcard which has not been used in your device before, it
will create a new encrypted database and ask which applications to
allow (showing, of course, their permission requests). The resulting
database would hold the kind of data corresponding to /data/system/
packages.xml. There would, of course, also be an option to delete the
databases for "other" devices (which would prompt the same rebuild).
There must be, of course, a "master" databases on the sdcard showing
ALL installed apps, upon insertion, this must be compared to the per-
device database resulting in the user being prompted for any new
applications and for removing from the per-device database, any
obsolete entries.
5) Since due to other-device compatibility, it must remain fat32,
there are two options I can think of;
a) loopback filesystem within the primary fat32 filesystem. This would
fly under the radar of MS's hostility routines. Secondary benefit is
that it would easily allow advanced users to 'mount -o loop' the
application filesystem.
b) modify the mass storage controller code to only show the fat32
filesystem. Makes it a little more akward for advanced users.
(*) there is another FEATURE that could be added, not exactly
relevant, but related... Change the mass storage driver to present a
*virtual* filesystem, i.e., be able to leave the sdcard MOUNTED, but
still grant access to it (i.e. how NFS is able to share a filesystem
to (multiple) other machines without making it unavailable to the
host.
6) Two options;
a) tag it as unavailable. If a different sdcard is inserted containing
the same app, it would also activate that one. If the same app is
later added to internal, it would activate that, i.e., the intent
would be the same since it isn't related to the UID.
b) don't allow sdcard apps to be added to the home screen. This is
just slightly easier, but not by much. It is also less "cool".

I would like to hear about any holes in this scheme that anyone can
think of.
And please, if you wish to contribute, be precise about any problems
that you see with this, and if possible, a solution *within the
bounds* of the infrastructure I have presented. I would rather not
have this degenerate into a "yeah, its nice, but wouldn't it be cool
if we did this instead". I would like comments that are constructive
with respect to making these suggestions happen with absolutely as
little modification as is required.

If we are able to come up with a concrete logical scheme, then at that
point I would like to begin working on this from an implementation
perspective, i.e., how to *actually* make it happen.

Eric F

unread,
Oct 22, 2009, 2:43:36 PM10/22/09
to android-platform
A bold move lbcoder!

I think first we should get a confirmation from Google that the list
of requirements is both complete and correct. Otherwise any designed
solution might be for nothing. Also confirmation that they are not
working on this already in their private repo would be nice (although,
we have to be realistic here, this is AOSP we are talking about).

I think there should be some discussion as to #5 on the requirements.
Apps installed on an SD card in an Android 2.5 device and then plugged
into an Android 2.1 device should not necessarily function correctly,
or display at all. What about an app that is tightly coupled with the
contacts of one phone that wouldn't make sense to run on a second
phone with the same app data, and would make more sense to start
separate app data per phone.

Also, I think added to the requirements should be determined if the
capability to support multiple cards should be:
1) Designed to be explicitly never supported
2) Designed to one day work with more improvements in a way that is
compatible with the design for supporting one card
3) Designed to be supported

A good design takes into account where Android and Android devices
might be in 2 years, not just what's in the stores today.

I agree that some kind of loopback filesystem on the fat32 card is in
order. I had a post a while back describing how I thought the UI and
the user should have to deal with creating this section of the memory
card, changing its size, deleting, installing apps etc. Remember
people can also eject the card and insert it into a card reader on
their computer, so I am not sure how well just reporting fat32 over
usb mass storage is sufficient to protect users from formatting their
cards by accident.

-E

Jean-Baptiste Queru

unread,
Oct 22, 2009, 3:31:17 PM10/22/09
to android-...@googlegroups.com
All right, here are a few hints of things which I think have been
discussed in the past (though I don't remember whether that was in
public or not).

-application and its data stored on the same volume. Internal apps
store data internally, sdcard apps store data on sdcard.

-apps and their data as stored on SD are tied to the device that
installed them, can't be read on a PC or on another device (i.e.
crypto).

-shared UIDs need to work, one way or another. That's the tricky
design part IMHO when it comes to dealing with UIDs (or maybe this is
where we need to make big simplifying decisions).


The basic idea for the filesystem-level work is to create an e3fs
image (or equivalent) in an encrypted disk image on the SD card. with
the crypto key being stored on /data (so that access to it goes away
after a factory reset).

A significant implementation detail is that all processes that have
file opened on the SD card either need to close them or be killed.
Once apps get on the SD card, you end up in a situation where the
system server will need to do that too; in addition to all the
"legitimate" codepaths to deal with, we also think that there are
cases there the system server leaks open file descriptors of apks.

A further simplifying assumption might be to only allow one SD card
with apps tracked by the system at any time.

JBQ
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

Al Sutton

unread,
Oct 22, 2009, 4:30:49 PM10/22/09
to android-...@googlegroups.com
On the UIDs issue, can't a "drive id" be used as part of the UID
associated with an app?

For example, if we use 0 for internal, 1 for the first SD, etc. then
an app can get a UID of 0x1234 when its' installed, but would be run
with a UID of 0x001234 if its' run from internal storage, 0x011234 if
run from "drive" 1, 0x021234 if user from "drive" 2, etc.

That way any device an SD card is inserted into only needs to worry
about uniqueness of the UID within the device as opposed to uniqueness
across any system it's inserted into.

Al.
--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

Jean-Baptiste Queru

unread,
Oct 22, 2009, 4:44:36 PM10/22/09
to android-...@googlegroups.com
Where things become messy is really when you start to deal with shared UIDs.

App1 is installed on the SD card. SD card gets ejected. App2 (which
requests a shared UID with App1) is installed on internal storage. SD
card is put back in. App2 notices that App1 is around, tries to access
App1's files. If they don't have the same UID, kaboom.

(extend the scenario a bit further, assume that you have that scenario
covered with shared UIDs, insert SD card 2, install App3 on SD card 2
that requests the same UID as App1. Now you need to have apps on SD
cards 1 and 2 that need to share a UID).


Seriously, really really don't try to use the same apps installed on 1
SD card onto multiple devices. Really, don't. The associated can of
worms is so huge that it would delay apps2sd by months or doom it
forever.

Even with many simplifying assumptions (1 device, 1 SD card, no
hot-plug) this is a tricky enough problem.

JBQ

PS: don't forget the case where you install updates for system apps.
Chances are, those really need to only ever go on internal storage
(yet another simplifying assumption), at least so that both the
original and the new variant share the same data directory.

Eric F

unread,
Oct 22, 2009, 8:05:48 PM10/22/09
to android-platform
I think the idea of swapping "SD cards" is a bit of an antiquated
notion. Back when people bought 512 MB cards this maybe made sense.
But today's cards are 16 or 32 GB. They are more like a configurable
hard disk for the cell phone. Like when you buy a Mac Mini you get to
choose how big of a disk drive you want. I can't really imagine a
situation where I'd want to have different apps on different SD cards
and switch between them. Sure in a perfect world it should still work.
But if it degrades from the system being able to work smoothly in
other areas, I don't think this is a bad thing to give up. Especially
if it's possible to A) take the file that represents the encrypted
file system and copy it to the computer, and then copy it to a second
card. So let's say we bought an 8GB card thinking that would be
sufficient. Later we realize we wanted a 16 GB card, we move the file
between cards using a computer and then use Android to resize the
filesystem to our new choice, preserving our installed apps.

I can't see normal users "swapping cards", so that leaves us with
power users. I think most power users are hungry for the largest/
fastest SD card they can get their hands on. Which means 16 (soon 32)
GB cards, how many of those is a user going to need? Many phones are
putting the flash card underneath the battery. I just can't imagine a
real situation where a real user would want to swap between two
different sets of installed apps.

The most realistic thing I can think of is a video fiend carries
around a huge movie collection split between 3 or 4 32GB cards. In the
situation where external apps are only located on one card per device.
One of the cards contains say 4GB of apps and the rest are videos. The
rest of the cards contain no apps (because of this proposed
limitation) and all videos. What are the possible problems? The user
only switches to one of the "non apps" card when they want to watch
one of the films. So they aren't likely to be using many apps. The
apps that the user wants to use will hopefully fit on internal
storage. Whereas most of the SD card based apps are large games,
foreground stuff.

Anyone see this in a different way?
> >> On Thu, Oct 22, 2009 at 11:43 AM, Eric F <ericfrie...@gmail.com>
> ...
>
> read more »

Al Sutton

unread,
Oct 23, 2009, 2:56:22 AM10/23/09
to android-...@googlegroups.com
I've never been a fan of assuming how a user uses their device and not
including functionality on that basis.

Personally I can see people temporarily swapping SD cards so they can
try out other peoples apps on their phone, so I can see the need to
handle it properly.

Al.
--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

Al Sutton

unread,
Oct 23, 2009, 2:58:31 AM10/23/09
to android-...@googlegroups.com
From what I've seen most apps don't use a shared UID, so as step one
down the path to SD-apps goodness could we not allow non-share UID
apps to run from SD and limited shared UID apps to internal storage.

I know it's not ideal, but its' one step up from where we are now
where even if an app doesn't need a shared UID its' still forced to
only be runnable from internal storage.

Al.
--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

Jean-Baptiste Queru

unread,
Oct 23, 2009, 8:28:47 AM10/23/09
to android-...@googlegroups.com
Well, as soon as we allow something like that, we can't allow
forward-locked apps on the SD card, and those are likely to be the
largest ones, i.e. the ones that'd benefit most from being installed
there. Maybe that could be worked around by keeping the "protected"
parts of the app on internal storage, and putting the rest on the SD
card. I'm not sure that users would understand why only some of their
apps can be shared between devices.

This opens a lot of other cans of worms: e.g. this'll create
situations where the same app is installed on the internal storage and
on the SD card. This doesn't directly allow to guarantee overall
uniqueness of UIDs on a given device. This creates some nasty issues
of compatibility if developers start to fine-tune individual versions
of their app for individual devices and an SD card is shared between
non-identical devices. This would also require to re-validate all the
permissions of all the SD-card apps whenever that SD-card is mounted
on a device (including at each boot). In general, this would create a
truckload of security issues, since no device can't trust the content
of the SD card.

Like I said, this is something that we should really really really not
try to do in a first version - it'd doom the feature to being so hard
to implement and to have so many subtle issues that I guarantee it'd
delay it much further. Enough users have been vocal enough about this
that I strongly feel that we should aim for something simple that's
more likely to be feasible (because "simple" is already going to be
hard enough).

JBQ

Jean-Baptiste Queru

unread,
Oct 23, 2009, 8:05:37 AM10/23/09
to android-...@googlegroups.com
That's the kind of simplification I had in mind. It's unfortunate,
though, as shared UIDs are a great mechanism, and it'd be sad if we
gave developers a negative incentive against using it ("if you used
shred UIDs, your app won't be installable on the SD card").

JBQ

Al Sutton

unread,
Oct 23, 2009, 8:51:03 AM10/23/09
to android-...@googlegroups.com
My view on this is shared UID apps don't lose anything by this, but non-shared UID apps gain the ability to run from SD cards, so its' improving the platform in general whilst not taking anything away.

Hopefully future work will help shared-UID apps as well, but I think the benefits to users from implementing this outweigh the benefits of trying to create the perfect solution for both types of apps.

Al.
________________________________________
From: android-...@googlegroups.com [android-...@googlegroups.com] On Behalf Of Jean-Baptiste Queru [j...@android.com]
Sent: 23 October 2009 13:05
To: android-...@googlegroups.com
Subject: Re: More Applications on SDCARD

Al Sutton

unread,
Oct 23, 2009, 8:56:19 AM10/23/09
to android-...@googlegroups.com
Fair points. I can see the benefits of not trying to solve this as part of the first step towards SD-card apps given that a solution which addresses all these points will only delay things and may only benefit a limited number of users.

Al.
________________________________________
From: android-...@googlegroups.com [android-...@googlegroups.com] On Behalf Of Jean-Baptiste Queru [j...@android.com]
Sent: 23 October 2009 13:28
To: android-...@googlegroups.com
Subject: Re: More Applications on SDCARD

lbcoder

unread,
Oct 26, 2009, 12:20:33 PM10/26/09
to android-platform
For your first point, yes obviously the app and associated data must
be on the same volume.

For the second point, why? Should it not be that only *protected* apps
be associated with a particular device? Since it is the protection
itself that defines whether the app is or is not portable to other
devices, i.e., being UNprotected should be considered as authorization
to copy/backup/etc. Why else would they be separated within /data/app
and /data/app-private. I suggest that /sdcard/app-private be encrypted
and that /sdcard/app be open. My concern on this point is the
performance impact associated with encryption/decryption, particularly
with such weak processors. Also, the entire volume need not be
encrypted as a single unit. What is wrong with simply encrypting the
particular files themselves?

Note: the same encryption key could be used for multiple SDCARDs.

Regarding the shared UIDs, the simpler the better. Which is why I
propose that a specific RANGE of UIDs be used for external-apps. If
ALL external apps are given an ID within a specific range, and no
OTHER apps are given an ID within that range, then you are guaranteed
that no unit can possibly have (accidentally) overlapping UIDs. ** now
I understand the need for multiple installed packages to share UIDs by
design, but this is in the case of app-dependencies. The simplest
resolution to this is that for an app to be installed INTERNALLY using
a shared UID, the UID that it shares must ALSO be installed
INTERNALLY. If the app that it depends on is stored EXTERNALLY, then
it must too be installed EXTERNALLY. I don't know about the case of
installing an app externally with a dependency that is already
installed internally. Might be easiest for such dependencies to always
be stored in the same place.

Regarding open sdcard files....
Given a safe unmount of the external media, would this not allow the
system to track and safely close open file descriptors? I.e., the
umount command will fail if there are open file descriptors, so a
minor extension to this would allow us to cleanly kill processes
holding open file descriptors to that media -- I would be inclined to
simply put a "There are open files, these will be closed. Are you
sure?" message, which would then go and kill those processes safely.
Given an unsafe unmount, could we not just "kill -9" all processes
within "lsof | grep '\/sdcard'" or whatever? Isn't something like that
happening already? I.e., any process that has an open file descriptor
on the sdcard *in current versions* must have those file descriptors
closed/processes killed/etc.
> ...
>
> read more »

lbcoder

unread,
Oct 26, 2009, 12:24:30 PM10/26/09
to android-platform
Yes, force app dependencies to be installed to the same media.

App2 shares UID with App1. They must both be installed internally or
must both be installed externally.
I can't see any way that there could be a conflict given this scheme.
> >> On Thu, Oct 22, 2009 at 11:43 AM, Eric F <ericfrie...@gmail.com>
> ...
>
> read more »

lbcoder

unread,
Oct 26, 2009, 12:41:58 PM10/26/09
to android-platform
I think I touched on this in the thread starter.

i.e., keep any number of per-device configurations within the same
sdcard for the possibility of sharing to other devices. If the per-
device configuration is encrypted, then upon sdcard insertion, only
those apps permitted by that device are runnable. And we can either
key-check those apps on insertion, OR run a simple SHA hash of the
file. If the hash doesn't match what is stored in the per-device
configuration, request authorization refresh. If the per-device
configuration doesn't exist, create it and go through the full
authorization requests. The user can put a checkmark beside each app
they want to authorize.

i.e., the sdcard has a "master" packages.xml, and for each device, it
has a "deviceid-packages.xml" which is a subset of the master
packages.xml for that card.

Regarding users not understanding why some apps can't be shared
between devices... I think that it is important that they be warned of
this. You can give them a LIST of *ALL* of the apps that are installed
on the card, and do something along the lines of greying out the
"protected" apps. If a user tries to authorize a protected app, give
them a warning that says "This app is not authorized. The app
developer requires that this app be restricted to the device it was
initially installed on". That should make it pretty clear. And since
the apk is encrypted using the same key as the deviceid-packages.xml
file for the device it was initially installed on, it will be
gibberish to any other device, so even if they hacked the
authorization dialog, it would still be impossible to run it.

Jean-Baptiste Queru

unread,
Oct 26, 2009, 1:28:46 PM10/26/09
to android-...@googlegroups.com
The notion of encrypting per-device auth stuff is pretty interesting,
though it obviously adds quite an extra level of complexity.

Keeping the filesystem unencrypted, though, opens quite some cans of
security worms that might be worth avoiding as a starting point.

JBQ

Patrick Ethier

unread,
Oct 26, 2009, 2:40:38 PM10/26/09
to android-...@googlegroups.com
Would someone care to elaborate how the keys to perform all this encryption
are going to be managed?

I've been poking around the source code looking at the JCE stuff (mainly
bouncy castle) and my assumption here is that in order for this to work
properly we'd need to have a definitive key store. Although seems trivial to
generate a Java keystore it becomes less apparent how to integrate the
securing and management of the key store from an end-user perspective.

I'd assume that the private key on each device would have to be protected and
integrated with the phone security mechanisms (Unlock Pattern/SIM PIN) in
order to make any sense or be usable for the end-user. We'd need probably
need a way to "tie" the key and the keystore to the actual device so it
cannot simply be copied off the device and replicated (moving from a
hardware device to an emulator for example). Ideally using some hardware
link, maybe leveraging some of the SIM's crypto capabilities (The intent is
to avoid making this a GSM specific feature but I don`t see how else to
manage right now).

Once you generate this secured key, you can then start doing things like
encrypting packages onto a card and doing signed meta-data manifests.

I'm struggling with a similar problem right now looking at how to get a
device specific PGP (or GPG) key installed on a device in order to enable
secured communications.

If the above is something that the AOSP team would be interested in as a
feature I`d definitely be open to attempt taking it on as a project.

Regards,
Pat


-----Original Message-----
From: android-...@googlegroups.com
[mailto:android-...@googlegroups.com] On Behalf Of Jean-Baptiste Queru
Sent: October-26-09 1:29 PM
To: android-...@googlegroups.com
Subject: Re: More Applications on SDCARD


Jean-Baptiste Queru

unread,
Oct 26, 2009, 2:45:52 PM10/26/09
to android-...@googlegroups.com
The plan is to store the (randomly-generated) key on /data, with no
user intervention - it doesn't need to be stored any more securely
than anything that's already on /data, since it protects data that's
not any more sensitive than the one on /data.

JBQ

Al Sutton

unread,
Oct 26, 2009, 3:03:18 PM10/26/09
to android-...@googlegroups.com
So what would stop someone with root extracting the key and passing it
over to someone else, thus making the SD card & key a pair?

It might be worth encrypting the key with PKCS#5 (password based
encryption, which is already present in the build according to http://developer.android.com/intl/zh-TW/reference/javax/crypto/spec/package-descr.html
) using the device ID in the OS so that any key copied around won't
decrypt on another device without a fair chunk of work.

Al.

--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

Patrick Ethier

unread,
Oct 26, 2009, 3:08:24 PM10/26/09
to android-...@googlegroups.com
This is what I`m alluding to. Using any PBE mechanism will be somewhat
frustrating to the end-user (always think that your grandmother is stuck
operating the device) unless it's integrated in the phone lock/unlock
mechanism.

And yes, copying the key off of /data will be somewhat trivial for anybody
who is motivated enough to get an app working on multiple devices when it
shouldn't unless that key is protected somehow.

Pat


-----Original Message-----
From: android-...@googlegroups.com
[mailto:android-...@googlegroups.com] On Behalf Of Al Sutton
Sent: October-26-09 3:03 PM
To: android-...@googlegroups.com
Subject: Re: More Applications on SDCARD


Jean-Baptiste Queru

unread,
Oct 26, 2009, 3:10:53 PM10/26/09
to android-...@googlegroups.com
Nothing would stop someone with root access from reading the key, but
then if they have root access they can already read all the files that
the key protects, so this doesn't weaken security.

JBQ

lbcoder

unread,
Oct 26, 2009, 4:58:47 PM10/26/09
to android-platform
I don't think that we need to worry about passwords here... fact is
that if a user password is the key to decryption, then the user knows
the key, which means that they can copy the data we are trying to keep
from being copied. The key has to be random, generated by some
gatekeeper (who would that be?), or hardware-based (i.e. IMEI/SN). The
problem is that no matter what the key is, it *must* be stored
somewhere, and at some point *must* be in memory, and with root, there
is NO place on the phone where it can be stored where it can't be
read, including in ram. This means that the best copy protection
available is equal to the *existing* copy protection, which is
dependent on *regular* users not being able to read anything out of /
data/app-private due to lack of permissions.

The security against root access copying currently works like this;
if (device==ADP1) market-enable-private=false; //or something to that
effect

And quite frankly, it doesn't work since it is trivial for a root user
to pretend to be a G1.

Which means that the whole copy protection issue is there to *limit*
copying (i.e. with regards to the *majority* of users who don't have
root), rather than block it entirely. Regardless of the anti-piracy
scheme, there will always be *someone* who will find a way to get
around it, but for the majority of users, the objective is simply to
make it too technical for them to easily be able to email programs
back and forth to each other, i.e., they will have to find a hacker
website or a root user who isn't worried about the moral issues of
piracy.



On Oct 26, 3:08 pm, "Patrick Ethier" <patr...@secureops.com> wrote:
> This is what I`m alluding to. Using any PBE mechanism will be somewhat
> frustrating to the end-user (always think that your grandmother is stuck
> operating the device) unless it's integrated in the phone lock/unlock
> mechanism.
>
> And yes, copying the key off of /data will be somewhat trivial for anybody
> who is motivated enough to get an app working on multiple devices when it
> shouldn't unless that key is protected somehow.
>
> Pat
>
> -----Original Message-----
> From: android-...@googlegroups.com
>
> [mailto:android-...@googlegroups.com] On Behalf Of Al Sutton
> Sent: October-26-09 3:03 PM
> To: android-...@googlegroups.com
> Subject: Re: More Applications on SDCARD
>
> So what would stop someone with root extracting the key and passing it  
> over to someone else, thus making the SD card & key a pair?
>
> It might be worth encrypting the key with PKCS#5 (password based  
> encryption, which is already present in the build according tohttp://developer.android.com/intl/zh-TW/reference/javax/crypto/spec/p...
> escr.html
> ) using the device ID in the OS so that any key copied around won't  
> decrypt on another device without a fair chunk of work.
>
> Al.
>
> --
>
> * Looking for Android Apps? - Tryhttp://andappstore.com/*
>
> ======
> Funky Android Limited is registered in England & Wales with the  
> company number  6741909.
>
> The views expressed in this email are those of the author and not  
> necessarily those of Funky Android Limited, it's associates, or it's  
> subsidiaries.
>
> On 26 Oct 2009, at 18:45, Jean-Baptiste Queru wrote:
>
> > The plan is to store the (randomly-generated) key on /data, with no
> > user intervention - it doesn't need to be stored any more securely
> > than anything that's already on /data, since it protects data that's
> > not any more sensitive than the one on /data.
>
> > JBQ
>
> > On Mon, Oct 26, 2009 at 11:40 AM, Patrick Ethier <patr...@secureops.com
> ...
>
> read more »

lbcoder

unread,
Oct 26, 2009, 5:02:44 PM10/26/09
to android-platform
The problem is that where there's a will, there's a way... it would
actually be quite trivial. A simple patch to the decryption program to
input the device ID/IMEI/whatever manually rather than actually
reading it from hardware.

On Oct 26, 3:03 pm, Al Sutton <a...@funkyandroid.com> wrote:
> So what would stop someone with root extracting the key and passing it  
> over to someone else, thus making the SD card & key a pair?
>
> It might be worth encrypting the key with PKCS#5 (password based  
> encryption, which is already present in the build according tohttp://developer.android.com/intl/zh-TW/reference/javax/crypto/spec/p...
> ) using the device ID in the OS so that any key copied around won't  
> decrypt on another device without a fair chunk of work.
>
> Al.
>
> --
>
> * Looking for Android Apps? - Tryhttp://andappstore.com/*
>
> ======
> Funky Android Limited is registered in England & Wales with the  
> company number  6741909.
>
> The views expressed in this email are those of the author and not  
> necessarily those of Funky Android Limited, it's associates, or it's  
> subsidiaries.
>
> On 26 Oct 2009, at 18:45, Jean-Baptiste Queru wrote:
>
>
>
> > The plan is to store the (randomly-generated) key on /data, with no
> > user intervention - it doesn't need to be stored any more securely
> > than anything that's already on /data, since it protects data that's
> > not any more sensitive than the one on /data.
>
> > JBQ
>
> > On Mon, Oct 26, 2009 at 11:40 AM, Patrick Ethier <patr...@secureops.com
> ...
>
> read more »

Eric F

unread,
Oct 27, 2009, 5:35:26 PM10/27/09
to android-platform
I've followed every single Apps on SD card thread that's ever been on
android-platform AND android-discuss. People act like "this issue has
been hashed out over and over again previously" as a way of dismissing
any communication on this. The truth is the tip of the iceberg has
barely been reached each time.

Now that it is clear that Android 2.0 does not support any kind of
apps on SD and that Google still neglected to hit the send button on
the email saying "512MB isn't really enough guys". We need to revisit
this. We need a complete list of requirements from OHA that are non
negotiable (as in, a guarantee that a solution meeting those
requirements can be merged into AOSP master). We need the Android
developers responsible for:

vold
Package Installation Manager
All the SD card related settings, setup, etc
Application security model
Possibly someone low level on Dalvik to answer questions on memory
management and process killing in the event of SD card failure
Launcher (we want to gray out unavailable programs)
and we probably need an Android Product Manager (if you have such a
role)

We need these people to join this discussion and make sure at the very
least they put in what OHA requirements are non-negotiable, what
problems they foresee, and optionally ideas on how to go start a final
design.

Let's be serious. Just tell us this will or won't happen so we don't
waste OUR valuable time. Otherwise whatever ends up sounding good here
after a lot of careful design will just be discarded in one sentence
by the above individuals at a later date. I would just like an end to
the hypocrisy. Just say "this isn't going to happen. sorry guys, maybe
next year" if that's what you mean. Otherwise, the people involved
should start collaborating, perhaps a wiki design doc and start making
serious progress on this.

-E

Avtar Singh

unread,
Oct 28, 2009, 7:50:28 AM10/28/09
to android-...@googlegroups.com

IMHO, security (all the detail that has been discussed in this thread) and doing it reliably are the main challenges in this requirement. Finding a solution would require fair amount of ingenuity. Whether Google / anyone else like OHA is ready to finding a solution using a community approach is not something that I think will happen in these times. But this is just my opinion...

Jean-Baptiste Queru

unread,
Oct 28, 2009, 8:29:10 AM10/28/09
to android-...@googlegroups.com
All the engineers you mention routinely take part in open discussions:
San for vold and SD card management, Dianne for the application and
security model, Fadden for the dalvik side (though I'm not sure why
that's relevant), Romain for the Launcher side (though anything that'd
require to modify Launcher will need to be considered carefully as it
implies that we're breaking compatibility to some extent).

As for product management, I can play one for 10 seconds: "yes, that
sounds like a good idea, you're the engineers, figure out how to make
it happen when you have time for it".

Some of the hard requirements are:
-security: apps2sd must safeguard users' data and developers' code
with as much security as internal storage.
-stability: apps2sd must not cause the system to crash or leak
(including in situations where an SD card is permanently lost).
-compatibility: apps2sd must allow all existing applications (using
supported APIs) to work without modification (to the extent possible).
-ease of use: apps2sd must work with any SD card without requiring any
complex configuration.
-interoperabilty: apps2sd must work with UMS, and the space used for
apps2sd must be recoverable on a regular computer with no special
tools.
-performance: apps2sd must not cause any significant performance
degradation, including CPU, RAM, and battery life.

There's an additional "soft" requirement:
-hot-swap: apps2sd should work on devices with hot-swappable SD cards.

There might be more requirements, but those are probably a decent
starting point.

A major issue is resources: I'd expect that the people I mentioned
above will have time to discuss the design, the code, etc... but
probably won't have time to actually write any of it in the short
term, so there's no clear black-or-white statement about whether
anyone can or will get involved.

JBQ

lbcoder

unread,
Oct 28, 2009, 9:58:06 AM10/28/09
to android-platform
Actually, I think that this project would be a perfect fit with
another possibility that you mentioned... the community-AOSP branch.
It would allow US to develop the system over a period of time, in the
earlier stages perhaps relaxing some of the security considerations in
favor of getting a stable system (of course taking into consideration
the eventual security requirements). I.e., the first step is to build
the infrastructure that allows a group of apps to be added and removed
from the package manager, the second step is to actually get that onto
a single SDCARD and trigger it by sdcard mount/unmount, the third step
is to deal with UID issues and multiple-sdcards, etc., etc,. Once the
system has advanced to a state where it meets the core-AOSP security
and stability requirements (most likely with the assistance of google
engineers in the latter stages), then it can be merged in and everyone
will be happy.

Obviously, as I'm sure that everybody can agree, the current community-
type apps-on-sdcard system leaves a LOT to be desired, and I think
that this is due to the very limited organizational infrastructure
available to the community. When dealing with a project of this
magnitude, there is simply no sensible way to organize the community.
I'm sure that there are a LOT of people who would like to contribute
to this as long as the entire project doesn't rest on one person's
back.

Disconnect

unread,
Oct 28, 2009, 10:08:47 AM10/28/09
to android-...@googlegroups.com
You're forgetting something easy though, on the security side. It is
required to offer the same protection as onboard storage. So all the
encryption/security mess can go away (for now) because aosp ships with
root. And since the word from the beginning was "its not our fault
devices are all locked down" a "complete" solution for android
doesn't have to include encryption or data-signing. (Yes, that leaves
out retail devices, but it also puts some of the more finicky work out
later and possibly gets vendors to contribute it.)

lbcoder

unread,
Oct 28, 2009, 10:17:21 AM10/28/09
to android-platform
I thought that I just said that...
"in the earlier stages perhaps relaxing some of the security
considerations in
favor of getting a stable system".

The main thing to be wary of is that the infrastructure we develop not
preclude the possibility of security, since this would block it from
ever being merged. That means that we need to discuss and assess the
security issues, just not necessarily IMPLEMENT them [all].

On Oct 28, 10:08 am, Disconnect <dc.disconn...@gmail.com> wrote:
> You're forgetting something easy though, on the security side. It is
> required to offer the same protection as onboard storage. So all the
> encryption/security mess can go away (for now) because aosp ships with
> root. And since the word from the beginning was "its not our fault
> devices are all locked down"  a "complete" solution for android
> doesn't have to include encryption or data-signing. (Yes, that leaves
> out retail devices, but it also puts some of the more finicky work out
> later and possibly gets vendors to contribute it.)
>

Disconnect

unread,
Oct 28, 2009, 10:22:34 AM10/28/09
to android-...@googlegroups.com
My point is that it will likely get merged ANYWAY. It offers exactly
as much data protection as the onboard storage does.

Christopher Tate

unread,
Oct 28, 2009, 11:09:30 AM10/28/09
to android-...@googlegroups.com
For the record there is at least one more hard requirement: the
solution has to support swappable SD cards, and must "do the right
thing" when an app on SD card winds up having the same uid assignment
as an app already installed on the internal disk. REALLY doing the
right thing involves correctly handling the case of explicitly
shared-uid apps in this situation as well as not-shared-uid.

--
chris tate
android framework engineer

lbcoder

unread,
Oct 28, 2009, 12:46:17 PM10/28/09
to android-platform
Guessing at what is and is not likely to be merged is probably a
little off-topic for this thread, but I have to go with the assumption
that it wouldn't be merged without the security features. And this I
judge not by yours or my own relative perception of the security of
this system wrt the existing security, but rather based on statements
made by JBQ on the matter.

And remember that there is more to security than simply copy-
protection. Take for example the situation where you swap sdcards with
someone, and the sdcard you shove into your phone has a malicious app
on it that wants to steal all of your personal information and send it
off to some hacker. There needs to be a permission verification scheme
in place to handle this possibility. When installing an app
internally, *every* app goes through the process where it shows what
permissions it requires and gives you the option to decline if you
aren't comfortable with it -- and obviously, if you shove in an sdcard
with 500 apps installed, you can't individually verify the security
for *every* app *every* time you insert the card... One possibility
would be to verify security at RUNTIME, but this would get invasive/
annoying very quickly, which is why I proposed the encrypted per-
device configuration file. Perhaps security verification at FIRST-
runtime and added to the per-device configuration file? But even that
would create problems since it would require a *very significant*
change in the package manager and what would it be... dalvik?

So we are left with the possibility of leaving it to a single device,
or to use per-device configurations. If it is left to a single device,
then we need only one encrypted packages.xml file on the sdcard
showing all the apps and all installed apps are authorized. If we use
a per-device configuration, then we need a master (unencrypted)
packages.xml file and a per-device file for each device. Regardless of
which device an app is installed from, it is added to the *master*
list and to that device's configuration file.

The way I look at the per-device configuration file is this;
The package manager is only interested in the per-device configuration
file associated with *that device* and needs to be triggered to
refresh whenever the per-device configuration is *changed*. This has
to happen regardless of whether it is a single-device or multi-device
scheme. The package installer needs to be extended to write BOTH the
per-device configuration file as well as the master file in the event
of multi-device configuration. No other (user visible) functions need
to be added to existing infrastructure to handle multi-device
configurations, but will rather be handled by a separate sdcard-app
maintenance program, which has functions as follows; create app-
storage, destroy app-storage, delete app from sdcard (regardless of
what device owns it), delete per-device configuration file (regardless
of what device it relates to), create per-device configuration file
for *current device*, adjust app authorizations (add or remove from
per-device file pertaining to *current* device).

Scheme: insert sdcard, attempt to mount external apps filesystem. If
exists but there is no per-device config file, launch "sdcard
application management interface", which lists all apps on sdcard,
associated permissions for each, and has a checkbox next to each one,
if checked, it is added to the per-device config file (and package
manager/launcher). If it is a protected app, it is shown, but greyed
out for all devices except the authorized device (being encrypted, it
wouldn't be runnable even if it was authorized). Protected apps are
always authorized to the authorized device (so no checkbox). Protected
apps and per-device configuration files can be *deleted* from *any*
device. Upon sdcard insertion, if per-device configuration *does*
exist, verify that all items within the per-device configuration are
within the master configuration and purge as required. Trigger
application manager to incorporate the apps in the per-device
configuration file.

I think that this is actually quite *necessary*.

Now off the topic of security, I would like opinions regarding the
filesystem for storing these apps. Obviously, it needs to be something
that supports a unix security model. But what are our options? Is extX
suitable? There are issues with ext2 associated with an unclean
unmount. Journaled? BTRfs?

And how do we deal with the filesystem? The downside of putting it in
its own partition is that MS's hostility routines will tell users to
format it (which they WILL do for lack of understanding -- so this is
OUT), another downside is that it will have to be configured at
initial sdcard setup. Partition resizing, though possible and safe in
a controlled situation, is too slow and too unreliable to be
implemented in a phone. Loopback mount? Advantages are that there
won't be a format-this prompt on MS and that it can be safely grown as
needed. Disadvantage there is a limit of 4GiB (fat32 filesize limit).
Is there a way around this limit? LVM would do it, but that's way too
resource intense for the hardware (i.e. major performance impact). Any
simple way to create a spanned file? I.e. you have 3 files ".extapps.
1, .extapps.2, .extapps.3", which are regarded as a single file
".extapps", which contains a single loopback filesystem of up to
12GiB. Does it even matter if we are limited to 4GiB? I suppose that
this could be considered as "future expansion" and doesn't necessarily
have to be implemented right away.


On Oct 28, 10:22 am, Disconnect <dc.disconn...@gmail.com> wrote:
> My point is that it will likely get merged ANYWAY. It offers exactly
> as much data protection as the onboard storage does.
>

lbcoder

unread,
Oct 28, 2009, 12:47:49 PM10/28/09
to android-platform
This has already been discussed.
Look back at the first post of this thread.

lbcoder

unread,
Oct 28, 2009, 12:54:07 PM10/28/09
to android-platform
To be more precise..
First post under "Scheme:" (i), and
13th post (second by me), second paragraph starting with "Regarding
the shared UIDs".

What are your thoughts on this?

On Oct 28, 11:09 am, Christopher Tate <ct...@google.com> wrote:

Patrick Ethier

unread,
Oct 28, 2009, 12:58:44 PM10/28/09
to android-...@googlegroups.com
Just a thought on what you describe below.

Wouldn't it be easier to make a "per application" configuration that gets
stored on the device? The device reads the .APK's stored on the card. At
first runtime it generates a hash of the APK and then prompts for
permissions.

Any time that app comes across the device (whether on another SDCARD that the
user used to back up or whatever) the launcher checks the hash to make sure
it's the same application that got approved previously.

You could also, in the same config file, link each app to a local UID so that
you don't run into the UID problem.

Of course, this feels like you now need changes to the app launcher and the
package manager...

Pat


-----Original Message-----
From: android-...@googlegroups.com

Jean-Baptiste Queru

unread,
Oct 28, 2009, 1:01:18 PM10/28/09
to android-...@googlegroups.com
3 words: simplify, simplify, simplify. Assume it's a really hard
problem (if it wasn't, we'd have solved it a long time ago).

-aim to make the SD card work in a single device. Heck, even if the
system can only track a single SD card at a time it's probably still
fine. Personally, I'd hate to put restrictions on shared UIDs but I
guess that's just a pet peeve of mine.

-filesystem: let's assume some permission-enforcing filesystem in an
encrypted disk image stored in a single file (skip the encryption for
initial development). Start with ext2 or ext3. Once the rest of the
system works, we can refine this part as necessary. Partitioning the
SD card isn't an option. Keep UMS in mind, it's probably more tricky
than it seems.

JBQ

lbcoder

unread,
Oct 28, 2009, 1:20:17 PM10/28/09
to android-platform
Could you check your email client settings... it marked this as spam
and added an ugly ***SPAM*** into the thread title.

I think I understand what you are proposing, but here's where it
breaks down; each application has its home path -- currently in /data/
data/package.name. These files are owned by the UID associated with
that particular app in the system. This means that the same UID must
be maintained regardless of what device the card is inserted into.

Could you go back and please consider my UID range segregation
proposal.

Regarding changes to the app launcher and package manager...
obviously, no matter what scheme is settled on, changes will be
required. Though I don't think necessarily to the launcher (although
it would ultimately be nice to have external apps visually separated
from internal apps...).
> ...
>
> read more »

lbcoder

unread,
Oct 28, 2009, 1:48:08 PM10/28/09
to android-platform
I agree that we need to start simple.
However, I am concerned that design decisions early on may negatively
impact the possibility of future enhancements.

I also understand the issue with restricting shared UIDs... so I'll
propose a scenerio:
Application A is installed internally, B is installed externally,
shared UID. Card is removed, application A is uninstalled and then
reinstalled (so it has a new UID). Card is put back in. Now the UIDs
no longer match unless it stores card info internally. Given the
condition proposed by Mr. Tate, we *must* allow swappable sdcards,
which suggests an eventual requirement to be able to track multiple
sdcards containing apps (I think this would lead to user problems
otherwise). And also, given an ultimate goal of being able to share
sdcards between multiple devices (even if it isn't implemented
initially), then shared UIDs become a real nightmare.

So I'm going to suggest that at least this requirement is fairly
simple to deal with.. during the install process, check for shared
UIDs, if shared UIDs are to be used, only allow installation to the
same location as the existing app in the pair. In the event that an
sdcard is inserted containing an app that wants to share UIDs with an
already-internal app, require that this app be installed internally,
i.e. prompt saying "for this app to function, it must be installed
internally. Do you wish to proceed?". Per one of my previous
suggestions, if the app exists in both places, only the internal one
is regarded as being "present".

On Oct 28, 1:01 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> 3 words: simplify, simplify, simplify. Assume it's a really hard
> problem (if it wasn't, we'd have solved it a long time ago).
>
> -aim to make the SD card work in a single device. Heck, even if the
> system can only track a single SD card at a time it's probably still
> fine. Personally, I'd hate to put restrictions on shared UIDs but I
> guess that's just a pet peeve of mine.
>
> -filesystem: let's assume some permission-enforcing filesystem in an
> encrypted disk image stored in a single file (skip the encryption for
> initial development). Start with ext2 or ext3. Once the rest of the
> system works, we can refine this part as necessary. Partitioning the
> SD card isn't an option. Keep UMS in mind, it's probably more tricky
> than it seems.
>
> JBQ
>
> ...
>
> read more »

Disconnect

unread,
Oct 28, 2009, 1:50:37 PM10/28/09
to android-...@googlegroups.com
There is a LOT of info here about requirements. With that in mind, I
created a google doc:
https://docs.google.com/Doc?docid=0ATHAIHhsIvlLZGQ5Zmh3cDJfNWNycTQyOGc4&hl=en

If I missed any features, or miscategorized any, etc please update the
doc. Please don't destroy it. (Does google docs have wave-style undo?)

Jean-Baptiste Queru

unread,
Oct 28, 2009, 1:54:38 PM10/28/09
to android-...@googlegroups.com
The issue of hot-swapping SD card is orthogonal to that of shared UIDs
- you could turn off the phone, swap the SD and turn it back on, and
the same issue would still exist.

There are so many issues with the notion of sharing cards between
devices that I think it should be a non-goal at this point. Really.
It's great to think about it as we go, but I'd have no qualms making
simplifying decisions right now even if those prevent an immediate
extension to card-sharing.

JBQ

Disconnect

unread,
Oct 28, 2009, 1:55:04 PM10/28/09
to android-...@googlegroups.com
As far as filesystem, can I suggest something like encfs?
(http://www.arg0.net/encfs) That specific tool uses some c++
libraries, but that should be fixable. It does per-file encryption, so
space is trivially recoverable, and it uses fuse and openssl (it
should be fairly independent of any underlying hardware changes, and
able to take advantage of any platform/device level ssl enhancements.)

On Wed, Oct 28, 2009 at 1:01 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>

Jean-Baptiste Queru

unread,
Oct 28, 2009, 1:59:43 PM10/28/09
to android-...@googlegroups.com
That's out of my league, to be honest. I guess that it is sufficiently
tamper-proof (i.e. that it's possible to detect whether someone tried
to modify the data from outside this one device, including
adding/deleting files), that should work.

I think that it would make sense to write a first implementation of
the filesystem stuff in order to unblock work on the higher layers,
and then write "real" filesystem-level code.

JBQ

lbcoder

unread,
Oct 28, 2009, 2:32:42 PM10/28/09
to android-platform
Regarding the filesystem... ok, loopback ext3 located at /
sdcard/.extapps limit to 4GiB (for now, we can deal with that limit
later). I like ext3 over ext2 because it (typically) doesn't need an
fsck upon harsh unmount. UMS is no issue here since whatever system
mounts the fat32 filesystem will regard the .extapps as any regular
file. Is there any way we can set the file as "hidden" to MS from
within linux?

So to start;
mkdir /data/extapps
dd if=/dev/zero of=/sdcard/.extapps count=200000
mkfs.ext3 /sdcard/.extapps
mount -o loop -t ext3 /sdcard/.extapps /data/extapps

Step 1... enhance the sdcard mount to first mount /sdcard and then try
to mount /sdcard/.hidden to /data/extapps (or is there another
location that would be preferred?), and then unmount function to first
unmount /sdcard/.hidden and then unmount /sdcard.

Step 2... add to the unmount (before unmounting anything) a check for
open file handles and a request to kill the processes or cancel the
unmount.

Question: What is the preferred way to kill off applications? If the
user answers yes, can we just go and *kill* the processes? or is there
a sane shutdown mechanism? Whatever the answer, we need to go and do
it if the user says to.

Question 2: Where is the current mechanism for handling sdcard removal-
without-unmount?

Step 3: (where it gets fun) fix up package manager to be able to add
and remove apps.

Question: Where is the application home directory location and dalvik
cache location established? (I know where they are presently, I need
to know how *it* knows where they are.)

** after this it should *work* (sortof) -- won't be possible to
install apps onto sdcard and won't be sane shutdown of apps if the
card is forcibly removed without unmounting.

Step 4: update installer to prompt for install location.

** here it will be able to install and run apps from sdcard, but
nothing is done to handle UIDs.

Points of failure after completion of step4:
1) things crash bad when sdcard is pulled without unmount,
2) installation of packages when sdcard is OUT will break things in a
BAD WAY,
3) shared UIDs should still work regardless of where things are
located, but may give unexpected results if member of pair is missing
(card out),
4) applications that refer to their home directory by absolute path
will be broken. I don't know what (if anything) we can do about this
except advise app developers to use '~' to refer to home directories.
Is there any way we can internally rewrite paths that look like "/data/
data/my.package.name/" into "~/"? Or maybe runtime-symlink?,
5) no tracking for sdcard, so if the user swaps in another sdcard with
apps, things will crash.
*note: at this point it is already way better than community-hack.

Step 5+: more installer and package manager updates, handling UIDs,
etc. deal with it when we get there.

Disconnect

unread,
Oct 28, 2009, 2:36:41 PM10/28/09
to android-...@googlegroups.com
Where do you put dalvik cache in this plan? I'm thinking it needs to
be associated with the apk for size, but for speed it shouldn't be
encrypted. (At least for now.) And there should be some way of
detecting tampering, or just regenerate all the caches on insert (SLOW
but unlike boot-time, at least we can provide feedback.)

lbcoder

unread,
Oct 28, 2009, 2:40:42 PM10/28/09
to android-platform
I like that document. I have only skimmed through it so far, and only
two question;
- does "mount -o loop -t ext3 /wherever/it/is/located/.extapps /mnt"
count as "standard tools" or "special tools"? it is perfectly standard
on a linux system, but I doubt that it is at all possible on MS.
- *IS* it really a requirement? A regular user doesn't have the
ability to read files off the internal /data partition unless they
have some specific technical know-how.

On Oct 28, 1:50 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> There is a LOT of info here about requirements. With that in mind, I
> created a google doc:https://docs.google.com/Doc?docid=0ATHAIHhsIvlLZGQ5Zmh3cDJfNWNycTQyOG...

Disconnect

unread,
Oct 28, 2009, 2:45:42 PM10/28/09
to android-...@googlegroups.com
I think - esp for now - it would be considered a pass if "delete
.extapps" was possible. (EG no partitioning or other weirdness)

As an additional thought it might make sense to do each app as it's
own bundle. That way a user can say "Oh! That 2 gig mess is
JoesGiantTileGenerator". Means added complexity on the mounts though.
(Hmm. Adds to security though - even with shared-uid, if a user
refuses the perms on an app it is not mounted..)

lbcoder

unread,
Oct 28, 2009, 2:46:51 PM10/28/09
to android-platform
The APK itself, the application's home directory, and the
application's dalvik-cache must all be within the same device. I was
just about to write 'within the same filesystem', but this isn't
necessarily a requirement, i.e., if you use filesystem-level
encryption vs file-level encryption.

And for the initial development, we aren't going to make any (major)
consideration for encryption, except to note that it eventually must
be done (just so we don't write ourselves into a corner).

On Oct 28, 2:36 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> Where do you put dalvik cache in this plan? I'm thinking it needs to
> be associated with the apk for size, but for speed it shouldn't be
> encrypted. (At least for now.) And there should be some way of
> detecting tampering, or just regenerate all the caches on insert (SLOW
> but unlike boot-time, at least we can provide feedback.)
>

Disconnect

unread,
Oct 28, 2009, 2:55:06 PM10/28/09
to android-...@googlegroups.com
Right, I keep getting twisted up on that :)

The data -should- eventually support encryption, and the cache
-should- support tamper detection or encryption (to match the apk
security) but right now we're assuming aosp with root. Doh.

I updated the doc as well, since data-protection is a soft requirement
(and I fleshed that out a bit, so if someone - eg jbq - could
doublecheck that it is correct from google's side that'd be nice.)

lbcoder

unread,
Oct 28, 2009, 2:55:14 PM10/28/09
to android-platform
An application can't have a negative impact on security except in two
conditions; 1) it is added by the package manager, or 2) it is a
protected app that can easily be copied. Basically, if everything was
within a single external filesystem, it doesn't matter if some of it
is untrusted as long as you don't allow it to run or be accessed by
other regular users, and it can't run unless it is given the
permission to be added to the package manager.

And it is most definitely possible to delete .extapps (i.e. right-
click, delete). And I don't think there is any reason to secure
against it since it must, by definition, be an intentional and user-
initiated event.

On Oct 28, 2:45 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> I think - esp for now - it would be considered a pass if "delete
> .extapps" was possible. (EG no partitioning or other weirdness)
>
> As an additional thought it might make sense to do each app as it's
> own bundle. That way a user can say "Oh! That 2 gig mess is
> JoesGiantTileGenerator". Means added complexity on the mounts though.
> (Hmm. Adds to security though - even with shared-uid, if a user
> refuses the perms on an app it is not mounted..)
>

Disconnect

unread,
Oct 28, 2009, 3:00:11 PM10/28/09
to android-...@googlegroups.com
It could be considered a security impact if an app is refused by the
user (eg tampering or unwanted) and the associated data is accessible
to a different shared uid app. (EG "No, I don't want to run
JohnsKeyLoggerKeyboard" but oops, the logging it did last time is
already available to "JimsInnocentLookingWebSender". If the user
refuses permission, it should behave as if it was not installed - no
app or data access.)

lbcoder

unread,
Oct 28, 2009, 4:13:54 PM10/28/09
to android-platform
Hmm.. that's an interesting perspective.

I'm trying to wrap my head around this; obviously, it must be clear if
there are shared UIDs in use on the card.

The first thing to think about is that this issue only exists in the
case where multiple devices may share the same sdcard. The second is
that it is impossible for the other device to install a program into
YOUR device -- you must explicitly authorize it. Which means that if
you run the key logger program, then the web sender program can only
be run from the OTHER device unless you actually *do* give it
permission.

The next realization is that BOTH programs must be signed by the same
key, which means they must be published by the same developer.
Naturally, this doesn't stop someone from making manual changes to the
configurations for THEIR device (i.e. manually change the user ID for
a program), however, the security issue here comes from the fact that
the(any) other DEVICE can read YOUR DATA, and this risk has nothing to
do with user IDs.

I think that ultimately, when dealing with sharing between multiple
devices, we may want to implement a per-device USERDATA encryption --
make it optional upon creation, i.e., ask the user if they want to
encrypt userdata, however, this would actually make for SUPERIOR
security compared to the existing model (not that I have anything
against that)... i.e., when in the sdcard setup menu, there is the
button that says "setup sdcard to allow applications to be installed
to sdcard" -- It asks for initial size to devote to apps, and it asks
"would you like to encrypt your application user data? Encrypting data
will have a minimal impact on performance but ensures that your data
is protected in case your sdcard is misplaced. Yes, No."

But since right now this is about getting a minimum-working-system-
that-isn't-an-ugly-hack, i.e., single device, single card, lets just
write this down for deeper consideration when we actually get to that
stage... ;)

On Oct 28, 3:00 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> It could be considered a security impact if an app is refused by the
> user (eg tampering or unwanted) and the associated data is accessible
> to a different shared uid app. (EG "No, I don't want to run
> JohnsKeyLoggerKeyboard" but oops, the logging it did last time is
> already available to "JimsInnocentLookingWebSender". If the user
> refuses permission, it should behave as if it was not installed - no
> app or data access.)
>

Disconnect

unread,
Oct 28, 2009, 4:27:54 PM10/28/09
to android-...@googlegroups.com
I think the loopback method has another major problem -
expanding/shrinking is effectively impossible. (And convincing a user
of this is going to be difficult. Even worse is "I only have 1 app
installed! Why can't I copy it to a smaller sd card?")

Per-file encryption allows for dynamic (and automatic) grow/shrink.
(I'm not sure if encfs supports layering unix access controls on
non-unix filesystems, but that is a clear requirement. Its even in the
doc ;) ..)

I think there is another usecase that applies to the shared-uid issue
but I'll have to think about it to flesh it out better.

lbcoder

unread,
Oct 28, 2009, 4:48:58 PM10/28/09
to android-platform
Actually, expanding and shrinking is trivial.

Expand:
truncate /sdcard/.extapps newsizeM
resize2fs /sdcard/.extapps

Shrink:
resize2fs /sdcard/.extapps newsizeM
truncate /sdcard/.extapps newsizeM

Done.
Note: though 'truncate' makes you think small, it will actually grow a
file by appending 0's.
Note2: for expanding, in order to *feel* safe (even though it makes no
difference), you can replace 'truncate' with 'dd if=/dev/zero
count=amount_to_grow_by_in_blocks | cat >> /sdcard/.extapps'
Note3: do we really want to enable shrinking? a shrink can take a long
time, and if it goes wrong, the data can all be lost.
Note4: expanding is really fast and virtually zero chance of data
loss.

Re: "I only have 1 app... etc." -- if we enable shrinking, they CAN.
Shrink the filesystem so that it fits on the new smaller sdcard, copy
it onto their computer, copy it to the smaller sdcard.

On Oct 28, 4:27 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> I think the loopback method has another major problem -
> expanding/shrinking is effectively impossible. (And convincing a user
> of this is going to be difficult. Even worse is "I only have 1 app
> installed! Why can't I copy it to a smaller sd card?")
>
> Per-file encryption allows for dynamic (and automatic) grow/shrink.
> (I'm not sure if encfs supports layering unix access controls on
> non-unix filesystems, but that is a clear requirement. Its even in the
> doc ;) ..)
>
> I think there is another usecase that applies to the shared-uid issue
> but I'll have to think about it to flesh it out better.
>

Disconnect

unread,
Oct 28, 2009, 4:53:19 PM10/28/09
to android-...@googlegroups.com
Note3. :)

Eric F

unread,
Oct 28, 2009, 4:59:24 PM10/28/09
to android-platform
Is it really impossible to expand or resize? Shrinking is usually
tough, but expansion should not be impossible. Or am I missing
something ( I come from a VM, lvm background where I do a lot of
resize2fs etc )? To me it seems like a good simplification to do the
one file, filesystem approach. It adds a lot of simplifications to the
design. Remember there will be file name restriction differences so a
per-file approach will have to maintain some kind of DB translating
file names.

I also don't think that hiding the Android files on the SD card from
windows file readers is a good idea. I have an 8GB SD card I haven't
used in a while. I only see 4GB available WTH? Format it.. Only the
next day to realize, oh crap, that had all my apps on it.

I think it should be more like

/AndroidInstalledApps/PhoneNameOrID (or if multiple files are used, a
directory instead of an FS image)

So it's clear to the user that there IS something on the card and it
is for Android.

-E

lbcoder

unread,
Oct 28, 2009, 5:01:47 PM10/28/09
to android-platform
Well, if you're worried about that, then its just a question of being
clear about it from the start. When you go to ask the initial size to
devote to apps, you say "you can make it bigger any time you want, but
you can't make it smaller without deleting all the apps and associated
data from the sdcard and starting over fresh, recommended starting
size is 50MiB".

Oh, and we call it "reserved" space. That way it is clear that this
full amount of space is removed from the available total rather than
just being a set limit.

On Oct 28, 4:53 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> Note3. :)
>

lbcoder

unread,
Oct 28, 2009, 5:09:47 PM10/28/09