Android安全机制介绍
阅读原文时间:2023年07月13日阅读:1

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

     • 进程沙箱隔离机制。

     • 应用程序签名机制。

     • 权限声明机制。

     • 訪问控制机制。

     • 进程通信机制。

     • 内存管理机制。

     • SELinux

一、进程沙箱隔离机制

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

二、应用程序签名机制

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

签名的过程:

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

       • 相应用进行签名

       • 优化应用程序

签名的作用:

       • 识别代码的作者。

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

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

三、权限声明机制

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

• 通过manifest文件里声明下面属性

请求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入手区分问题的根源。

手机扫一扫

移动阅读更方便

阿里云服务器
腾讯云服务器
七牛云服务器

你可能感兴趣的文章