On Mon, Jun 10, 2013 at 9:07 AM, Antonio M. Amaya <[email protected]> wrote: > On 10/06/2013 18:00, Jonas Sicking wrote: >> >> On Mon, Jun 10, 2013 at 8:39 AM, Antonio M. Amaya <[email protected]> wrote: >>> >>> Hey all. >>> >>> From a security point of view, moving the apps to the sdcard opens a can >>> of >>> worms. Or several ones, actually. Currently there are some assumptions >>> that >>> the security model holds true, that won't hold true anymore after/if some >>> of >>> the proposed changes land. The most important two that I can think of, >>> off >>> the top of my head, are: >>> >>> >>> * There's no way for an app to access the code (unless it has the >>> webapps-manage permission) or data (in any case) of another app. That >>> means, >>> amongst other things, that I could currently an app that stores some >>> private >>> data on the phone and it will be reasonably secure (barring a >>> catastrophic >>> compromise of the underlying OS). >>> * The only process that can write on the application code and data >>> directory is the parent process (that runs as root). >>> >>> Taking that as granted, some security decisions were taken that made >>> sense >>> on that context and that would make no sense on a context where the apps >>> are >>> stored on a media that's writable by other apps/other random devices. For >>> example (I'm CCing bsmith because of this one, actually), currently, app >>> signature is validated only at installation time. Once the app is on the >>> device, is assumed to be secure (for the trust level it has, be it >>> certified, privileged or just packaged). >>> >>> What does this mean if apps are installed/executed from the sdcard? Well, >>> for once it means we could have a virus on a computer replacing a >>> privileged/legit app with some malware that made use of the permissions >>> granted to the legit app. To mitigate this risk, the signature should be >>> verified at load time (instead of just at install time as it's now). We >>> can >>> use the ids.json included actually to verify that the package is the same >>> one that was installed. >>> >>> But that's just an example. A move of this caliber should require a >>> in-depth >>> risk analysis, before (or at the same time) the decisions of what to move >>> and what not to move is made. For example, to me it doesn't make much >>> sense >>> to move all of the data jars of an app to the sdcard by default. I think >>> the >>> default behavior should be the secure one (store the data jars on a place >>> that isn't exposed, as they're now) and the insecure behavior (store them >>> on >>> the sdcard) should be something that the apps require explicitly. >> >> FWIW, I assume that if we enable storing apps on the SD card, that we >> store them in a directory that we prevent using the DeviceStorage API >> from using. I.e. the DeviceStorage API would be changed so that it >> never traverses into this directory, no matter what argument is passed >> to getDeviceStorage() > > > That would fix part of the problem, but just part. Even assuming apps > wouldn't be able to traverse it, any process compromise would grant > access to all the data on the sdcard (as it does now, actually, the > sdcard directories have a permission of 075). And, of course, there's > the problem of explaining users that plugin their phone on a computer > could expose the apps private data (including cookies and such, if all > the data jars are moved).
Child processes do not have access to the sdcard. All access to the sdcard, which currently is only the DeviceStorage API, goes through the parent process. I think this is enfoced not through directory permissions, but rather by how we mount the sdcard. The same would apply if we move apps to the sdcard. We still wouldn't let apps access the sdcard directly, it would always go through the parent process. I agree that no matter what we do, we always need to use kernel-enforced protection of application code and data so that applications can't access each other. Even if an application is able to compromise a process. / Jonas >> / Jonas >> >>> On 07/06/2013 7:49, Paul Theriault wrote: >>> >>> I assume that file permissions would be set to prevent adb access to app >>> & >>> data, as it currently is on /data ? Will there need to be any changes to >>> APIs which allows access to the sdcard (devicestorage, usb mass storage) >>> to >>> prevent apps accessing other app's data? >>> >>> >>> >>> On Jun 7, 2013, at 3:00 PM, Fabrice Desre wrote: >>> >>> >>> >>> Given the limited space available on the /data partition, I'd like to >>> add the possibility to move apps to the sdcard. This means moving the >>> app package and manifest, and also private data jars. >>> >>> For this, we need to: >>> - Add a new api call to mozApps.mgmt, eg DOMRequest >>> moveToExternalStorage(Application) >>> - Add a new api to manage the app lifecycle, since we need to make sure >>> an app is not running before we move it. This one could live on the app >>> object itself, or on mozApps.mgmt. >>> - Update the webapps code and the app:// protocol handler accordingly. >>> - Update data jars to be usable on the sdcard. Ben thinks that this is >>> doable for indexedDB. That may be harder for other stores that use a >>> common db for all apps. >>> - Add some UI in Gaia. >>> >>> One issue is that some devices have several external volumes. Any ideas >>> on how to manage that are welcome. >>> >>> Fabrice >>> -- >>> Fabrice Desré >>> b2g team >>> Mozilla Corporation >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected]<mailto:[email protected]> >>> >>> https://lists.mozilla.org/listinfo/dev-b2g >>> >>> >>> >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected]<mailto:[email protected]> >>> https://lists.mozilla.org/listinfo/dev-b2g >>> >>> >>> >>> ________________________________ >>> >>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >>> nuestra política de envío y recepción de correo electrónico en el enlace >>> situado más abajo. >>> This message is intended exclusively for its addressee. We only send and >>> receive email on the basis of the terms set out at: >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>> >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-b2g > > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el enlace > situado más abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
