When a new application is installed with a shared_ID and common signature, it will gain automatically all permissions already granted to other installed applications with the same shared_ID and signature.
In the case , I guess it could be useful to display to the end-user, before confirming the new application installation, the list of all the permissions, this application will have, even if they are not requested in the application manifest. Indeed, if this new application really needs such permission, then the user may still decide to install it. Otherwise, he may simply prefer install an other application version that will not have the shared ID, and will be "less dangerous" (less granted permission), due to less automatically granted permissions. The shared ID scheme is useful for developer and software update/ modularity, but could be maliciously exploited as described in the previous thread. The more information the end-user will have about granted permissions, the better choice about the installation and its consequences, he will make. Disconnect wrote: > Oh I forgot. There is an even easier example on the adp1/holiday phones: One > app, NO permissions. > > Can you guess what it does? :) > > On Fri, May 1, 2009 at 6:21 PM, Disconnect <[email protected]> wrote: > > > Effectively yes, that is corirect. However, you can save some complication > > - two apps. One saves your contacts to SD. The other (net permissions only) > > dumps all those contacts, plus your photos and music and whatever else, up > > to a server. (Over edge/3g only, so you can't even sniff it.) > > > > ...oops. > > > > So far that example has been the answer to any question about enhancing > > android security in a useful way (such as temporary permissions). I'm not > > quite sure I understand how it applies, but I've mostly given up arguing > > about it. (If you want to find the threads, look for ones with me and > > hackbod. Those are the ones that come to mind most readily, although I'm not > > picking on her directly - she's hardly alone in espousing that position.) > > > > > > On Fri, May 1, 2009 at 11:47 AM, jfr <[email protected]> wrote: > > > >> > >> Hello all, > >> > >> I'm trying to wrap my heads around this, so forgive me if I'm > >> rehashing conversations had elsewhere. This is based on what I've read > >> in this thread. Let me pose a hypothetical scenario: > >> > >> Say I'm a user of average technological savvy -- I know that the > >> padlock icon on my pc browser means things are safe, I don't like > >> connecting to unknown WiFi points because I've heard there's snooping > >> going on, but I'm not a computer weenie -- I'm just an average user. > >> Say I also like cute widgets. > >> > >> Say someobody writes four applications that use protected APIs, sells > >> them as a package called MyCuteWidgetsSuite or individually. The apps > >> are as follows: > >> > >> MyRingerPhoneBook requires access to the phonebook on the device so > >> that I can attach a nice little sound to each contact when I scroll > >> over. It specifies READ_CONTACTS in the Manifest as a required > >> permission. I allow it to run because while I know it reads my > >> contacts, it says nothing about sending things over network -- so I > >> think my contact data is safe. > >> > >> MyPhoneCallFireworks is a little app that shows a cute animation > >> whenever I make a phone call. It specifies PROCESS_OUTGOING_CALLS in > >> the Manifest as a required permission. I allow it to run because well, > >> it makes sense to do so and there is nothing about sending things over > >> the network. > >> > >> MySparkleSMS is a little app that shows a cute little sparkly rainbow > >> whenever I get an SMS from a friend, and that puts invisible > >> characters in outgoing SMS messages so that other friends with > >> MySparkleSMS will get my sparkly rainbow when I send them a message. > >> It specifies RECEIVE_SMS and SEND_SMS. This makes sense to me because, > >> yes, it's an SMS application > >> > >> MyPhoneCallWhenNear is a little app that automatically calls my > >> buddies when they're within two blocks of me. It specifies CALL_PHONE > >> and ACCESS_COARSE_LOCATION and INTERNET in the manifest. The whole > >> Internet thing kind of wigs me out a bit, but I already installed two > >> other apps in the suite months ago and they've been behaving very > >> nicely, plus it's not using GPS but just WiFi location... I guess I > >> can trust the app. Sure, I will allow it to run. > >> > >> Each application has sharedUserId specified in the Manifest, and all > >> apps are signed under the same self signed certificate. According to > >> Android documentation (http://developer.android.com/guide/topics/ > >> security/security.html<http://developer.android.com/guide/topics/%0Asecurity/security.html>), > >> all these applications share privileges. They > >> are, in essence, one big application with a whole host of permissions. > >> > >> Say MyCuteWidgetsSuite was written not by a lover of sparkly things > >> but by a shady character in East Evilonia, and that in 12 months, > >> after the apps have been on the top-10 downloads list in the > >> Marketplace and highly rated by lots of lovers of sparklies, the apps > >> will wake up and download all my call logs, contact information, a > >> record of my location movements and my full SMS message trails to a > >> server It will also be able to open up an internet connection to a > >> server, make outgoing phone calls without my knowing it (and listen to > >> my conversations), and send SMS messages silently, helping it become > >> part of a an SMS and phone dialer spam zombienet. > >> > >> Question: > >> Is this a plausible scenario? Or is there something I'm missing about > >> self-signing and security between applications with the same cert/UID? > >> What in the Android Security Model prevents this kind of scenario? > >> > >> -jfr > >> > > > >
