Security design for running apps off the SD Card
Mike Hearn
filesystem on the SD card. Can somebody explain to me why it's
insufficient to enforce permissions using some kind of pattern
matching rules inside the kernel, eg, rules like:
All files except those under /Applications are permission free.
/Applications may only have directories in it.
Each directory under /Applications contains a secure application
identifier (certificate?).
Reads/writes to these directories are denied unless the process is
associated with that ID.
Associating a process (or rather, internal uid/gid) with that cert is
a privileged operation.
Or is the concern that people may take the SD Card, plug it into a
desktop and then some other app interferes with the permissions.
I am not sure why cryptography is necessary here, if the kernel would
enforce Android-level security on open().
Disconnect
But basically, android has several security guarantees. Many of them relate to applications inside the device not interfering/harming each other, etc. But they also make a data privacy/integrity guarantee and you can't enforce that unless you-and-only-you can read/write the data.
The whole doc is at http://code.google.com/android/devel/security.html
Jean-Baptiste Queru
without going through the kernel (by pulling the SD card and inserting
it into a card reader. In fact even connecting the device to a
computer over USB would have the same problem.
JBQ
--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.
Dianne Hackborn
Dianne Hackborn
Android framework engineer
hac...@android.com
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
Al Sutton
running apps from the SD card.
I'm guessing that the cryptofs will be tied to the key of either the
user or the device itself, both of which are not ideal for the following
reason;
Tied to user : In environments where 'phones can be shared (e.g.
corporate environments), and the users have individual phone logins
(yes, I am thinking in the future), any corporate app distributed on SD
card would need to have multiple copies of the app each one on an
encrypted fs with a specific users credentials.
Tied to device : If the users phone breaks and they buy another 'phone
or get a replacement they will then be unable to use the apps they have
on their SD.
I would suggest that the SD cards fs is left as an open filesystem and a
more intelligent method is made available to the apps. Plenty of methods
are already employed in the PC world and I've been able to write a
license key system without too much trouble on Android which can lock an
app to a device or phone number, or user without any problems or
requirements for a crypto fs.
Al.
Mark Murphy
> Tied to user : In environments where 'phones can be shared (e.g.
> corporate environments), and the users have individual phone logins
> (yes, I am thinking in the future), any corporate app distributed on SD
> card would need to have multiple copies of the app each one on an
> encrypted fs with a specific users credentials.
I think you're assuming that apps can be distributed as pre-installed on
an SD card, such that the phone can magically use them without going
through package management or other forms of installation. I don't think
that is a safe assumption. In fact, that would scare the crap out of me,
because that introduces some disturbing security issues for ordinary
people (e.g., when do I get to approve permissions?).
If the apps have to be installed anyway, they'll get whatever signatures
they need as part of the installation process.
Rather than viewing SD cards as the distribution mechanism, I'd focus
instead on making an awesome bulk-installer/device imager for use in
corporate environments. Such an app would allow corporate IT to load a
bunch of apps with minimal interaction, loading some profile to
determine what should get installed.
Not only does that de-couple the issue of corporate rollouts from the
apps-on-SD implementation details, and not only does it allow the
Android security system to work normally for non-corporate users, but it
also handles the case where SD cards aren't even in the picture (e.g.,
devices with 8GB flash) and could be extended to handle other settings
not related to application installation (e.g., email app configuration,
proxy server configuration).
Heck, a device imager app would probably be fairly lucrative for
somebody with access to firmware engineering talent to help make patches
to Android to support such a thing.
--
Mark Murphy (a Commons Guy)
http://commonsware.com
Android Training on the Ranch! -- Mar 16-20, 2009
http://www.bignerdranch.com/schedule.shtml
Disconnect
So I can pull out all the funky socket-opening stuff without breaking the security model? (Or, better, just boot an upstream kernel.)
Al Sutton
Games Consoles, GPS Units, even some PC software (how many times do you
think the average user has inserted an autostart CD/DVD into their PC?).
I can see the need for a default permission set, I can see the need for
code to get the permission requirements from an SD card app and ask the
user to approve them, and we all know there is major work to be done
before any app will run off an SD card, but imho it's better that the
work was done considering Load-and-Go as opposed to ending up with a
solution which prohibits it for no other reason than the way it was
designed.
If corporations are given the choice of;
a) A techie having to setup and run a bulk loader for each new device
the company wants to use.
or
b) Unboxing the device and plugging in an SD card which has been created
from an "standard" image file.
I can see companies going with b every time for time and cost reasons.
Load and Go is good, Load and Go can be your friend, users like Load and
Go, and Android shouldn't get in the way of what users like just because
we don't want to put the effort into making it work ;).
Al.
--
======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.
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.
BubbaG
On Dec 20, 12:54 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> You mean like the current security patches? (ahem*reinvented-selinux*ahem)
>
> So I can pull out all the funky socket-opening stuff without breaking the
> security model? (Or, better, just boot an upstream kernel.)
>
>
> > We are also simply not going to require special patches of the kernel to
> > implement very specialized behavior, especially special patches without
> > which the entire security model would break down.
>
> > On Sat, Dec 20, 2008 at 8:08 AM, Jean-Baptiste Queru <j...@google.com>wrote:
>
> >> The concern is indeed the fact that the SD card can also be read
> >> without going through the kernel (by pulling the SD card and inserting
> >> it into a card reader. In fact even connecting the device to a
> >> computer over USB would have the same problem.
>
> >> JBQ
>
>
> >> > I read that the currently considered solution is to place an encrypted
> >> > filesystem on the SD card. Can somebody explain to me why it's
> >> > insufficient to enforce permissions using some kind of pattern
> >> > matching rules inside the kernel, eg, rules like:
>
> >> > All files except those under /Applications are permission free.
> >> > /Applications may only have directories in it.
> >> > Each directory under /Applications contains a secure application
> >> > identifier (certificate?).
> >> > Reads/writes to these directories are denied unless the process is
> >> > associated with that ID.
> >> > Associating a process (or rather, internal uid/gid) with that cert is
> >> > a privileged operation.
>
> >> > Or is the concern that people may take the SD Card, plug it into a
> >> > desktop and then some other app interferes with the permissions.
>
> >> > I am not sure why cryptography is necessary here, if the kernel would
> >> > enforce Android-level security on open().
>
> >> --
> >> Jean-Baptiste M. "JBQ" Queru
> >> Android Engineer, Google.
>
> > --
> > Dianne Hackborn
> > Android framework engineer
> > Note: please don't send private questions to me, as I don't have time to
> > provide private support. All such questions should be posted on public
> > forums, where I and others can see and answer them.
Symbian and WM OS's as examples. You can install apps to the card,
but they do not function accept on the device installed. App
initialization is on the device installed to, so if you try using the
card with that installed app in another device, it will not operate or
even be recognized. It seems that the approach articulated in the
forums here appeasr more complex than the install option requires.
There should be no 100% card installs. "98%" of the app should be
installed to the card and the initialization files on the device.
JM"Very"HO.
That being said, I support the fact that "Nothing is as simple as it
sounds". You have created a very user friendly SDK. Consequently,
the more "easy" the SDK, the more "complex" the environment around
it. Even programming deals with laws of displacement.
tarek nemo
Pls pls aandroid stop sending me msgs plsss
On 20 Dec 2008, 4:09 PM, "Jean-Baptiste Queru" <j...@google.com> wrote:
The concern is indeed the fact that the SD card can also be read
without going through the kernel (by pulling the SD card and inserting
it into a card reader. In fact even connecting the device to a
computer over USB would have the same problem.
JBQ
On Sat, Dec 20, 2008 at 7:02 AM, Mike Hearn <mh.in....@gmail.com> wrote: > > I read that the cu...
Michael
lists you don't want to be on. There's nothing to be gained from
asking us to do this for you - we can't.
Mike Hearn
> without going through the kernel (by pulling the SD card and inserting
> it into a card reader. In fact even connecting the device to a
> computer over USB would have the same problem.
anywhere? The security document here:
http://code.google.com/android/devel/security.html
makes no mention of moving the SD card to an external device being a
problem. I don't actually understand why this needs to be guarded
against - what is the threat here? Even if you assume there's some
piece of malware on the PC the worst it can do is steal a commercial
app, but making apps uncopyable is a separate problem.
Diane says that specialised pattern matching in the kernel is not
acceptable for Android - OK, fine, but is there a list of what is and
isn't acceptable to change in the imported codebases? I imagined the
kernel could be modified without restriction but apparently not.
Here is an alternative plan that involves less magic inside the
kernel.
When an SD card is first mounted, it's mounted as
uid=root,gid=root,umask=077 which (I think) means it's only read/
write by root and nobody else. Then the kernel FAT driver is changed
such that permission changes are stored in memory rather than
rejected. A userspace process can then examine the structure of the
filesystem, do signature checks and whatever else is needed before
modifying the permissions of a directory tree to be what it'd have
been on the internal storage (eg owned by the app user).
The only change necessary then, is a small new (generic!) feature in
the FAT driver. If gated by a mount option it might even be accepted
upstream. I imagine the patch would be only a few hundred lines of
code.
Mike Hearn
there's already code in cupcake to do encryption so it looks like this
design was finalized already. Is there a design doc anywhere? There's
a lot of discussion on this list from people who weren't involved in
these design discussions, and it'd save everyone a lot of time if
there was a description of why the system is being designed the way it
is.
Joe Onorato
A bigger concern is that apps can write to the whole sd card. That would mean that one app could rewrite another app's binary, which is about the biggest inter-app security problem you can construct. With the app stored in an encrypted partition, it becomes impossible for an app to rewrite another app in a way predictable enough for it to exploit it. It could presumably get it to crash, but that may be acceptable. Simply signing the app and putting it on the sdcard isn't enough. There isn't enough memory or internal storage to reliably copy it wholesale to a secure place before its signature is verified. Verifying the signature is also slow enough that you don't want to do it more than once, ideally at install time.
By the way, this has nothing to do with an autorun style thing. We could easily allow an apk to be installed at a known location and install and run it. But I don't think that's a very good idea. At a minimum I'd want something that the user had to do. If windows didn't have this feature, then the malware that comes on audio cds wouldn't be possible. I'd be willing to think about it if there was some interaction, like "You put in an SD card with these apps on it, would you like to install them?"
As for custom kernel changes, we're already maintaining more kernel patches that are unlikely to be accepted from upstream than we'd like. It'd be better to keep those as distinct as possible, rather than dealing with constant integration hassles of trying to keep a custom FAT file system up to date.
-joe
Al Sutton
- Given that I go hook my G1 up to my PC, do "adb pull
/system/app/Browser.apk BrowserBackup.apk" and get the Browser that's
installed as part of the firmware, I think trying to protect apks from
being read is already a lost battle.
- I don't see the need to copy the apk to a secure location before the
signature check. One of the points of signatures is that they allow you
to verify data thats arrived via an insecure transport medium.
- With signatures, they only need to be checked if the SD card is
changed. The signature could be verified on the first run of an apk and
it's then considered trusted until the SD is ejected. We could go
further an have a history of a few SDs and the trusted apps on them, but
that's another conversation.
- You've missing a use case with the SD app issue. Autorun should be an
option that the user controls, but there is also the use case of apps
that are installed to an SD and then when the SD is inserted into a
different device the apps are ready for the user to start. (think some
type of database on the SD which is used to populate the apps menu when
the SD is inserted, and those apps are removed from the menu when the SD
is ejected).
- UMSDOS has fallen by the wayside, offers a permission system that
would fit into the Android model, and would accommodate pretty much
everything I can think of that we need. I'm sure a UMSDOS maintainer
would be welcomed upstream as some distros attracted some of their users
because they include it.
Al.
Disconnect
#2 - if you don't, you are subject to a very simple attack: wait for you to verify the sig, then change the data underneath you.
#3 - "changed" or "touched by a different app" or "touched by the PC" or "rebooted" .. etc.
#4 - that is 2 use cases. autorun handles things like "this is an installer sd" and "this is a movie". app on sd solves "i want this app to run on an sd card".
#5 - feel free to volunteer. it doesn't solve the data integrity/security requirement, so its not useful here, but feel free to volunteer. I'm sure someone out there misses umsdos and would love to see it resurrected.
One other note that is worth considering - this needs to work with the existing API and existing apps. all existing apps, regardless of strange-but-sdk-legal requirements..
Joe Onorato
A few quick points;
- Given that I go hook my G1 up to my PC, do "adb pull /system/app/Browser.apk BrowserBackup.apk" and get the Browser that's installed as part of the firmware, I think trying to protect apks from being read is already a lost battle.
I'm not really worried about that either.
- I don't see the need to copy the apk to a secure location before the signature check. One of the points of signatures is that they allow you to verify data thats arrived via an insecure transport medium.
- With signatures, they only need to be checked if the SD card is changed. The signature could be verified on the first run of an apk and it's then considered trusted until the SD is ejected. We could go further an have a history of a few SDs and the trusted apps on them, but that's another conversation.
The problem is that the SD card is read-write for all apps on the device, so if it were to be run directly from an insecure file system, once the signature is checked, the malicious app could change it out from under the system.
- You've missing a use case with the SD app issue. Autorun should be an option that the user controls, but there is also the use case of apps that are installed to an SD and then when the SD is inserted into a different device the apps are ready for the user to start. (think some type of database on the SD which is used to populate the apps menu when the SD is inserted, and those apps are removed from the menu when the SD is ejected).
One way or another, an app needs to be installed on android before it can be run. Among other things, its permission requests need to be checked and its list of intents needs to be loaded.
- UMSDOS has fallen by the wayside, offers a permission system that would fit into the Android model, and would accommodate pretty much everything I can think of that we need. I'm sure a UMSDOS maintainer would be welcomed upstream as some distros attracted some of their users because they include it.
I don't know anything about UMSDOS. It sounds like a decent idea, but the fact that it's been abandoned isn't promising. I'm not saying it's a bad idea, I just don't have any experience, although I'm unlikely to be the person implementing the filesystem part of apps-on-sd-cards anyway.
-joe
Al Sutton
preferential treatment?, All the apps downloaded via the browser are in
/sdcard/download
#2 - That's why we need file system permissions (a la UMSDOS), then apps
can change other apps once the SD is inserted without breaking the
Android security model.
#3 - Are you listing the cases for reverification of the signature?, I
agree it could be more intelligent than my initial description.
#4 - Joe had mentioned autorun but not the non-autorun, hence the one
missed case.
#5 - See #2.
> <mailto:mh.in....@gmail.com
Al Sutton
> On Tue, Dec 23, 2008 at 2:52 PM, Al Sutton <a...@funkyandroid.com
> <mailto:a...@funkyandroid.com>> wrote:
>
> - I don't see the need to copy the apk to a secure location before
> the signature check. One of the points of signatures is that they
> allow you to verify data thats arrived via an insecure transport
> medium.
>
> - With signatures, they only need to be checked if the SD card is
> changed. The signature could be verified on the first run of an
> apk and it's then considered trusted until the SD is ejected. We
> could go further an have a history of a few SDs and the trusted
> apps on them, but that's another conversation.
>
>
> The problem is that the SD card is read-write for all apps on the
> device, so if it were to be run directly from an insecure file system,
> once the signature is checked, the malicious app could change it out
> from under the system.
>
>
>
> - You've missing a use case with the SD app issue. Autorun should
> be an option that the user controls, but there is also the use
> case of apps that are installed to an SD and then when the SD is
> inserted into a different device the apps are ready for the user
> to start. (think some type of database on the SD which is used to
> populate the apps menu when the SD is inserted, and those apps are
> removed from the menu when the SD is ejected).
>
>
> One way or another, an app needs to be installed on android before it
> can be run. Among other things, its permission requests need to be
> checked and its list of intents needs to be loaded.
>
When you say "an app needs to be installed before it can be run", that's
part of my point. The need is only because of the design of the OS and
to me it's adding artificial barriers.
An alternative would, for example, be permission requests on first
usage. That way you can be sure that an app actually needs the
permission for the usage dynamic you put on it, and users don't get a
huge list of permissions which may or may not be used.
(I know that's a non-current way of doing it, but we're here to discuss
improvements :)).
>
> - UMSDOS has fallen by the wayside, offers a permission system
> that would fit into the Android model, and would accommodate
> pretty much everything I can think of that we need. I'm sure a
> UMSDOS maintainer would be welcomed upstream as some distros
> attracted some of their users because they include it.
>
>
> I don't know anything about UMSDOS. It sounds like a decent idea, but
> the fact that it's been abandoned isn't promising. I'm not saying
> it's a bad idea, I just don't have any experience, although I'm
> unlikely to be the person implementing the filesystem part of
> apps-on-sd-cards anyway.
>
> -joe
>
It was initially the way to do "trial" installs of Linux without
blasting away your M$ OS. It fell by the way side largely because of
LiveCDs and large hard disks, but if it fits our needs then it's
probably a good idea to recycle the code :).
Al.
>
>
>
>
>
> Al.
Disconnect
#2 - that still does nothing for the case where the sd card is removed. until you explain how the data is protected, its a non-starter. repeating yourself won't make it any more viable.
#3 - there are a lot of cases where you need to recheck. and with large cards.. "you rebooted your phone. please wait 15 minutes while I recheck 100 applications and prompt you for permissions"
#5 - again. its not useful here, but feel free to volunteer to those dists that want a maintainer for it.
Dan Bornstein
> An alternative would, for example, be permission requests on first usage.
> That way you can be sure that an app actually needs the permission for the
> usage dynamic you put on it, and users don't get a huge list of permissions
> which may or may not be used.
FWIW, I[*] think that would be a huge step backwards: The
tried-and-true default behavior for users — even sophisticated ones —
is to blindly click the "allow" button on such permission request
dialogs. Colloquially, you might as well think of the request dialog
as asking no more than "Would you like the program to function? YES /
NO" and of course everybody nearly always says "YES" without actually
reading what the dialog really says, rendering the whole interaction a
moot waste of time.
With the up-front install-time manifest, we have at least a reasonable
stand where (a) sophisticated users can make an informed decision, and
(b) unsophisticated users can still make a decent decision based on
the wisdom of the crowds that include sophisticated users, e.g. today,
star ratings and comments in the markets. (Yes yes things could stand
to be improved on the market front.)
-dan
[*] and I am pretty sure the rest of the Android team who have an
opinion about this at all
Al Sutton
----- Original message -----
> #1 - Apps downloaded by other installers can be stored where those
> installers choose. Part of what marketplace offers is a way to ensure an app
> is only installed once - I suspect others (slideme) would like to do the
> same. That involves not saving it where anyone can read it.
>
The browser is a system supplied installer. Developers do host apks as part of their site.
> #2 - that still does nothing for the case where the sd card is removed.
> until you explain how the data is protected, its a non-starter. repeating
> yourself won't make it any more viable.
>
I'm making the case for allowing unprotected data. The UMSDOS permissions block apps modifying each other inside an Android environment, and for many apps it may make sense to allow data to be modified on another machine.
For data that the app wants to protect a crypto fs could be provided in addition to allowing free data, what I'm against is not allowing unlocked data and apps.
> #3 - there are a lot of cases where you need to recheck. and with large
> cards.. "you rebooted your phone. please wait 15 minutes while I recheck 100
> applications and prompt you for permissions"
>
Once the card is in the device its in a controlled environmnet, so we can verify apps on first usage (not upon insertion).
> #5 - again. its not useful here, but feel free to volunteer to those dists
> that want a maintainer for it.
>
Again I see things differently.
Mike Hearn
>
> A bigger concern is that apps can write to the whole sd card. That would
> mean that one app could rewrite another app's binary, which is about the
> biggest inter-app security problem you can construct.
mounting initially as root and then modifying the (in memory)
permissions after signature verification is so apps *cannot* read or
modify other apps - the standard kernel permissions prevent them, same
as with internal storage.
> With the app stored
> in an encrypted partition, it becomes impossible for an app to rewrite
> another app in a way predictable enough for it to exploit it. It could
> presumably get it to crash, but that may be acceptable.
another apps bytes, even if they are encrypted ... the kernel can
already enforce this if only it's told what to do. Decrypting apps on
the fly is going to be quite the power-suck, just to work around a
(simple) missing feature in the kernel.
> As for custom kernel changes, we're already maintaining more kernel patches
> that are unlikely to be accepted from upstream than we'd like. It'd be
> better to keep those as distinct as possible, rather than dealing with
> constant integration hassles of trying to keep a custom FAT file system up
> to date.
needs to do is have an in-memory table of what directories have had
their permissions modified, and then use the regular kernel machinery
to enforce those permissions until the FS is unmounted. This is not an
on-disk format change.
dc.dis...@gmail.com
and modification. How does your hack solve that?
Al Sutton
If a user has warning dialog blindness (WDB) then they click an OK box
at install, runtime, or pretty much whenever.
To me the current system is pretty crude because it's a one shot
all-or-nothing ahead-of-time decision so a user has to decide whether or
not to allow permissions before they've personally experienced how the
app uses them and they can only say yes to everything or not install the
app at all, they can't selectively pick permissions.
A permission checks on use framework not only allows users to make
decisions within the context of how the app uses the permission, and as
a further enhancement it should allow granualar permission grants (e.g.
Yes to internet acces, No to vibrating the 'phone).
As an example of the difference; Imagine a notepad application which
wants the ability to vibrate the phone as part of it's feature set. At
the moment the user has to say Yes to all the permission just to try it
out, then they discover the developer wrote the code so the 'phone
vibrates every time a key is pressed and there is nothing they can do
about it except uninstall the app even if it's the best notepad
application the world has seen.
With check on use & a granular system the user could install the app,
run it, when the press a key the 'phone asks for vibrate permission,
they can say "Yes", "No", or "Just this time", and have the option to
still use the app even though the app nomatter what they chose. If they
select Yes they should be able to change their mind in the application
manager (which would be enhanced to allow granual permission control),
and if they say "Just this time" they'll soon get the message when the
permission request dialogue pops up every time they press a key, if they
select No the app can still be used but without the annoying feature.
I hope this helps you understand where I'm coming from.
Al.
Al Sutton
1) Use the Astro file manager from Market to "back up" the apk to an sd
card.
2) Copy the apk into /sdcard/dcim and change the apk extension to jpg
3) Use the Mail or Gmail app to email the app to yourself (now it ends
.jpg the Mail or GMail apps will think it's just a corrupted picture).
4) Wait for it to arrive.
"Reading an apk downloaded from the marketplace.... Done" (as Gordon
Ramsey would say).
P.S. If you want to avoid waiting for the mail to go round the SMTP
servers and back to yourself use K9 and an Imap account you can save the
email with the attachment as a draft and pick it up from your Imap
drafts box.
Al Sutton
want the correction. It will only be provided to Disconnect or anyone
@android.com.
Al.
Al Sutton
exported to a PC and read and modified, short answer is it's not.
I would suggest the focus of work shifts to an apk trust mechanism
(something I suggested a few months ago at
http://alsutton.wordpress.com/2008/09/17/google-android-and-code-signing-app-shops/)
and away from trying to create a completely secure storage solution
which leaves free apps in a straight jacket.
I've emailed the -developers list to see what developers think because,
after all, they're the ones who are going to be stuck with what ever is
the end product.
Al.
Al Sutton
exported to a PC and read and modified, short answer is it's not.
I would suggest the focus of work shifts to an apk trust mechanism
(something I suggested a few months ago at
http://alsutton.wordpress.com/2008/09/17/google-android-and-code-signing-app-shops/)
and away from trying to create a completely secure storage solution
which leaves free apps in a straight jacket.
I've emailed the -developers list to see what developers think because,
after all, they're the ones who are going to be stuck with what ever is
the end product.
Al.
Disconnect
Actual modifications to the INTENT of the security policy must wait for the next rev of the platform - its not something that can be thrown away in 1.x because its inconvenient. And "well, wait, maybe we shouldn't protect apps or data" is a serious modification to the intent (and in fact invalidates a good solid chunk of the document, implementation flaws aside.) No matter how much complaining and handwaving is done, the security policy is already set.
If you have an app that needs to share data, or even use completely unprotected data, there is ALREADY a way to do that. Please explain the "straight jacket" involved in using /sdcard/{save your files here}. I think at this pioint you are just objecting out of habit, as you have not posted any new information in a while. If that is true, please reconsider.
Here is where we are now, and where we need to remain:
- apps can have unsecure storage, either using permissions flags on files in /data/data/app.com/ or by simply using /sdcard.
- apps can have secure storage, by not using permission flags (accepting defaults) in /data/data/app.com/
- apps can not be modified by external entities (inside or outside the phone) after the signature has been verified and the app installed
- apps requiring permissions must have those permissions approved by the user at install time
Any method to allow the sd card (or any other storage medium) to host applications must maintain those same basic guarantees. You are declaring that you don't like them, so therefor they are invalid - that would have been something to debate back when the 1.0 spec was being drafted, but right now it is fixed in stone.
Al Sutton
> Again, given the security policy, that is more likely an oversight
> than an intentional gap. Esp since you can't view the directory
> holding the installed apks. (I'm not sure why the files are
> world-readable, instead of properly owned, but..)
>
protected isn't true.
> Actual modifications to the INTENT of the security policy must wait
> for the next rev of the platform - its not something that can be
> thrown away in 1.x because its inconvenient. And "well, wait, maybe
> we shouldn't protect apps or data" is a serious modification to the
> intent (and in fact invalidates a good solid chunk of the document,
> implementation flaws aside.) No matter how much complaining and
> handwaving is done, the security policy is already set.
>
Not if additions are made to APIs. For example adding a
android:secureInstallOnly entry to the manifest which defaults to true.
If it's false the apk and data can be written to the normal FS in a
"portable" manner which allows insert-and-run behaviour as opposed to
insert-and-install on every device.
Similarly additional flags or options could be added where there is a
decision to make between secure and insecure storage whereby the default
behaviour is the same as the current, but the flag allows non-secured
behaviour.
I'm not suggesting throwing anything away, just making sure that things
we add have flexibility.
> If you have an app that needs to share data, or even use completely
> unprotected data, there is ALREADY a way to do that. Please explain
> the "straight jacket" involved in using /sdcard/{save your files
> here}. I think at this pioint you are just objecting out of habit, as
> you have not posted any new information in a while. If that is true,
> please reconsider.
>
As I said in the email, that straight jacket point relates to
applications, not data. The current plan for an encrypted filesystem on
SDs which is the only place APKs can be installed to for run-from-SD
functionality is the straight jacket. It prevents APKs being moved
freely between android devices without the need for a re-install on each
new device.
I'm also suggesting that we look at ways to indicate who trusts an APK
so the user can make an informed choice rather than locking every APK
down so it can't be moved between devices easily. Applying the web of
trust concept to APKs (as I've proposed) win/win situation. Developers
get a mechanism by which they can distribute their apps with test
certifications included in the APK, App distributors get to sign copies
they've distributed so they can build their brand on the quality of the
apps they distribute, and users get an idea of who else trusts an
applications behaviour whereas at the moment there is not mechanism to
do this (the Marketplace rating system is suffering heavy abuse at the
moment so it's not a reliable marker).
> Here is where we are now, and where we need to remain:
> - apps can have unsecure storage, either using permissions flags on
> files in /data/data/app.com/ <http://app.com/> or by simply using
> /sdcard.
> - apps can have secure storage, by not using permission flags
> (accepting defaults) in /data/data/app.com/ <http://app.com/>
> - apps can not be modified by external entities (inside or outside
> the phone) after the signature has been verified and the app installed
> - apps requiring permissions must have those permissions approved by
> the user at install time
>
This is all true for internally installed apps. What we're talking about
here is apps installed on external storage which is a slightly different
problem domain due to the fact the storage medium is removable and
designed to be transportable.
What I'm suggesting is to add the following (as #5);
- apps can indicate that they wish to be stored in a "portable" manner
which allows the storage medium to moved between devices without the
need for a re-install.
And add to #4 where the following wording can be added;
"except for apps which have indicated they wish to be deployed in a
portable format, in this case the permissions are approved by the user
upon first execution after insertion of the portable storage device".
As has been previously done, there is a lot of work do be done to get
run-from-SD working, so I'm trying to put these forward before we end up
with a solution which gets deployed and makes portable apps impossible.
> Any method to allow the sd card (or any other storage medium) to host
> applications must maintain those same basic guarantees. You are
> declaring that you don't like them, so therefor they are invalid -
> that would have been something to debate back when the 1.0 spec was
> being drafted, but right now it is fixed in stone.
>
That's just a complete misrepresentation of what I've said.
I'm trying to make sure portably installed apps are a posibility, not
trying to force all apps to be installed in a portable manner. I'm not
suggesting any of those are just thrown out, what I'm suggesting are
modifications for the (as yet unwritten) run-from SD scenario.
Al.
>
> On Wed, Dec 24, 2008 at 3:37 AM, Al Sutton <a...@funkyandroid.com
> <mailto:a...@funkyandroid.com>> wrote:
>
>
> In the same way that any apk is currently protected against being
> exported to a PC and read and modified, short answer is it's not.
>
> I would suggest the focus of work shifts to an apk trust mechanism
> (something I suggested a few months ago at
> http://alsutton.wordpress.com/2008/09/17/google-android-and-code-signing-app-shops/)
> and away from trying to create a completely secure storage
> solution which leaves free apps in a straight jacket.
>
> I've emailed the -developers list to see what developers think
> because, after all, they're the ones who are going to be stuck
> with what ever is the end product.
>
> Al.
>
>
> dc.dis...@gmail.com <mailto:dc.dis...@gmail.com> wrote:
>
> And when the card is in a pc? It needs to be secure against
> reading
> and modification. How does your hack solve that?
>
> On 12/23/08, Mike Hearn <mh.in....@gmail.com
Dianne Hackborn
The purpose of using an encrypted filesystem for external storage (esp on a FAT filesystem) is so that "installed" .apks can not be modified from outside of the operating system's control. Anything that allows such modifications to happen is a no-go from the very start because it fundamentally breaks large swaths of the security in the system.
Anyway, there was already a long discussion on this where I posted our expected approach for dealing with installing .apks on the sd card, which is baed on creating an encrypted filesystem. This is still the expected plan.
Dianne Hackborn
Android framework engineer
Al Sutton
> There is nothing in the security model design, implementation, or
> intention to prevent anyone from being able to read, or copy a .apk.
> I don't know why you posted those convoluted steps previously to copy
> a .apk -- just use adb pull to retrieve one, or someone can write a
> regular android app that reads and send a .apk to wherever it wants
> without any special permission.
>
that happened (specifically mine dated Dec 23rd 7:52 and Disconnects
response).
> The purpose of using an encrypted filesystem for external storage (esp
> on a FAT filesystem) is so that "installed" .apks can not be modified
> from outside of the operating system's control. Anything that allows
> such modifications to happen is a no-go from the very start because it
> fundamentally breaks large swaths of the security in the system.
>
Please read the earlier messages in this thread as to the reason why I'm
suggesting it's a bad idea (specifically mine date Dec 20th 5:16)
> Anyway, there was already a long discussion on this where I posted our
> expected approach for dealing with installing .apks on the sd card,
> which is baed on creating an encrypted filesystem. This is still the
> expected plan.
>
Please read the earlier messages in this thread as to the reason why I
believe that it's approached designed to make the developers lives
easier at the expense of making the OS easier for users (specifically
mine date Dec 20th, 8:30)
Regards,
Al.
> <mailto:a...@funkyandroid.com <mailto:a...@funkyandroid.com>>> wrote:
>
>
> In the same way that any apk is currently protected against
> being
> exported to a PC and read and modified, short answer is
> it's not.
>
> I would suggest the focus of work shifts to an apk trust
> mechanism
> (something I suggested a few months ago at
>
> http://alsutton.wordpress.com/2008/09/17/google-android-and-code-signing-app-shops/)
> and away from trying to create a completely secure storage
> solution which leaves free apps in a straight jacket.
>
> I've emailed the -developers list to see what developers think
> because, after all, they're the ones who are going to be stuck
> with what ever is the end product.
>
> Al.
>
>
> dc.dis...@gmail.com <mailto:dc.dis...@gmail.com>
> <mailto:dc.dis...@gmail.com
> <mailto:dc.dis...@gmail.com>> wrote:
>
> And when the card is in a pc? It needs to be secure against
> reading
> and modification. How does your hack solve that?
>
> On 12/23/08, Mike Hearn <mh.in....@gmail.com
> <mailto:mh.in....@gmail.com>
> <mailto:mh.in....@gmail.com
> hac...@android.com <mailto:hac...@android.com>
>
> Note: please don't send private questions to me, as I don't have time
> to provide private support. All such questions should be posted on
> public forums, where I and others can see and answer them.
>
Peli
discussion:
It is actually the direction we try to follow at OpenIntents:
Have as few permissions necessary as possible in the core application,
and let the user extend capabilities through "extensions" with
additional permissions.
For your Notepad example that would mean that the core Notepad
application would not require any permission at all, but the user
could download the "vibrate on key press (TM)" extension which only
needs the vibrate permission and would interact with Notepad.
Similarly, if they wanted to be informed about updates, they download
the Update application which requires the Internet permission, or the
sync application to sync notes with a server which would also require
the internet permission.
Again, getting closer to the original cause of this thread:
Splitting an application into small components that can be installed
separately also means that a user only needs to download those
components that they really need - saving valuable space on internal
memory :-)
(I guess SD card apps would lead to huge, monolithic, require-all-
permissions apps...)
Peli
www.openintents.org
Mike Hearn
Anyway, I'm not sure that super-modular approach is a good idea for
two reasons:
1) It requires users to do manual dependency resolution and management
currently. Experience from Linux indicates that a lot of users find
this hard/irritating. Let's not establish a precedent here, that would
suck. Death to manual dependency management!
2) Badly written extensions might accidentally allow themselves to be
controlled by an activity != the one they were meant for. That'd
result in a circumvention of the security system.
It's probably better, for now, to just require all the permissions
your app needs for the full feature set. I have argued with Diane and
JBQ about just-in-time permissions before :) and their viewpoint was,
reasonably, that it worked pretty badly for J2ME.
Even so I think it could be made to work better, and, it'll be
necessary as apps get more complicated. Otherwise we'll either end up
with weird componentization hacks like this one, or users will get
trained to ignore the permissions warnings because they are always so
numerous (I am sceptical most users pay attention already, but have
no data).
Peli
quickly answer your two points here:
> 1) It requires users to do manual dependency resolution and management
> currently. Experience from Linux indicates that a lot of users find
> this hard/irritating. Let's not establish a precedent here, that would
> suck. Death to manual dependency management!
management is required. But this could well be created by a third
party (I'm thinking of OI here again :-) )
> 2) Badly written extensions might accidentally allow themselves to be
> controlled by an activity != the one they were meant for. That'd
> result in a circumvention of the security system.
uninstall the badly written extension to stop unwanted behavior.
It is more difficult with a large monolithic application that is badly
written to remove badly behaving parts without loosing the rest of the
application that you like.
> It's probably better, for now, to just require all the permissions
> your app needs for the full feature set.
phone is not a Linux desktop, so I assume that a "full feature set"
application on the phone would typically be much simpler than a
corresponding desktop application. It seems to me the more important
to have the possibility to customize the behavior through extensions,
similar to Firefox extensions.
> Otherwise we'll either end up
> with weird componentization hacks like this one,
the users won't need or use on their phone, and it would even make
more sense to componentize these features if they require particular
security permissions.
I agree with you that an application should ask for all permissions it
needs to work properly, but all I'm claiming is that it is probably
badly designed focus of the application if it requires more than a few
permissions (and the end user also won't read through all of these).
Peli
Disconnect
You mean like the current security patches? (ahem*reinvented-selinux*ahem)
So I can pull out all the funky socket-opening stuff without breaking the security model? (Or, better, just boot an upstream kernel.)
On Sat, Dec 20, 2008 at 11:40 AM, Dianne Hackborn <hac...@android.com> wrote:We are also simply not going to require special patches of the kernel to implement very specialized behavior, especially special patches without which the entire security model would break down.
On Sat, Dec 20, 2008 at 8:08 AM, Jean-Baptiste Queru <j...@google.com> wrote:
The concern is indeed the fact that the SD card can also be read
without going through the kernel (by pulling the SD card and inserting
it into a card reader. In fact even connecting the device to a
computer over USB would have the same problem.
JBQ
--
On Sat, Dec 20, 2008 at 7:02 AM, Mike Hearn <mh.in....@gmail.com> wrote:
>
> I read that the currently considered solution is to place an encrypted
> filesystem on the SD card. Can somebody explain to me why it's
> insufficient to enforce permissions using some kind of pattern
> matching rules inside the kernel, eg, rules like:
>
> All files except those under /Applications are permission free.
> /Applications may only have directories in it.
> Each directory under /Applications contains a secure application
> identifier (certificate?).
> Reads/writes to these directories are denied unless the process is
> associated with that ID.
> Associating a process (or rather, internal uid/gid) with that cert is
> a privileged operation.
>
> Or is the concern that people may take the SD Card, plug it into a
> desktop and then some other app interferes with the permissions.
>
> I am not sure why cryptography is necessary here, if the kernel would
> enforce Android-level security on open().
>
>
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.
--
Dianne Hackborn
Android framework engineer
hac...@android.com