My understanding is that system apps will be granted a system or systemOrSignature permission only if they request the permission in their manifest. Moreover, starting with Android 4.4, for the purpose of permissions, only privileged pre-installed apps/packages (those in /system/priv-app directory) are considered "system" -- in previous versions of Android all pre-installed apps/packages were considered "system" -- see https://android.googlesource.com/platform/frameworks/base/+/ccbf84f44c9e6a5ed3c08673614826bb237afc54.
Alex On Sun, Feb 9, 2014 at 8:31 PM, Balu .. <[email protected]> wrote: > > Can anyone please clarify on the Protection Levels for a permission? > Below is my understanding: > > "Protection levels - ‘signature’ and ‘systemOrsignature’ are same except for > the below reason. In either case a system app is always having the > permission. > > Suppose X is defining permission with Protection level systemOrsignature. > > And Y is a system app that is part of the system image, > then Y has the permission. > > And if Z is another vendor app that has a same certificate/signature (if the > developer (OEM) of X has shared it with vendor), > then Z too has the permission, even if Z is not part of system image. > > So, this helps non-system apps that share OEM signature. " > > Also, Is there a way to prevent the system apps that dont have a permission > in its Manifest from the access. > To be clear: > "Suppose X is defining permission with Protection level systemOrsignature. > And Y is a system app that is part of the system image, > then Y has the permission. " > > In this case is it possible to prevent Y from having the permission? > > Please clarify. > > > > On Thursday, 29 November 2012 03:25:01 UTC+5:30, Joman Chu wrote: >> >> The relevant code is in PackageManagerService grantPermissionsLPw, around >> line 4812 where there's a lot of else-ifs testing for various flags in the >> permission. >> >> AOSP includes 4 keys in build/target/product/security. The package >> containing the framework (called android, in framework-res.apk) is signed >> with the platform key. One would hope consumer devices don't ship apps >> signed with these keys. >> >> My reading of the code would indicate that your guess is correct. Look at >> the test against mPlatformPackage.mSignatures (mPlatformPackage is the >> framework). >> >> On Tue, Nov 27, 2012 at 11:37 AM, Michael <[email protected]> wrote: >>> >>> Sorry for resurrecting an almost 2-year-old topic. >>> >>> Have read through the entire thread - the take-away is: >>> >>> 1. If an app is preloaded under the /system partition, it is granted >>> SystemOrSignature protection level permissions. >>> 2. An update to the same application (i.e. signed with the same key) >>> would retain the same grants, even when the update resides under /data >>> >>> My question is - in the context of developing a custom rom using AOSP - >>> there are cases where the application is not preloaded under /system (say, >>> during development when it is installed through adb install) yet the >>> application is granted SystemOrSignature permission. All I'm doing is to >>> sign the system with the AOSP debug key. >>> >>> So it seems that in addition to the above rules, there seems to be an >>> existence of some "Platform key" of sorts that an application can derive >>> SystemOrSignature permissions with. In practice - of course, it differs >>> from manufacturer to manufacturer. My question is, on a typical device >>> (say, AOSP on a development board), how does the framework trust a >>> signature? If so, how many of them are there? >>> >>> My guess is that the platform signature is the one the framework itself >>> is signed with prior to loading, i.e. framework checks if the package is >>> signed with the same certificate that the framework itself is signed with, >>> therefore the concept of "platform signature" is implicit - i.e. there is >>> only one of them, it is not stored anywhere except as a certificate of the >>> package named "android". >>> >>> Dianne, would you confirm or debunk my understanding, as it is not >>> something I could find on the developer documentation? Thanks! >>> >>> >>>> >>>> On Tuesday, 22 February 2011 20:36:06 UTC-5, Dianne Hackborn wrote: >>>>> >>>>> Yes, adb install -r calls the same PackageManager function that market >>>>> does. >>>>> >>>>> The new app can not get new system permissions that the original one >>>>> did not have. It can only keep the previously granted permissions. >>>>> >>>>> On Tue, Feb 22, 2011 at 5:34 PM, Felipe <[email protected]> wrote: >>>>>> >>>>>> Hi Dianne, >>>>>> >>>>>> Thanks for the quick response. Sorry if I wasted your time with the >>>>>> big message. I just wanted to clarify the scenario. >>>>>> >>>>>> Basically, I was asking if we can use "adb install -r" to simulate an >>>>>> update, like the one Market app does. I need to test it this way, >>>>>> since Market doesn't have a staging area to do this kind of upgrade >>>>>> test. I know that "adb install -r" simulates well an upgrade, but >>>>>> since I was not able to make this permission thing work using it, I >>>>>> thought that it may not do exactly what the Market does regarding the >>>>>> permissions. So, could you please confirm that adb install -r is fine >>>>>> for this kind of test? If no, is there any other way, or shall I just >>>>>> trust that it is going to work? >>>>>> >>>>>> Another question I have, since it works, is about extra >>>>>> systemOrSignature permissions on the version 2 of the app that were >>>>>> not on the apk installed in the system partition. Will these >>>>>> permissions be granted, even if they were not in the original version >>>>>> of the app, or will the system just grant the permissions that were >>>>>> inside the original apk? >>>>>> >>>>>> Here are the Manifests of the two versions of app 2. I don't know if >>>>>> it helps or not. I am really out of ideas on how to simulate this and >>>>>> get it working. >>>>>> >>>>>> APP_2_V1 >>>>>> >>>>>> <?xml version="1.0" encoding="utf-8"?> >>>>>> <manifest xmlns:android="http://schemas.android.com/apk/res/android"; >>>>>> package="com.felipe.app2.test" >>>>>> android:sharedUserId="com.felipe.app2.test" >>>>>> android:versionCode="1" >>>>>> android:versionName="1.0"> >>>>>> <uses-permission >>>>>> android:name="com.felipe.app1.Permissions.ACCESS_ACCOUNTS"/> >>>>>> <application android:name="com.felipe.app1.App" >>>>>> android:icon="@drawable/icon" android:label="@string/ >>>>>> app_name"> >>>>>> <uses-library android:name="com.felipe.library.utilities"/> >>>>>> >>>>>> </application> >>>>>> </manifest> >>>>>> >>>>>> >>>>>> APP_2_V2 >>>>>> >>>>>> <?xml version="1.0" encoding="utf-8"?> >>>>>> <manifest xmlns:android="http://schemas.android.com/apk/res/android"; >>>>>> package="com.felipe.app2.test" >>>>>> android:sharedUserId="com.felipe.app2.test" >>>>>> android:versionCode="2" >>>>>> android:versionName="2.0"> >>>>>> >>>>>> <uses-permission >>>>>> android:name="com.felipe.app1.Permissions.ACCESS_ACCOUNTS"/> >>>>>> <application android:name="com.felipe.app1.App" >>>>>> android:icon="@drawable/icon" android:label="@string/app_name"> >>>>>> >>>>>> <uses-library android:name="com.felipe.library.utilities"/> >>>>>> <activity android:name=".Main" >>>>>> android:label="@string/app_name"> >>>>>> <intent-filter> >>>>>> <action android:name="android.intent.action.MAIN" /> >>>>>> <category >>>>>> android:name="android.intent.category.LAUNCHER" /> >>>>>> </intent-filter> >>>>>> </activity> >>>>>> </application> >>>>>> </manifest> >>>>>> >>>>>> Sorry to bother this much. >>>>>> >>>>>> Felipe >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Dianne Hackborn <[email protected]> >>>>>> Date: Feb 22, 9:35 pm >>>>>> Subject: signatureOrSystem premissions >>>>>> To: Android Security Discussions >>>>>> >>>>>> >>>>>> It does work, Market relies on it working to do its self-updates. >>>>>> >>>>>> There isn't nearly enough information here to help you. There is a >>>>>> lot of >>>>>> text, but all of the information it contains seems to boil down to: "I >>>>>> have >>>>>> app A and app B, which both use a signatureOrSystem permission. If I >>>>>> have >>>>>> app A on the system image, and then update it with app B, then app B >>>>>> doesn't >>>>>> keep the permission." >>>>>> >>>>>> If that is really your scenario, all I can say is that this does work. >>>>>> There are a huge number of variabilities in exactly what you are >>>>>> doing and >>>>>> configuring things that could cause problems. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Feb 22, 2011 at 3:49 PM, Felipe <[email protected]> >>>>>> wrote: >>>>>> > Upgrading system apks through market and retaining permissions >>>>>> >>>>>> > Hi, >>>>>> >>>>>> > I tried to test the android ability of upgrading a system app with a >>>>>> > new version, but I am facing some permission problems. It seems >>>>>> > that, >>>>>> > after the app is upgraded, it looses the capability of accessing >>>>>> > permissions that are systemOrSignature. I am testing this on an >>>>>> > engineering build that is signed with a debug certificate. >>>>>> >>>>>> > Below is a description of my test: >>>>>> >>>>>> > Setup: >>>>>> >>>>>> > 1) Three apps: >>>>>> > APP_1 - signed with CERT_1 - provides some functionality that is >>>>>> > protected by PERM_1 permission, that is systemOrSignature >>>>>> >>>>>> > APP_2_V1 - signed with CERT_2 - version one that goes inside the >>>>>> > system partition >>>>>> >>>>>> > APP_2_V2 - signed with CERT_2 - version that is going to be >>>>>> > installed >>>>>> > to upgrade APP_2_V1 >>>>>> >>>>>> > APP_2_* (V1 and V2) use the PERM_1 permission to do some stuff >>>>>> >>>>>> > ============= >>>>>> > Test 1 >>>>>> > ============= >>>>>> > Objective: >>>>>> > - Validate that APP_2_V1 is able to use the permission PERM_1. >>>>>> >>>>>> > Setup: >>>>>> > - Put APP_1 and APP_2_V1 on the system partition. >>>>>> >>>>>> > Test: >>>>>> > - execute APP_2_V1 and test the scenario that uses the PERM_1 >>>>>> > permission. >>>>>> >>>>>> > Result: >>>>>> > - APP_2_V1 was able to access it fine. >>>>>> >>>>>> > ============= >>>>>> > Test 2 >>>>>> > ============= >>>>>> > Objective: >>>>>> > - Validate that APP_2_V2 is able to use the permission PERM_1. >>>>>> >>>>>> > Setup: >>>>>> > - Put APP_1 and APP_2_V2 on the system partition. >>>>>> >>>>>> > Test: >>>>>> > - execute APP_2_V2 and test the scenario that uses the PERM_1 >>>>>> > permission. >>>>>> >>>>>> > Result: >>>>>> > - APP_2_V2 was able to access it fine. >>>>>> >>>>>> > ============= >>>>>> > Test 3 >>>>>> > ============= >>>>>> > Objective: >>>>>> > - Validate that when APP_2_V1 is upgraded from market with >>>>>> > APP_2_V2, >>>>>> > the new version will be able to use the PERM_1. >>>>>> >>>>>> > Setup: >>>>>> > - Put APP_1 and APP_2_V1 on the system partition >>>>>> >>>>>> > Test: >>>>>> > a - Get the APP_2_V2 apk and do a adb install -r >>>>>> > b - Test the APP_2_V2 and see if it works >>>>>> >>>>>> > Result: >>>>>> > a - APP_2_V1 was correctly upgraded to APP_2_V2 after the adb >>>>>> > install >>>>>> > -r >>>>>> > b - During the APP_2_V2 execution, the app was not able to use >>>>>> > PERM_1 >>>>>> > anymore >>>>>> > c - If upgrade is uninstalled, PERM_1 works again on the APP_2_V1 >>>>>> >>>>>> > Questions: >>>>>> > 1) Shouldn't the system still give permission PERM_1 to APP_2_V2 >>>>>> > after >>>>>> > it is installed in a phone with a system >>>>>> > partition that contains APP_2_V1? >>>>>> >>>>>> > 2) If yes on question 1, is there any page that explains how to test >>>>>> > this upgrade? Does market upgrade do anything >>>>>> > different from "adb install -r"? >>>>>> >>>>>> > Thanks and Regards >>>>>> >>>>>> > Felipe >>>>>> >>>>>> > ---------- Forwarded message ---------- >>>>>> > From: Dan Zhang <[email protected]> >>>>>> > Date: Oct 20 2010, 3:53 pm >>>>>> > Subject: signatureOrSystem premissions >>>>>> > To: Android Security Discussions >>>>>> >>>>>> > Are there any known flaws or hacks that can install native apps on >>>>>> > devices >>>>>> > without formal approval by Android? In other words, what >>>>>> > protections >>>>>> > make >>>>>> > the process to prevent unapproved self-installation of native apps >>>>>> > like >>>>>> > Maps, Youtube robust? >>>>>> >>>>>> > thanks >>>>>> >>>>>> > > ---------- Forwarded message ---------- >>>>>> > > From: Dianne Hackborn <[email protected]> >>>>>> > > Date: Jul 7, 1:50 am >>>>>> > > Subject: signatureOrSystem premissions >>>>>> > > To: Android Security Discussions >>>>>> >>>>>> > > Correct, for signatureOrSystem, if you are installed in the system >>>>>> > > image, >>>>>> > > then you will be granted the permission regardless of your signing >>>>>> > > cert. >>>>>> >>>>>> > > On Wed, Jul 7, 2010 at 12:38 AM, Dan Hein <[email protected]> >>>>>> > > wrote: >>>>>> > > > A clarifying question, just to make sure I understand >>>>>> > > > completely. >>>>>> >>>>>> > > > So in the scenario described above, the developer would sign the >>>>>> > > > pre-installed app with his or her own developer certificate, >>>>>> > > > correct? >>>>>> > > > Likewise, updates to the pre-installed app would be signed with >>>>>> > > > the >>>>>> > same >>>>>> > > > certificate? In other words, the developer's certificate never >>>>>> > changes. >>>>>> >>>>>> > > > The app derives special privilege as a by-product of originally >>>>>> > > > being >>>>>> > > > included in /system by the handset manufacturer; not because of >>>>>> > > > the >>>>>> > > > particular certificate used to sign said app. >>>>>> >>>>>> > > > Is my understanding correct? >>>>>> >>>>>> > > > Thanks, >>>>>> > > > Dan >>>>>> >>>>>> > > > On Thu, Jun 10, 2010 at 7:43 PM, Dianne Hackborn >>>>>> > > > <[email protected] >>>>>> > > >wrote: >>>>>> >>>>>> > > >> A new application needs to be signed with the same certificate >>>>>> > > >> as the >>>>>> > > old >>>>>> > > >> one to be able to update it. >>>>>> >>>>>> > > >> On Thu, Jun 10, 2010 at 3:43 PM, Pragati Ogal Rai < >>>>>> > > [email protected]>wrote: >>>>>> >>>>>> > > >>> Consider a scenario where an app is pre-installed by the >>>>>> > manufacturer. >>>>>> > > >>> Now the developer can create an updated app and puts it on the >>>>>> > > >>> market >>>>>> > > >>> signed with developer's own certificate. The users of the pre- >>>>>> > > >>> installed app can upgrade it. This is all good. But what if >>>>>> > > >>> someone >>>>>> > > >>> else besides the original developer (read hacker) place their >>>>>> > > >>> app >>>>>> > with >>>>>> > > >>> the same name in Android Market. Can users still upgrade their >>>>>> > > >>> pre- >>>>>> > > >>> installed app and get around SystemOrSignature permissions. >>>>>> >>>>>> > > >>> On Jun 4, 4:14 pm, Dianne Hackborn <[email protected]> >>>>>> > > >>> wrote: >>>>>> > > >>> > An application signed with a platform cert can't be placed >>>>>> > > >>> > on >>>>>> > Market, >>>>>> > > >>> > because each device has its own platform cert. >>>>>> >>>>>> > > >>> > An application developer that wants to use these permissions >>>>>> > > >>> > needs >>>>>> > to >>>>>> > > >>> be >>>>>> > > >>> > working with a device manufacturer to have the app >>>>>> > > >>> > pre-installed; >>>>>> > > given >>>>>> > > >>> > that, you can just be pre-installed on the system image and >>>>>> > > >>> > thus be >>>>>> > > >>> granted >>>>>> > > >>> > this type of permission without needing to be signed with a >>>>>> > > >>> > special >>>>>> > > >>> cert. >>>>>> > > >>> > (This also means you can place your app, signed with your >>>>>> > > >>> > own >>>>>> > cert, >>>>>> > > on >>>>>> > > >>> > Market, and deliver updates to it even to devices that are >>>>>> > > >>> pre-installed, >>>>>> > > >>> > like Google Maps does. When the update is applied, you can >>>>>> > continue >>>>>> > > to >>>>>> > > >>> have >>>>>> > > >>> > whatever permissions you were originally granted as an app >>>>>> > > >>> pre-installed in >>>>>> > > >>> > the system. Of course users could still install your app on >>>>>> > > >>> > a >>>>>> > device >>>>>> > > >>> where >>>>>> > > >>> > it wasn't pre-installed, so such an app needs to be able to >>>>>> > > >>> > run in >>>>>> > > some >>>>>> > > >>> way >>>>>> > > >>> > in situations where it doesn't get the permission.) >>>>>> >>>>>> > > >>> > On Fri, Jun 4, 2010 at 1:45 PM, ivan <[email protected]> >>>>>> > > >>> > wrote: >>>>>> > > >>> > > Hello, >>>>>> >>>>>> > > >>> > > I'm writing an extensive application that's going to >>>>>> > > >>> > > require the >>>>>> > > >>> > > downloading of media content. >>>>>> >>>>>> > > >>> > > I've learned a little about the DownloadProvider that >>>>>> > > >>> > > requires >>>>>> > > >>> > > signatureOrSystem permissions. >>>>>> >>>>>> > > >>> > > I'm assuming to be signed by the system signature one must >>>>>> > > negotiate >>>>>> > > >>> > > with Google and the OEM (or something like that). >>>>>> >>>>>> > > >>> > > Is this correct? >>>>>> >>>>>> > > >>> > > Can someone please explain the process of creating an >>>>>> > > >>> > > application >>>>>> > > >>> with >>>>>> > > >>> > > signatureOrSystem permissions that can access the >>>>>> > DownloadProvider? >>>>>> > > >>> > > Please note that this is an application meant for Google >>>>>> > > >>> > > Market. >>>>>> >>>>>> > > >>> > > Thanks. >>>>>> >>>>>> > > >>> > -- >>>>>> > > >>> > 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.- Hide quoted text - >>>>>> >>>>>> > > >>> > - Show quoted text - >>>>>> >>>>>> > > >> -- >>>>>> > > >> 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. >>>>>> >>>>>> > > -- >>>>>> > > 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. >>>>>> >>>>>> > -- >>>>>> > regards >>>>>> >>>>>> > Dan Zhang >>>>>> >>>>>> > -- >>>>>> > You received this message because you are subscribed to the Google >>>>>> > Groups >>>>>> > "Android Security Discussions" group. >>>>>> > To post to this group, send email to >>>>>> > [email protected]. >>>>>> > To unsubscribe from this group, send email to >>>>>> > [email protected]. >>>>>> > For more options, visit this group at >>>>>> >http://groups.google.com/group/android-security-discuss?hl=en. >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Android Security Discussions" group. >>>>>> To post to this group, send email to [email protected]. >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected]. >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/android-security-discuss?hl=en. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Android Security Discussions" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/android-security-discuss/-/WkOMxZpA0qoJ. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/android-security-discuss?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to > [email protected]. > Visit this group at http://groups.google.com/group/android-security-discuss. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/groups/opt_out.
