android - 为安全而设计 - 2 - 开发文档翻译

由于本人英文能力实在有限，不足之初敬请谅解，希望大家落脚同时能指出不足。

本博客只要没有注明“转”，那么均为原创，转贴请注明链接

 

android 进程与线程 - 开发文档翻译 - 进程

android 进程与线程 - 开发文档翻译 - 线程

 

android activity开发文档翻译 - 1 - 基础篇

android activity开发文档翻译 - 2 - 生命周期篇

 

android task与back stack 开发文档翻译 - 1

android task与back stack 开发文档翻译 - 2

android task与back stack 开发文档翻译 - 3

 

android Fragment开发文档翻译 - 1

android Fragment开发文档翻译 - 2

 

android - 为安全而设计 - 1 - 开发文档翻译

android - 为安全而设计 - 2 - 开发文档翻译

android - 为安全而设计 - 3 - 开发文档翻译

 

本系列并没有对原文100%翻译，可能没有100%的贴出原文

 

Using Interprocess Communication (IPC)

使用进程间通信

Some Android applications attempt to implement IPC using traditional Linux techniques such as network sockets and shared files. 

We strongly encourage the use of Android system functionality for IPC such as Intents, Binders, Services, and Receivers. 

The Android IPC mechanisms allow you to verify the identity of the application connecting to your IPC and set security policy for each IPC mechanism.

一些Android应用试图使用传统的Linux技术实现IPC，比如网络socket和共享文件。

我们强烈鼓励使用Android系统IPC功能，比如Intent，Binder，Service和Receiver。

Android IPC机制允许你为每一个IPC机制验证连接到你的IPC和设置安全策略的应用的身份。

 

 

Many of the security elements are shared across IPC mechanisms. 

Broadcast Receivers, Activities, and Services are all declared in the application manifest. 

If your IPC mechanism is not intended for use by other applications, set the android:exported to false. 

This is useful for applications that consist of multiple processes within the same UID, or if you decide late in development that you do not actually want to expose functionality as IPC but you don’t want to rewrite the code.

很多安全元素通过IPC机制共享。

Broadcast Receiver, Activitie,和Service都在应用的manifest中声明。

如果你的IPC机制不打算给其他应用使用，设置android:exported属性为false

这对由同一个UID内多个进程应用，或者你在开发后期决定不想通过IPC暴露功能但是你又不想重写代码是很有用的

 

 

If your IPC is intended to be accessible to other applications, you can apply a security policy by using the Permission tag. 

If IPC is between applications built by the same developer, it is preferable to use signature level permissions. 

Signature permissions do not require user confirmation, so they provide a better user experience and more controlled access to the IPC mechanism.

如果你的IPC打算让别的应用访问，你可以通过使用Permission标记设置一个安全策略

如果IPC是相同开发者应用间的，使用签名级的许可更好一些。

签名许可不要求用户确认，所以他们提供一个更好的用户体验并且更能控制对IPC机制的访问。

 

 

One area that can introduce confusion is the use of intent filters. 

Note that Intent filters should not be considered a security feature -- components can be invoked directly and may not have data that would conform to the intent filter. 

You should perform input validation within your intent receiver to confirm that it is properly formatted for the invoked receiver, service, or activity.

一个可以引入困惑的区域是intent过滤器的使用

注意，Intent过滤器应该不被认为是一个安全功能 -- 组件可以直接的被执行并且也许没有符合intent过滤器的数据

你应该在你的intent接收器中执行输入验证来确保它有执行receiver，service或者activity恰当的格式。

 

 

 

Using intents

使用intent

Intents are the preferred mechanism for asynchronous IPC in Android. 

Depending on your application requirements, you might use sendBroadcast(), sendOrderedBroadcast(), or direct an intent to a specific application component.

Intent是Android中异步IPC机制的首选

根据你应用的需求，你也许使用sendBroadcast(), sendOrderedBroadcast()或者直接的intent来指定一个应用组件。

 

 

Note that ordered broadcasts can be “consumed” by a recipient, so they may not be delivered to all applications. 

If you are sending an Intent where delivery to a specific receiver is required, the intent must be delivered directly to the receiver.

注意，有序广播可以被接收者“消费”，所以他们也许不会被发送到所有的应用中。

如果你打算在必须发送给一个指定的receiver的地方发送一个intent，这个intent必须被直接的发送给这个receiver。

 

 

Senders of an intent can verify that the recipient has a permission specifying a non-Null Permission upon sending. 

Only applications with that Permission will receive the intent. 

If data within a broadcast intent may be sensitive, you should consider applying a permission to make sure that malicious applications cannot register to receive those messages without appropriate permissions. 

In those circumstances, you may also consider invoking the receiver directly, rather than raising a broadcast.

intent的发送者能在发送的时候验证接受者是否有一个许可指定了一个non-Null Permission。

只有有那个许可的应用才会收到这个intent。

如果在广播intent内的数据是敏感的，你应该考虑使用一个许可来保证恶意应用没有恰当的许可无法注册接收那些消息。

那种环境下，你也许也考虑直接执行这个receiver而不是发起一个广播

 

 

 

Using binder and AIDL interfaces

使用binder和AIDL接口

Binders are the preferred mechanism for RPC-style IPC in Android. 

They provide a well-defined interface that enables mutual authentication of the endpoints, if required.

在Android中，Binders是RPC-style IPC的首选机制。

必要的话，他们提供一个定义明确的接口，促进彼此的端点认证

 

 

We strongly encourage designing interfaces in a manner that does not require interface specific permission checks. 

Binders are not declared within the application manifest, and therefore you cannot apply declarative permissions directly to a Binder. 

Binders generally inherit permissions declared in the application manifest for the Service or Activity within which they are implemented. 

If you are creating an interface that requires authentication and/or access controls on a specific binder interface, those controls must be explicitly added as code in the interface.

我们强烈鼓励在一定程度上设计不要求接口指定许可检查的接口。

Binder不在应用的manifest中声明，并且因此你不能直接在Binder上应用声明的许可。

Binder继承在应用在manifest中Service或者Activity声明的，Service或者Activity内实现了的许可。

如果你打算建立一个接口，在一个指定binder接口上要求验证并且（或者）要求访问控制，这些控制必须在接口中清楚的在代码中添加。

 

 

If providing an interface that does require access controls, use checkCallingPermission() to verify whether the caller of the Binder has a required permission. 

This is especially important before accessing a Service on behalf of the caller, as the identify of your application is passed to other interfaces. 

If invoking an interface provided by a Service, the bindService() invocation may fail if you do not have permission to access the given Service. 

If calling an interface provided locally by your own application, it may be useful to use the clearCallingIdentity() to satisfy internal security checks.

如果提供一个需要访问控制的接口，使用checkCallingPermission()来验证Binder的主叫者是否拥有必要的许可。

因为你的应用的id已经被传递到别的interface，所以代表访问一个Service之前这尤其重要

如果执行一个service提供的接口，如果你没有对给定的service的访问许可，bindService()请求也许会失败

如果调用一个你自己应用提供的本地的接口，使用clearCallingIdentity()来消除内部的安全检查也行是有用的。

 

 

 

Using broadcast receivers

使用broadcast receivers

Broadcast receivers are used to handle asynchronous requests initiated via an intent.

Broadcast receivers是用来处理通过intent发起的异步请求

 

By default, receivers are exported and can be invoked by any other application. 

If your BroadcastReceivers is intended for use by other applications, you may want to apply security permissions to receivers using the <receiver> element within the application manifest. 

This will prevent applications without appropriate permissions from sending an intent to the BroadcastReceivers.

默认的，receiver是导出的并且可以被其他任何应用执行

如果你的BroadcastReceiver打算让其他应用使用，你也许想要在应用的manifest文件中使用<receiver>元素对receiver应用安全许可。

这将阻止没有恰当许可的应用发送intent给这个BroadcastReceiver

 

 

 

Using Services

使用Service

Services are often used to supply functionality for other applications to use. 

Each service class must have a corresponding declaration in its package's AndroidManifest.xml.

Service经常被用于为其他应用提供功能供其使用

每一个service类必须在它的包的AndroidManifest.xml中有相应的声明。

 

 

By default, Services are exported and can be invoked by any other application. 

Services can be protected using the android:permission attribute within the manifest’s <service> tag. 

By doing so, other applications will need to declare a corresponding <uses-permission> element in their own manifest to be able to start, stop, or bind to the service.

默认的，Service被导出并且可以被其他应用执行

可以在manifest文件中的<service>标记使用android:permission保护Service

这样做，其他应用在他们自己的manifest文件中将需要声明一个相应的<uses-permission>元素来启动，停止或者绑定到这个service上

 

 

A Service can protect individual IPC calls into it with permissions, by calling checkCallingPermission() before executing the implementation of that call. 

We generally recommend using the declarative permissions in the manifest, since those are less prone to oversight.

一个Service可以保护单独的具有许可的IPC调用它，在执行那个调用的实现之前，通过调用checkCallingPermission()实现保护。

我们一般建议使用manifest中声明的许可，因为那些是不容易监管的

 

 

 

Using Activities

使用Activity

Activities are most often used for providing the core user-facing functionality of an application. 

By default, Activities are exported and invokable by other applications only if they have an intent filter or binder declared. 

In general, we recommend that you specifically declare a Receiver or Service to handle IPC, since this modular approach reduces the risk of exposing functionality that is not intended for use by other applications.

Activity是一个应用最经常被用来提供核心面向用户功能性

默认的，Activity只有在拥有一个intent过滤器或者binder声明时，是被导出的并且可被其他应用执行。

大体上说，我们建议你指定声明一个Receiver或者Service来处理IPC，因为这模块化方法减少不打算给其他应用使用的功能性暴露的风险

 

 

If you do expose an Activity for purposes of IPC, the android:permission attribute in the <activity> declaration in the application manifest can be used to restrict access to only those applications which have the stated permissions.

如果你为IPC暴露一个activity，在manifest里<activity>声明中的android:permission属性可以限制让只有声明了许可的那些应用访问。

 

 

 

Using Permissions

使用许可

Requesting Permissions

请求许可

We recommend minimizing the number of permissions requested by an application. 

Not having access to sensitive permissions reduces the risk of inadvertently misusing those permissions, can improve user adoption, and makes applications less attractive targets for attackers.

我们建议一个应用请求的许可数量最小化

不具有访问敏感的许可可以减少无意中滥用那些许可的风险，可以让用户更能接受，并且使得攻击者对应用减少兴趣

 

 

If it is possible to design your application in a way that does not require a permission, that is preferable. 

For example, rather than requesting access to device information to create an identifier, create a GUID for your application. (This specific example is also discussed in Handling User Data) 

Or, rather than using external storage, store data in your application directory.

如果你的应用有一种可以设计出不需要任何许可的方法，那最好

例如：与其请求访问设备信息来建立一个标识，不如建立一个GUID（这个例子也在Handling User Data中有讨论）

 

 

If a permission is not required, do not request it. 

This sounds simple, but there has been quite a bit of research into the frequency of over-requesting permissions. 

If you’re interested in the subject you might start with this research paper published by U.C. Berkeley: http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-48.pdf

如果一个许可是不必要的，那么就不要请求使用

这听上去很简单，但是已经有相当多的过渡请求许可频率的研究

如果你对此感兴趣，你也许可以从由U.C. Berkeley发布的研究论文http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-48.pdf开始

 

 

 

In addition to requesting permissions, your application can use permissions to protect IPC that is security sensitive and will be exposed to other applications -- such as a ContentProvider. 

In general, we recommend using access controls other than user confirmed permissions where possible since permissions can be confusing for users. 

For example, consider using the signature protection level on permissions for IPC communication between applications provided by a single developer.

除了请求许可之外，你的应用可以使用许可来保护安全敏感的IPC并且会暴露给其他应用 -- 比如ContentProvider

总的来说，我们建议使用访问控制而不是在可能的地方让用户确认许可，因为许可会是用户困惑

例如，考虑在许可上为应用间的IPC通信使用单一开发者提供的签名保护级别

 

 

Do not cause permission re-delegation. 

This occurs when an app exposes data over IPC that is only available because it has a specific permission, but does not require that permission of any clients of it’s IPC interface. 

More details on the potential impacts, and frequency of this type of problem is provided in this research paper published at USENIX: http://www.cs.be rkeley.edu/~afelt/felt_usenixsec2011.pdf

不要产生许可再次授权

只有当一个应用通过IPC暴露数据才会发生，因为它有一个指定的许可，但是并不要求它的IPC接口的任何客户端许可

潜在影响的更多细节，和这种问题发生的频率在USENIX: http://www.cs.be rkeley.edu/~afelt/felt_usenixsec2011.pdf研究论文中都有提供。

 

 

Creating Permissions

建立许可

Generally, you should strive to create as few permissions as possible while satisfying your security requirements. 

Creating a new permission is relatively uncommon for most applications, since system-defined permissions cover many situations. 

Where appropriate, perform access checks using existing permissions.

大体上说，你应该力求建立拥有尽量少许可的应用，直至满足你的安全需要

建立一个新的许可对于大多数应用是相对不常见，因为系统定义的许可覆盖很多情况

在适当的地方使用已经存在的许可执行访问检查

 

 

If you must create a new permission, consider whether you can accomplish your task with a Signature permission. 

Signature permissions are transparent to the user and only allow access by applications signed by the same developer as application performing the permission check. 

If you create a Dangerous permission, then the user needs to decide whether to install the application. 

This can be confusing for other developers, as well as for users.

如果你必须建立一个新的许可，考虑是否你能使用签名许可完成你的任务

签名许可对用户是透明的并且只允许相同开发者签名的应用访问同应用执行许可检查一样

如果你建立一个危险的许可，那么用户需要决定是否安装这个应用

这会使其他开发着困惑，也使用户困惑

 

 

If you create a Dangerous permission, there are a number of complexities that you need to consider.

如果你建立一个危险的许可，那么会有非常多的复杂情况需要你考虑

 

 

The permission must have a string that concisely expresses to a user the security decision they will be required to make.

The permission string must be localized to many different languages.

Uses may choose not to install an application because a permission is confusing or perceived as risky.

Applications may request the permission when the creator of the permission has not been installed.

Each of these poses a significant non-technical challenge for an application developer, which is why we discourage the use of Dangerous permission.

许可必须有一个字符串简短的表述给用户他们将要要求做出的安全策略

许可字符必须做很多语言的国际化

用户也许由于对一个许可风险的困惑或者知晓而选择不安装应用

上面每一个因素都都应用开发者提出一个重要的非技术的挑战，这也是我们劝阻使用危险许可的原因

 

 

 

 

原文地址如下，英文水平实在有限，希望拍砖同时能给予指正。

http://developer.android.com/guide/practices/security.html

 

 

 

转贴请保留以下链接

本人blog地址

http://su1216.iteye.com/

http://blog.csdn.net/su1216/