android security and policy

Below is the analyzed report on android policy issue from my opinion, share to u and welcome your comment or discussion.   

1.       Android Security Basic 

1.1                Linux Kernel Level 

1.1.1          Process isolation 

Each application running on the separated process, which is isolated and cannot attack other process 

1.1.2         Memory isolation 

Each application running on the isolated virtual memory domain, which will not attack other process’s memory 

1.1.3         UID/GID isolation 

Each application be assigned a unique UID/GID in install time and use it in running time, which make sure the resource in one application will not be attacked by other application. 

1.2              Permission 

Use permission to control the access to the components or the component’s service in the system. 

1.3              Signature

Use certification/signature to unique the author of the application, to control some specific feature and some signature-level permission, but not control which app can be install and run.   

2.     Android policy compromises 

2.1              cannot verify the application is really the application what you think 

since android’s apk’s signature support self-cerificate based signature, so it can not restrict the application within the authenticated author. Thus, some app can easily set its app name same as other famous app to trick the user to install them. For example, QQ is a famous app, then someone can named their apk also “QQ”, when user install it, he cannot find out that it actually is not the real QQ since in installing UI, android only will prompt the app name but without the author name(this is because all the certificate of the apk is self-signatured so cannot verify its author, this is limitation of current android). After install and open it, maybe user find out the trick but the app already do some attack or steal some policy information.   

2.2             “Nothing or All” rule based permission control mechanism in install time 

When install time, the permission will be prompted for user to grant or denied. User only can select “accept” to accept all the permission and continue to install, Or select “cancel” to deny all the permission and cancel install. He cannot selectively accept someone and deny others,   

2.3             run-time permission check is not supported

 for the “Nothing or All” rule, user must grant all the permissions if they want to install and use the app, thus cause some app apply the extra permission to do some extra job. BUT, android did not support the run-time permission check and revoke functionality.   

2.4            not protect the policy-related permission as signature protect level 

Android use protect level to control the permission’s protect level, some platform security related permission is restricted as signature protect level, which only be granted for the apk signed by the same platform certificate. BUT, for many policy-related permission, such as SMS, NETWORK, CONTACT, CALENDAR, SD WRITE, etc, related permissions only be set as “Danger” protect level, which only need User grant in install time and in fact, user always directly accept it to continue to install.   

2.5             not support the recall for the malicious app which already installed in handset 

Even Google found the malicious app in “Google Play”, the Android’s app store,  they only can remove them from the store, BUT cannot remove the app already installed in user’s phone, and also cannot prevent user from installing it when they get it from other source. It all is because that google did not provide the recall function.   

3.     What can we think, though google maybe not fulfill it 

3.1              Support both self-signatured certificate and the CA issued authorized certificate ‘s signed apk. 

Android can preload the OEM’s trust root certificate and google’s trust root certificate. For the trust certificated signed apk, can display both the app name and author name in installing time, and also give some indication that this app is certificated. For the untrusted certificate signed apk, only display the app name in installing time, and give warning that it is untrusted app. These different certificate also should be used to achieve other differentiation ,such as permission control, see below section.   

3.2             Support selectively accept only some permission to install the app in installing time   

3.3             Support run-time permission check and revoke 

In runtime, still check the policy-related permission and give prompt to user, user can accept this time, this session, or  always. User also can deny this time, this session or always.   

3.4            Use signature to protect the policy-based permissions 

For policy-based permissions, such as SMS, NETWORK, CALENDAR, CONTACT, SD WRITE,etc, we use signature protect level to protect them. That is, only the Policy ROOT Certificate or its chained certificate signed apk can apply these policy-based permission and be granted fully by users(that is they can use the permission silently and run-time permission check is by pass). Otherwise, though user grant them in installing time, but run-time permission check and revoke mechanism still is effect for them. OEM and Google can control the Policy-enabled chained certificate to control its strategy.   

3.5             Use certificate and/or package name to recall the specific app or the specific author’s all apps 

When some malicious app be found, we need spread this information widely and hope all user can delete them and not install them. When malicious app be founded, besides remove them in the app store, the Android app store server also need add the malicious app’s package name and certificate(use package name and certificate to unique identify one malicious app) into the recall BACKLIST. When some malicious author be founded, besides remove all the author’s apps in the store, the Android app store server also need add the malicious author’s certificate into the recall BACKLIST. Then, when user connect to Google Service Server, the updated recall list should be pushed to Clients. In Clients, it always will remain the latest recall list, and use it to restrict malicious app being installed, or removed the already installed malicious apps. Details can be: each time the recall list be updated, check all the installed app with the recall list, and auto remove the apps in recall list, Or give user prompt that contain the malicious app’s information, user can strongly remain the malicious app not be removed if he like. And each time user install one app, check whether it is in the recall list, if so, deny it, Or also give user the prompt that contain the malicious app’s information, user can strongly remain to continue to install it if he like.