操作系统安全机制(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项目的私密信息进行访问,因为这两个项目的存储区是在两块不同的地址范围.

多用户和多用户边界

多用户的需求背景：资源匮乏，中央的统一管理，现实中还是其他有很多方面的原因而要用到多用户的操作系统。

多用户的边界：独立的工作目录，每个用户都有自己的独立空间，互不干扰；可操作或访问的资源，每个用户对某一种资源的权限是不一样的；可执行的操作，每个用户对某一个资源拥有的权限也是不一样的；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.