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]
