Android安全机制介绍

Android的安全机制包括以下几个方面：

• 进程沙箱隔离机制。

• 应用程序签名机制。

• 权限声明机制。

• 访问控制机制。

• 进程通信机制。

• 内存管理机制。

• SELinux

一、进程沙箱隔离机制

Android应用程序在安装时被赋予独特的用户标识（UID），并永久保持；应用程序及其运行的Dalvik虚拟机运行于独立的Linux进程空间，与UID不同的应用程序完全隔离。





二、应用程序签名机制

应用程序包（.apk文件）必须被开发者数字签名；同一开发者可指定不同的应用程序共享UID，进而运行于同一进程空间，共享资源。

签名的过程：

• 生成私有、公共密钥和公共密钥证书

• 对应用进行签名

• 优化应用程序

签名的作用：

• 识别代码的作者。

• 检测应用程序是否发生了改变。

• 在应用程序之间建立信任，以便于应用程序可以安全地共享代码和数据。

三、权限声明机制

应用程序需要显式声明权限、名称、权限组与保护级别。不同的级别要求应用程序行使此权限时的认证方式不同：Normal级申请即可用；Dangerous级需在安装时由用户确认才可用；Signature与Signatureorsystem则必须是系统用户才可用。

• 通过manifest文件中声明以下属性

<uses-permissionandroid:name="string" />

请求android:name对应的权限。

• 通过以下属性添加自定义权限

<permission

xmlns:android="http://schemas.android.com/apk/res/android"

android:name="com.test.android.ACCESS_FRIENDS_LIST"

android:description="@string/permission_description"

android:label="@string/permission_label"

android:protectionLevel="normal" />

• 系统组件权限，如activity组件

<activity

android:permission="com.test.android.ACCESS_FRIENDS_LIST"

四、访问控制机制

传统的 Linux访问控制机制确保系统文件与用户数据不受非法访问。

Linux用户与权限

• 超级用户（root），具有最高的系统权限，UID为
0。

• 系统伪用户，Linux操作系统出于系统管理的需要，但又不愿赋予超级用户的权限，需要将某些关键系统应用

文件所有权赋予某些系统伪用户，其UID范围为1
～ 499，系统的伪用户不能登录系统。


• 普通用户，只具备有限的访问权限，UID 为
500 ～ 6000，可以登录系统获得
shell

在Linux权限模型下，每个文件属于一个用户和一个组，由UID与GID
标识其所有权。针对于文件的具体访问权限

定义为可读(r)、可写(w)与可执行(x)，并由三组读、写、执行组成的权限三元组来描述相关权限。

第一组定义文件所有者（用户）的权限，第二组定义同组用户（GID
相同但UID
不同的用户）的权限，第三组定

义其他用户的权限（GID与UID
都不同的用户）。

五、进程通信机制

Binder
进程通信机制提供基于共享内存的高效进程通信；Binder基于Client-Server模式，提供类似COM

与CORBA的轻量级远程进程调用（RPC）；通过接口描述语言（AIDL）定义接口与交换数据的类型，确保进程

间通信的数据不会溢出越界，污染进程空间。



六、内存管理机制

基于标准
Linux的低内存管理机制（OOM），设计实现了独特的低内存清理（LMK）机制，将进程按重要性分级、分组，当内存不足时，自动清理最低级别进程所占用的内存空间；同时，引入不同于传统Linux共享内存机制的Android共享内存机制Ashmem，具备清理不再使用共享内存区域的能力。

七、SELinux

SELinux 拥有三个基本的操作模式

• Disabled：禁用SELinux策略

• Permissive：在Permissive
模式下，SELinux会被启用但不会实施安全性策略，而只会发出警告及记录行

动。Permissive模式在排除
SELinux的问题时很有用

• Enforcing：这个缺省模式会在系统上启用并实施SELinux
的安全性策略，拒绝访问及记录行动

SELinux 拥有三种访问控制方法：

• 强制类型（TE）：TE是针对型策略所采用的主要访问控制机制

• 基于角色的访问控制（RBAC）：它以SELinux用户（未必等同Linux用户）为基础，但缺省的针对型策略并未

采用它

• 多层保障（MLS）：未被采用，而且经常隐藏在缺省的针对型策略内。

SELinux策略文件：

• android/external/sepolicy目录下

• wing-common/sepolicy自定义策略

SELinux默认宏：

• global_macros

• mls_macros

• te_macros

SELinux常见概念

• 主体：在SELinux中主体通常指的是进程。

• 客体：客体通常是一些系统资源（如文件、目录、套接字、共享内存等）。

• 客体类型：一个客体类别代表某个确定类型（如文件或套接字）的所有资源。

• DAC：Linux基于用户识别的访问控制。

• MAC：主体对客体所采用的访问类型，即强制访问控制（TE）。

• 类型强制的安全上下文：访问属性叫做安全上下文；一个安全上下文包括用户、角色和类型标识符。

• 域：由于历史原因，一个进程的类型通常被称为一个域或域类型。我们认为域、域类型、主体类型和进程类型

都是指相同意思。

• 策略：因为SELinux默认不允许任何访问，所以在SELinux中，通过allow语句对主体授权对客体的访问权限。

• 域转换

SELinux策略

Selinux策略语言目前支持四类***规则：

allow，dontaudit，auditallow，neverallow规则由四部分组成

• 源类型（SourceType），通常是尝试访问进程的域类型。

• 目标类型（TargetType），被进程访问的客体的类型。

• 客体类别（ObjectClass），允许访问的客体类型（如file，dir，socket等）。

• 许可（Permission）象征目标允许源类型访问客体类型的访问种类。

• 如allowdev_type tmpfs:filesystem associate;

SELinux域转换

• 域转换发生条件

• 进程的新域类型对可执行文件类型有entrypoint访问权限

• 进程的域类型对入口文件类型有execute访问权限

• 进程当前的域类型对新的域类型有transition访问权限

SELinux属性

attribute概念可以被理解为“具有一组共性的type集合”，或者“这组type所具有的共性”。语法如下：

attribute attribute_name;

比如定义一个名为”file_type”的属性：

attribute file_type;

在定义某个type时建立它与某个attribute的关联，比如：

type shadow_t,file_type;

使用attribute可以有效地减少类似规则的数目，比如为了让domain==backup_t能够读取文件系统中的所有文

件，则理论上必须为所有可能存在的文件type定义相应的allow规则：

type backup_t;

allow backup_t shadow_t:file read;

allow backup_t var_t:file read;

可以通过attribute来有效解决这个问题，

allow backup_t file_type:file read;

SELinux角色

SELinux通过SC中的role实现了“基于角色的访问控制”(RBAC－Role Based Access Control)。在SELinux中，
并不直接建立用户和type之间的联系，而是通过角色作为桥梁。
user u roles { r }

role r types domain;

SELinux访问控制

• ls -Z 显示文件系统客体的安全上下文

• Ps -Z 显示进程的安全上下文

• 显示「用户：角色：类型：安全级别」

SELinux问题分析

当SELinux处于enforcing模式下时某些程序的执行会失败，在这里总结此类问题的总体分析方法。

• 首先排除DAC权限的问题，使用“ls –l”检查相关文件的属主和权限。如果DAC的权限许可，则就是SELinux的策略显式地拒绝了当前操作的执行。

• 然后检查用户当前所扮演的角色，某些操作只有特定的角色才有足够的权限执行。

• 进入permissive模式，从分析失败操作相应的***C Denied Msg入手区分问题的根源。