Android安全机制介绍 _Android安全

行是知之始,知是行之成。这篇文章主要讲述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，具备清理不再使用共享内存区域的能力。
七、SELinuxSELinux 拥有三个主要的操作模式
? Disabled：禁用SELinux策略? Permissive：在Permissive模式下，SELinux会被启用但不会实施安全性策略，而仅仅会发出警告及记录行动。Permissive模式在排除SELinux的问题时非常实用? Enforcing：这个缺省模式会在系统上启用并实施SELinux的安全性策略。拒绝訪问及记录行动
SELinux 拥有三种訪问控制方法：
? 强制类型（TE）：TE是针对型策略所採用的主要訪问控制机制? 基于角色的訪问控制（RBAC）：它以SELinux用户（未必等同Linux用户）为基础。但缺省的针对型策略并未採用它? 多层保障（MLS）：未被採用，并且常常隐藏在缺省的针对型策略内。
SELinux策略文件：? android/external/sepolicy文件夹下
? wing-common/sepolicy自己定义策略

【Android安全机制介绍】SELinux默认宏：
? global_macros? mls_macros? te_macros
SELinux常见概念
? 主体：在SELinux中主体通常指的是进程。? 客体：客体一般是一些系统资源（如文件、文件夹、套接字、共享内存等）。? 客体类型：一个客体类别代表某个确定类型（如文件或套接字）的全部资源。

? DAC：Linux基于用户识别的訪问控制。

? MAC：主体对客体所採用的訪问类型，即强制訪问控制（TE）。

? 类型强制的安全上下文：訪问属性叫做安全上下文；一个安全上下文包含用户、角色和类型标识符。
? 域：因为历史原因，一个进程的类型通常被称为一个域或域类型。
我们觉得域、域类型、主体类型和进程类型
都是指相允许思。? 策略：由于SELinux默认不同意不论什么訪问，所以在SELinux中，通过allow语句对主体授权对客体的訪问权限。? 域转换
SELinux策略
Selinux策略语言眼下支持四类AV规则：
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模式，从分析失败操作对应的AVC Denied Msg入手区分问题的根源。