操作系统安全机制(2)

Linux操作系统安全机制

先说明 Linux 更适合学习,Android也基于Linux.

进程和线程

  • 进程: 可执行文件的活动表现,如Android中Activity的生命周期.对于进程来讲,他有很多独立的空间,如堆和栈,所以进程是资源的最基本的分配单位.
  • 线程: CPU(核的调度单位),他可以让一个进程的任务在CPU下多管齐下,并发执行.所以线程是CPU的最小调度单位.

进程的地址空间边界

一个虚拟的地址空间,只有当程序运行的时候才会分配具体的物理空间。由此我们可以得知,程序的虚拟地址相对来说是固定的,而物理地址则随着每一次程序的运行而有所不同。

进程边界的安全围栏:Crash的不可延续性

Windiows: 也就是说当某一进程对OS的某块内存进行written,但是该内存快是only read的,这时改进程就会发生crash,但是他的crash不会影响到其他应用的进程,如chrome,360等应用不受其影响.这就是Crash的不可延续性.

Android: 常见的crash是 Force close
塞班: 诺基亚时代的手机,那时候的系统是没有进程边界的安全围栏的,在对物理内存地址空间这块都是映射同一块,也就是说只要当一个发生了crash,那么整个机子就会重启.那时对于那种crash是非常谨慎的,在测试这块是做最多的.

进程边界的安全围栏:全局数据和服务的不可访问性

存储在两个不同的块,提高了安全.
如A项目无法对B项目的私密信息进行访问,因为这两个项目的存储区是在两块不同的地址范围.

多用户和多用户边界

  1. 多用户的需求背景:资源匮乏,中央的统一管理,现实中还是其他有很多方面的原因而要用到多用户的操作系统。
  2. 多用户的边界:独立的工作目录,每个用户都有自己的独立空间,互不干扰;可操作或访问的资源,每个用户对某一种资源的权限是不一样的;可执行的操作,每个用户对某一个资源拥有的权限也是不一样的;UID和GID,用户名只是用来看的,Identifier才是系统层面的标识,而用户的行为就是一系列进程的行为,所以多用户的特性标识其实就是进程的UID和GID。

多用户的特性标识: UID 和 GID

我们先来了解下UID 和 GID.
- GID为GroupId,即组ID,用来标识用户组的唯一标识符
- UID为UserId,即用户ID,用来标识每个用户的唯一标示符,每个进程都会有一个UID.

扩展:
用户组:将同一类用户设置为同一个组,如可将所有的系统管理员设置为admin组,便于分配权限,将某些重要的文件设置为所有admin组用户可以读写,这样可以进行权限分配。
每个用户和用户组都有一个唯一的用户id.

Name 和ID 的映射

了解完UID 和 GID那他们是如何将这些ID和Name关联起来的呢.
Android中很多一些系统自带的app都有自己的UID,如
Android_filesystem_config.h文件的映射关系:
#define AID_ROOT 0
#define AID_SYSTEM 1000
#define AID_CAMERA 1006
#define AID_APP 10000
用户安装的app,如用户开启了很多app就会被分配到10001,10002…1000X下去

这些Name的String 都会被映射到一张表(android_id_info)里去,最后交给C/C++去调用.

Chmod和Chown命令介绍

对UID,GID和Name,ID 的映射了解后,那他们到底有什么用呢,跟安全有什么关系呢? 像在Linux 中可以说一切皆文件,一切皆资源,用户/群组在操作这些文件的时候,肯定也会涉及到文件的权限问题(r/w),我们是如何操作这些权限的,下面继续看 Chmod和Chown命令介绍.

Chmod用于修改文件权限

  • 文件的读取都是R/W/X,系统内部采用了3Bit表示这些读写状态,如R为最高位比特,置为0x04,W为中间比特,置位0X02,X为最低位比特,置位为0x01.
  • Sheel中表示时,位置使用相应R/W/X表示,没有置位使用-表示.
  • 操作文件面向群体的操作权限时,使用Chmod,可以直接使用数字,也可使用助记符:

    a:all
    u:owner user
    g:group
    +:add one permission
    -:remove one permission


如我们要修改根目录下的 test.txt文件权限:

ls-l
chmod 664 test.txt //对应 6-rw; 4-r
chmod u-w test.txt //对应 u-w表示用户组移除了 w权限

Chown用于修改文件的UID和GID

  • Sheel命令中通常采用Name方式修改,而不是ID修改,因为ID玩我们是看不到的.
  • 一般格式: chown newUID:newGID FileName
    如:根目录下有一个test.txt 它的UID和GID都是ROOT,这时如果我们要修改他的UID/GID,只能通过他的名字来更改.
chown system:system text.txt //修改了UID/GID, root -> system
//但是他的r/w/x权限是不变的

被ROOT了怎么办

  • 恶意程序获得了ROOT权限怎么办?
    如我们肯能只是想获取到ROOT权限,做A,B两件事情,但是如果有些恶意的程序因为你获取了ROOT后,他可以做一些A,B之外的事情,不是我们希望事情.
    那我们应该怎么办呢?

>
恶意应用获得了ROOT权限 — 现在我们是无能为力的.
我们想要做到的: 即便一个进程的EUID==ROOT权限,仍然不能为所欲为.

SELinux

  • DAC()模式:主体(EUID==ROOT)对它所属的对象和运行的程序拥有所有的控制权 – 可以做任何事
  • MAC()模式:SELinux基于的安全策略。管理员管理访问控制,管理员指定策略,用户不能改变它,任何主体不能改变 – 只能做安全策略授权的,不能为所欲为

举例,web服务器案例:

  • DAC模式下:web服务器进程具有root权限,当恶意病毒攻击成功并注入web服务器进程后,则可以利用web服务器进程的root权限,做任何事情.
  • MAC模式下:web服务器进程所能操作的对象和权限均在安全策略中明确列出,比如,只允许访问网络和访问特定文件等.即便web服务器被而已病毒攻击注入了,你仍然无法借由web服务器进程为所欲为,所有安全策略上没有授权的行为仍然是不允许的.

SEAndroid

  • 与SELinux的关系
    SEAndroid (Security-Enhanced Android)将原本运用在LinuxOS上的SELinux,移植到Android平台上.

  • 与SELinux的区别
    除了移植SELinux以外,google发布了那么多个版本,还做了很多针对于Android的安全提高,比如把Binder IPC,Socket,Properties访问控制加入到了SEAndroid的控制中.

  • SEAndroid的核心理念
    里边而已应用篡得了ROOT权限.
    但恶意应用仍然被有限的控制着而不能为所欲为.

JB MR2的一个漏洞弥补

  • JB(4.3) MR2的漏洞弥补
    在JB MR2之前,APK内部可以通过Java的Runtime执行一个具有Root-setUID的可执行文件而提升EffectiveUID 来进行一些特权操作,典型的就是Root包中的su就是这个原理

  • JB(4.3) MR2修补了这个漏洞
    每个apk进程在创建完后,都会执行如下这段代码,将CAPBSET全部清空.

    新进程的Effecttive(Capability Sets)为空,所以CAP_SETUID就没了,那么系统基于Root-setUID的可执行文件来提升EUID到ROOT当然就不允许了。所以新进程的EUID=RUID == APK的RUID.

相关内容推荐