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策略语言目前支持四类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入手区分问题的根源。

1.为什么需要沙箱机制？

默认情况下，一个应用程序是可以访问机器上的所有资源的，比如CPU、内存、文件系统、网络等等。

但是这是不安全的，如果随意操作资源，有可能破坏其他应用程序正在使用的资源，或者造成数据泄漏。为了解决这个问题，一般有下面两种解决方案：

（1） 为程序分配一个限定权限的账号：利用操作系统的权限管理机制进行限制

（2） 为程序提供一个受限的运行环境：这就是沙箱机制
2.什么是沙箱机制？

如上所述，沙箱就是一个限制应用程序对系统资源的访问的运行环境。
沙箱很多情况下都是实现在虚拟机（VM）中，比如Java的虚拟机JVM、Javascript的虚拟机V8引擎、Android中的虚拟机Dalvik/ART，以及以太坊的虚拟机EVM等等。具体的实现方式各有不同，本文重点分析一下JVM和EVM的沙箱机制实现。
3.JVM的沙箱机制

JVM的沙箱机制大致可以分为三层：

什么是沙箱机制



第一层：类加载器

采用双亲委派模型，低层类加载器在收到类加载请求时，需要先委派给高层类加载器区完成，只有在高层类加载器无法完成该请求时，才会再重新委派给低层类加载器。通过这一机制，确保了系统的核心类不会被篡改，恶意代码无法访问关键资源。


第二层：字节码校验器

类字节码被加载后，需要在字节码层面进行检验，具体包括以下内容：

（1） 变量要在使用之前进行初始化

（2） 方法调用与对象引用类型之前要匹配

（3） 访问私有数据和方法的规则没有被违背

（4） 对本地变量的访问落在运行时堆栈内

（5） 运行时堆栈没有溢出通过这一机制，可以确保字节码符合Java语言规范，避免访问无效访问或越界访问。
第三层：安全管理器

这一层是交由应用开发者来维护的，开发者可以根据自身需求，制定对应的安全策略。默认的安全策略配置位于以下两个配置文件中：
· $JAVA_HOME/conf/security/java.security

· $JAVA_HOME/conf/security/java.policy
默认情况下安全管理器是不开启的，可以在命令行增加一个参数来开启它：

java -Djava.security.manager SandboxTest


默认的安全策略配置不允许应用程序对文件的读写操作，所以如果你试图写一个文件，运行时会报如下错误：

如果你希望开放这个权限，可以编写自己的安全策略文件，比如我们写一个my.policy：



然后在运行时指定这个策略配置就可以了：

java -Djava.security.manager -Djava.security.policy=。/my.policy SandboxTest

应用开发者可以针对不同的应用场景进行精细化定制，控制程序对网络、文件、属性等内容的访问权限。
4.EVM的沙箱机制

EVM本身是一个相对封闭的环境，不支持对网络和文件系统的直接访问，从这个层面来说已经起到一部分沙箱的功能了：

另外，在智能合约之间互相调用时，EVM会重新分配堆栈和内存空间，在一个全新的环境中运行新合约，即使出现问题也不会破坏原有执行环境，从而为智能合约的执行提供了一个沙箱环境。


最后，每个智能合约的存储也是相互独立的，开发者可以根据需求，限制合约可以访问的存储空间，避免未授权的访问或修改。举例来说，下图就描述了CALL和CALLCODE指令对存储空间访问的区别：

java安全沙箱机制介绍




组成Java沙箱的基本组件如下：

·类加载体系结构

·class文件检验器

·内置于Java虚拟机（及语言）的安全特性

·安全管理器及Java API

Java安全模型的前三个部分——类加载体系结构、class文件检验器、Java虚拟机（及语言）的安全特性一起达到一个共同的目的：保持Java虚拟 机的实例和它正在运行的应用程序的内部完整性，使得它们不被下载的恶意代码或有漏洞的代码侵犯。相反，这个安全模型的第四个组成部分是安全管理器，它主要 用于保护虚拟机的外部资源不被虚拟机内运行的恶意或有漏洞的代码侵犯。这个安全管理器是一个单独的对象，在运行的Java虚拟机中，它在对于外部资源的访 问控制起中枢作用。
类加载体系结构

类加载器要加载一个类，它首先检查此类是否已被加载，然后再委托双亲加载器加载此类，它的双亲加载器再委托它的双亲，这样一直委托到启动加载器，启动加载 器在从核心API查找此类，如果有就返回此类，否则就他的子加载器就查找此类，如果都没有就抛出ClassNotFound的异常。如下图所示：




 这种委托双亲的模式好处是：启动类加载器可以抢在标准扩展类装载器之前去装载类，而标准扩展类装载器可以抢在类路径加载器之前去装载那个类，类路径装载 器又可以抢在自定义类加载器之前去加载它。所以Java虚拟机先从最可信的Java核心API查找类型，这是为了防止不可靠的类扮演被信任的类，试想一 下，网络上有个名叫java.lang.Integer的类，它是某个黑客为了想混进java.lang包所起的名字，实际上里面含有恶意代码，但是这种 伎俩在双亲模式加载体系结构下是行不通的，因为网络类加载器在加载它的时候，它首先调用双亲类加载器，这样一直向上委托，直到启动类加载器，而启动类加载
 器在核心Java API里发现了这个名字的类，所以它就直接加载Java核心API的java.lang.Integer类，然后将这个类返回，所以自始自终网络上的 java.lang.Integer的类是不会被加载的。

但是如果这个移动代码不是去试图替换一个被信任的类（就是前面说的那种情况），而是想在一个被信任的包中插入一个全新的类型，情况会怎样呢？比如一个名为 java.lang.Virus的类，经过双亲委托模式，最终类装载器试图从网络上下载这个类，因为网络类装载器的双亲们都没有这个类（当然没有了，因为 是病毒嘛）。假设成功下载了这个类，那你肯定会想，Virus和lang下的其他类痛在java.lang包下，暗示这个类是Java API的一部分，那么是不是也拥有修改Java.lang包中数据的权限呢？答案当然不是，因为要取得访问和修改java.lang包中的权
 限，java.lang.Virus和java.lang下其他类必须是属于同一个运行时包的，什么是运行时包？运行时包是指由同一个类装载器装载的、属 于同一个包的、多个类型的集合。考虑一下，java.lang.Virus和java.lang其他类是同一个类装载器装载的吗？不是 的！java.lang.Virus是由网络类装载器装载的！

 

class文件校验器，通过四趟扫描，保证了class文件正确 
第一趟是，检查class文件的结构是否正确。比较典型的就是，检查class文件是否以魔数OxCAFEBABE打头。
通过这趟检查，可以过滤掉大部分可能损坏的，或者压根就不是class的文件，来冒充装载。
第二趟是，检查它是否符合java语言特性里的编译规则。比如发现一个类的超类不是Object，就抛出异常。
第三趟是，检查字节码是否能被JVM安全的执行，而不会导致JVM崩溃。这里提到了一个停机的问题。内容是这样的，“即不可能写出一个程序，用它来判定作为其输入而读入的某个程序，是否会停机”。意思是，不可能写一个程序，让它告诉你，另外一个程序会不会中断或崩溃。
第四趟是，符号引用验证。一个类文件，它会包含它引用的其他类的全名和描述符，并跟他们建立符号引用（一种虚拟的，非物理连接的方式）。当程序第一次执行到需要符号引用的位置时，jvm会检查这个符号链接的正确性，然后建立真正的物理引用(直接引用)。

 

内置于Java虚拟机（及语言）的安全特性 
这些都是基础的java语言特性，他们降低了java程序出现内存混乱，崩溃的几率。
·结构化内存访问（不使用指针，一定程度上让黑客无法篡改内存数据）
·自动垃圾收集
·数组边界检查
·空引用检查
·数据类型安全

 
安全管理器及Java API 
这是安全沙箱中，离我们程序员最接近的一环。
securityMananger，是一个api级别的，可自定义的安全策略管理器，它深入到java api中，在各处都可以见到它的身影。比如SecurityClassLoader。
默认情况下，java应用程序是不设置 securityManager 实例的(意味着不会起到安全检查)，这个实例需要我们在程序启动时通过 System.setSecurityManager 来设置。
一般情况下，检查权限是，通过 SecurityManager.checkPermission(Permission perm) 来完成的。外部程序通过，创建Permission实例，传递给前面的check。
Permission是一个抽象类，需要继承它实现不同的权限验证，比如 FilePermission，代表对某个文件的读写权限。
new FilePermission("test.txt", "read")

白名单（white list）是BLE协议中最简单、直白的一种安全机制。其原理很简单，总结如下（前面的分析文章中都有介绍）：
所谓的白名单，就是一组蓝牙地址；通过白名单，可以只允许特定的蓝牙设备（白名单中列出的）扫描（Scan）、连接（connect）我们，也可以只扫描、连接特定的蓝牙设备（白名单中列出的）。
例如，如果某个BLE设备，只需要被受信任的某几个设备扫描、连接，我们就可以把这些受信任设备的蓝牙地址加入到该设备的白名单中，这样就可以有效避免其它“流氓设备”的骚扰了。


从设备程序中 ble_advertising.h 中涉及到白名单的有两个函数。如下：
1、设置白名单

2、取消白名单广播，可以被任意主设备扫描、连接。初次广播时记录广播模式，所以取消白名单重新广播也是这个广播模式。













dm基础上修改。 
未添加白名单管理：
每次新设备连接都触发配对请求（手机弹窗：蓝牙配对请求），即使是大于最大绑定数量(DEVICE_MANAGER_MAX_BONDS)也触发，只是超出部分的加密信息不保存而已，但是配对还是成功的。这种情况就是已保存的设备再次连接是不会再触发配对请求。


添加白名单管理后：
添加白名单后 大于最大绑定数量(DEVICE_MANAGER_MAX_BONDS)就不能再连接(手机弹窗：配对不成功),然后就断开连接。就是只有已绑定成功的
设备才能连接，其他的设备都不能连接。所以其他设备要绑定 就先要擦除ps内的信息。


1、配置白名单数量，最好是和 (DEVICE_MANAGER_MAX_BONDS) 一样。


2、使能白名单功能。


options.ble_adv_whitelist_enabled = BLE_ADV_WHITELIST_ENABLED;



3、白名单请求处理


        case BLE_ADV_EVT_WHITELIST_REQUEST:
        {
            ble_gap_whitelist_t whitelist;
            ble_gap_addr_t    * p_whitelist_addr[BLE_GAP_WHITELIST_ADDR_MAX_COUNT];
            ble_gap_irk_t     * p_whitelist_irk[BLE_GAP_WHITELIST_IRK_MAX_COUNT];


            whitelist.addr_count = BLE_GAP_WHITELIST_ADDR_MAX_COUNT;
            whitelist.irk_count  = BLE_GAP_WHITELIST_IRK_MAX_COUNT;
            whitelist.pp_addrs   = p_whitelist_addr;
            whitelist.pp_irks    = p_whitelist_irk;


            err_code = dm_whitelist_create(&m_app_handle, &whitelist);
            APP_ERROR_CHECK(err_code);


            err_code = ble_advertising_whitelist_reply(&whitelist);
            APP_ERROR_CHECK(err_code);
            break;
        }