Android安全机制介绍

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

     • 进程沙箱隔离机制。
     • 应用程序签名机制。
     • 权限声明机制。
     • 访问控制机制。
     • 进程通信机制。
     • 内存管理机制。
     • SELinux

一、进程沙箱隔离机制

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



二、应用程序签名机制

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

    签名的过程:

       • 生成私有、公共密钥和公共密钥证书
       • 对应用进行签名
       • 优化应用程序

    签名的作用:

       • 识别代码的作者。
       • 检测应用程序是否发生了改变。
       • 在应用程序之间建立信任,以便于应用程序可以安全地共享代码和数据。

三、权限声明机制

        应用程序需要显式声明权限、名称、权限组与保护级别。不同的级别要求应用程序行使此权限时的认证方式不同:Normal级申请即可用;Dangerous级需在安装时由用户确认才可用;SignatureSignatureorsystem则必须是系统用户才可用。
• 通过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),具有最高的系统权限,UID0
    • 系统伪用户,Linux操作系统出于系统管理的需要,但又不愿赋予超级用户的权限,需要将某些关键系统应用
      文件所有权赋予某些系统伪用户,其UID范围为1499,系统的伪用户不能登录系统。

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

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

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

    第一组定义文件所有者(用户)的权限,第二组定义同组用户(GID相同但UID不同的用户)的权限,第三组定

    义其他用户的权限(GIDUID都不同的用户)。


五、进程通信机制

               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中主体通常指的是进程。
• 客体:客体通常是一些系统资源(如文件、目录、套接字、共享内存等)。
• 客体类型:一个客体类别代表某个确定类型(如文件或套接字)的所有资源。
• DACLinux基于用户识别的访问控制。
• 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入手区分问题的根源。



评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值