We won't be changing the framework permissions to use a new "dangerousOrSignature" permission. There are two major problems with this:
(1) The signature is supplied by the device manufacturer, meaning that you need to have a relationship with every manufacturer (or carrier) who you want to use this facility with, potentially requiring that an app be signed with a very large number of certificates. (2) It seriously violates our "all apps are created equal" tenant. On Mon, Apr 6, 2009 at 1:36 AM, guillaume leterrier (Teleca Germany) < [email protected]> wrote: > > > Will, > > You are correct. If the signature check fails, the user approval will > still be requested. That is exactly the concept behind > "DangerousOrSignature". It could be better called > "SignatureFirstOrDangerous" > > If one wants to declare a permission protection based on signature > only (no end-user approval request ever), then it shall only use the > "signature" protection level. > > To answer your question, the "SignatureFirstOrDangerous" protection > level provides more flexibity and ease in the permission approval > process. It has the have major advantage of automatically approving > the required permission, if there is a trust relationship between the > permission requester and provider (based on signature). It could make > a more friendly end-user experience, because the end-user would not be > asked for approval. At the same time, it still provides the > possibility for the end-user to approve or not, if this trust > relationship doesn't exist. > > This could be quite powerful in the case of common SW libraries (as > for example ,the Android protected APIs) that are used a lot by many > various applications. > > The applications could be pre-approved (meaning signed with the same > signature of the requested permission) or would be simply not pre- > approved. > > In the future, I m convinced that some application will emerge as > standard applications for the android platform (to be installed by the > end-user, and not pre-installed in the system image) provided by very > well known software application supplier. These standard applications > could be pre-approved for these multiple common SW libraries (multiple > signature scheme), and so make the approval process seamless, removing > a potential complex permission approval hurdle from the end-user. > The OEM could then decide to get pre-signed or not these common SW > libraries by the pre-approved application SW suppliers. As the common > SW libraries could be part of the system image, then could still be > upgraded by a secure FOTA scheme at further stages of the product life > cyle. > > In case of an application that is not pre-approved, it could still > request the use of these common SW libraries > ("SignatureFirstOrDangerous"), but the end-user will assess the > security risk (being sufficiently informed) and decide or not to grant > the permission request. > > Basically, the "SignatureFirstOrDangerous" protection level may end up > simply replacing the "Dangerous" protection level in the Android > security scheme. Indeed, it is in a way backward compatible. if the > signature check is failing, then the end-user can still be requested > to grant or not. > > > Of course, such extra flexibility of the permission approval process > (signature based) is improved or is definitely more valid if the > multiple signature level is also supported (as described in the > previous post) by the Android platform. > > > Guillaume > > > > > On Apr 3, 8:40 pm, William Enck <[email protected]> wrote: > > Guillaume, > > > > Since users that currently accept all dangerous permissions are going > > to accept all failed DangerousOrSignature permissions as well, does > > the new protection level really buy us anything? > > > > Thanks, > > > > -Will > > > > On Apr 2, 2009, at 10:22 AM, guillaume leterrier (Teleca Germany) wrote: > > > > > > > > > > > > > > > > > Yes, I agree that this is not how Android security scheme is designed > > > (meaning there is no central certificate authority in the scheme). > > > > > But, I think it would not be necessary to go for a full centralized > > > certificate authority scheme (“a certificate that most applications > > > must be signed with in addition to their own to be able to get most > > > existing application permissions“) to extend the current scheme. > > > > > I guess, having the multiple signature scheme supported and a new > > > protection level supported could be sufficient. > > > > > Indeed, for example, most of the Android protected APIs (declared in > > > \frameworks\base\core\res\AndroidManifest.xml) are currently protected > > > as Dangerous protection level. > > > > > It would be interesting to create a new protection level > > > (DangerousOrSignature) and apply it to all current permissions > > > protected as Dangerous. > > > > > If the developer application (requesting a protected API) has been > > > also signed with the same key of the protected APIs package, the end- > > > user would not have to grant manually the requested permissions. > > > > > If the application is only signed by the developer, then the user > > > would be requested to grant or not the permissions (i.e installing or > > > not the application). > > > > > To avoid any unforeseen security side-effects and complexity, it may > > > be preferable to make a strict distinction between the primary key > > > used to sign the application, and the subsequent multiple signing keys > > > (secondary keys). > > > The secondary keys shall only be used to request signature protected > > > permissions (permissions declared by other applications signed by > > > primary keys matching one of the requesting application secondary > > > keys). > > > However, the secondary keys shall not be used to grant a permission > > > (declared by the application itself) requested by other applications. > > > Only the primary (as in the current scheme) shall be used for this > > > purpose. > > > To sum-up, the secondary keys shall only be used to request signed > > > permissions declared by other applications (based on their primary > > > keys). > > > > > Enabling such multiple signature scheme enables to support > > > applications that would request signed permissions provided by > > > different applications signed by different signatures, without forcing > > > the end-user to decide to grant or not those permissions. This will > > > also avoid, for achieving the same result, to resign all applications > > > with a common signature, but only the one requesting the signed > > > permissions of other applications. > > > > > Basically, the DangerousOrSignature protection level may end up simply > > > replacing the Dangerous protection level in the Android security > > > scheme. > > > If the signature check is failing, then the end-user can still be > > > requested to grant or not. > > > The only advantage of the current Dangerous protection scheme is to > > > always request the end-user granting decision whatever the application > > > signature. > > > > > Guillaume > > > > > On Apr 1, 7:02 pm, Dianne Hackborn <[email protected]> wrote: > > >> I am not sure what exactly you are looking for, but from your > > >> original > > >> message it sounds like you want to have a certificate that most > > >> applications > > >> must be signed with in addition to their own to be able to get most > > >> existing > > >> application permissions. > > > > >> If so, we simply do not do that. Android is an open platform, and > > >> we do not > > >> require that applications be signed by some authority to use standard > > >> features of the platform. > > > > >> I could certainly imagine one extending the system to add a new > > >> permission > > >> type where you specify the certificates that can have it, but we > > >> won't use > > >> this in the base platform, because that is not how we do security. > > > > >> On Wed, Apr 1, 2009 at 7:06 AM, guillaume leterrier (Teleca > > >> Germany) < > > > > >> [email protected]> wrote: > > > > >>> Well, I do not agree. Indeed, as it was mentioned in an other thread > > >>> (copied below), the multiple signature scheme is not supported. > > >>> In my opinion, this is a huge limitation for the platform. > > > > >>> Basically, this means that an application can declare a permission > > >>> ( protected by the signature scheme ), but this permission can > > >>> only be > > >>> used by an other application with the same signature. So, one can > > >>> not > > >>> create a permission ( protected by the signature scheme ) and have 2 > > >>> different applications (signed with 2 different signatures, coming > > >>> from 2 different developers ) using this permission. Only a > > >>> dangerous > > >>> or normal protection allows to do that ! > > > > >>>> 1)I know jar signer support multiple signatures in one jar file. > > >>>> If an > > >>>> APK file has two valid signatures, does that mean this APK can > > >>>> access > > >>>> signature level permission provided by both signers? > > > > >>> In theory, something is done with multiple signatures, but nobody > > >>> has > > >>> ever > > >>> used this so it probably doesn't work. This also has the side- > > >>> effect > > >>> (if it > > >>> does work) of aliasing the two signatures to the same thing since > > >>> they > > >>> presumably come from the same owner, which is likely not what you > > >>> want. > > > > >>> So basically, please don't do this. :) > > > > >>> On Mar 27, 11:14 pm, "[email protected]" <[email protected]> > > >>> wrote: > > >>>> Android permissions guard activities between applications. From > > >>>> Security perspective, android frame work is as same as an > > >>>> application. > > >>>> To use signature level or permission defined by framework, your > > >>>> application has to be signed using same key. > > > > >>>> You can define signature level permission in your application as > > >>>> well. > > >>>> And you can use multiple signing keys to sign your application. > > >>>> Other > > >>>> app would need to be signed using one of signing keys you used so > > >>>> they > > >>>> can use permission enforced by your application. > > > > >>>> Do you agree with me? > > > > >>>> For T-Mobile G1, HTC generated 4 keys to sign different groups of > > >>>> APKs. These 4 keys are corresponding to 4 keys in open source: > > >>>> testkey, media, platform and shared. You can search .bks files > > >>>> under > > >>>> build directory. > > > > >> -- > > >> 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 - > > > > -- > > William Enck > > PhD Candidate > > Department of Computer Science and Engineering > > The Pennsylvania State University > > [email protected] 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.
