Yeah this is an area the system is not behaving correctly. For signature permissions, there are a number of things it can do better: automatically grant the permissions regardless of the install order, and it definitely should remove permissions when the app defining them is uninstalled.
One way you can probably work around this is to declare the permission in -all- apps that use it. The first one that gets installed will define the permission for the system; all others that get installed will use it, as long as their certs match. (Assuming we are talking about a signature only permission here.) On Fri, Nov 6, 2009 at 4:43 AM, guillaume leterrier (Teleca Germany) < [email protected]> wrote: > > That is an interesting point and a potential security breach. > > However, is there already any protection? > > Requesting/Using a permission and declaring/creating a permission are > not the same. > > A new application installation shall fail, if it declares ("creates") > a new permision which is already granted to any other installed > application. > > This would cover this problem. The user would be required to uninstall > first. > > Informing the user about the potential risk (listing the application > that would use the newly declared permissions) could be an other > option, but simply rejecting the installation is probably safer. > > Guillaume > > On 4 Nov., 03:39, wook <[email protected]> wrote: > > Thank you for the explanation, Machigar. > > > > Looking at the description and the example, I wonder if there > > is a security breach like... > > > > 1. A malicious user User_M creates a bogus application, App_DECOY > > which declares some permissions with "normal" protection level. > > The permissions have names that other companies use for their > > own protection, for example, "com.visa.permission.IMPORTANT" or > > "com.master.permission.IMPORTANT". > > > > 2. The User_M deploys another application, App_EXPLOIT that uses > > the bogus permissions. After a victim installed App_EXPLOIT > > successfully, somehow User_M make the victim uninstall App_DECOY > > (may be User_M can say, it's a normal update procedure). > > > > 3. And then, the victim happens to install an application that is > > supposed to protect its data relying on "the real" > > com.visa.permission.IMPORTANT. But, the App_EXPLOIT would be able > > to access the new application's data using the bogus permissions. > > > > If this is correct, I think > > all permissions should be able to prove its declaration origin > > in a handset. Also, when the user uninstalls an application that > > defines a permission, the permission must be revoked, and the user > > should be informed which installed-applications use the permission. > > > > - Wook > > > > On Nov 4, 12:52 am, Machigar Ongtang <[email protected]> wrote: > > > > > > > > > Dear Ohpato, > > > > > Android recognizes permissions by their labels (text string). When the > > > permission is granted, it cannot be revoked. > > > As a result, even though the declaring application (app A in your case) > is > > > uninstalled, > > > the application that was assigned with such permission at it install > time > > > (your app B) still holds the permission. > > > App B can still use the permission as usual. For example, if app C uses > such > > > permission to protect its component, > > > app B can still access that component. > > > > > Moreover, if a newly installed application, say app D, declares the > same > > > permission that B is holding and uses it to > > > protect one of its components, app B can use that permission (which it > > > holds) to access app D's component as well.- Zitierten Text ausblenden > - > > > > - Zitierten Text anzeigen - > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
