DTE Linux、SELinux与SEAndroid之间的对比分析

ARM 60浏览

2000年,美国威廉玛丽学院的研究人员Serge等人在USENIX的4th annual Linux Showcase &Conference会议上发表了题为“Domainand Type Enforcement for Linux”的文章。该文章第一次将DTE模型用于Linux,实现了DTE Linux原型系统。

同年,美国国家安全局NSA的Stephen Smalley等人发布了开源的Linux安全框架SELinux,SELinux第一个版本基于Linux 2.5内核,并采用GPL开源协议发布。在2003年8月,SELinux正式集成进Linux官方内核的2.6.0版本。

SELinux作为目前DTE在Linux上实现的业界标准,其理念绝大部分是与DTE Linux一致的,但是由于两个成果分属不同的研究团队,因此其具体机制仍稍有差别。由于目前介绍DTE的资料很多,因此本文从另外一个角度,主要介绍DTE Linux与SELinux的区别。同时,由于本人的研究方向是Android安全,SELinux在Android系统上也进行了实现,名为SEAndroid,因此本文会结合Android系统来阐述一个配置SELinux策略的具体案例。本文档主要包括以下两个部分:1)DTE Linux与SELinux的异同;2)SEAndroid策略配置案例。

第1章           DTE Linux与SELinux的异同

1.1           相同之处

DTE Linux和SELinux都实现了DTE模型,主要包括以下三类访问控制:

1)Type Access

2)Domain Access

3)Domain Transition

1.2           不同之处

1)策略文件存放模式不同

DTE Linux采用了集中式的策略文件方案,其策略文件存储路径为/etc/dte.conf;而SELinux采用了分散式的策略文件方案,其策略文件存储在/etc/selinux/文件夹下,包括policy.conf文件。我个人认为SELinux的方案更优,不同的策略文件更为模块化,方便了不同组织、公司针对自身负责的程序逻辑进行策略编写,最后通过策略编译,所有的SELinux策略文件被编译成一个完整的策略库,在内核可以高效运行,不会产生效率损失。

2)与传统DAC判断逻辑之间的顺序不同

DTE Linux在访问授权时,先判断DTE策略,再判断DAC策略;而SELinux相反,先判断DAC策略,再判断DTE策略。我个人认为SELinux的实现更好,这是考虑到DTE策略是以阻止恶意攻击为目的,只有在攻击出现时DTE策略才会执行拒绝,正常情况下的一个访问被DAC策略拒绝的可能性比被DTE策略拒绝的可能性高得多,因此从性能角度考虑,将DAC策略判断逻辑放在前面是合适的。

3)代码实现是否依靠LSM

LSM是Linux Secrity Module的简称,即Linux安全模块。其是一种轻量级通用访问控制框架,适合于多种访问控制模型在它上面以内核可加载模块的形实现。用户可以根据自己的需求选择合适的安全模块加载到内核上实现。LSM框架在2003年12月集成到Linux 2.6官方代码中。LSM目前支持包括AppArmor,SELinux, Smack and TOMOYO Linux等多种安全框架。(文章发表几年之后,DTE Linux也在Linux 2.6 LSM进行了实现)

DTE Linux文章是文章作者自己基于Linux 2.3版本实现的原型系统,时间较早,当时还没有LSM框架,因此所有的函数钩子、新增加的系统调用都是DTE for Linux原型系统自己完成的。

SELinux框架是在LSM基础上开发的。背后还有一段插曲:2001年Linux KernelSummit大会上NSA找到Linux创始人Linus希望将SELinux集成进Linux 2.5中,Linus当时拒绝了这一请求,这是由于当时除了SELinux之外还有其他的众多安全框架,Linux社区无法达成共识采用哪一个框架。因此Linus决定将安全框架做成“一个模块”,于是后来就有了LSM和基于LSM的SELinux。

4)支持的模型不同

相比DTE Linux文章中只涉及DTE模型而言,SELinux在实现DTE模型的同时,还实现了RBAC模型和MLS模型(可选)。

第2章           SEAndroid策略配置案例

SEAndroid全称Security Enhancements (SE) for Android™,是SELinux在Android操作系统上的一个实现。目前SEAndroid并不受限于SELinux的功能,已经开始研发专用于Android系统的新的安全特性。

最近我在从事Android安全加固方面研究,其中涉及到一个配置SELinux策略的真实的案例。需求是:在保证生产和维护人员充分权限的情况下,防止普通用户取得Root权限。我们这里主要说下如何保证生产和维护人员的充分权限,本质上就是实现“root命令调用路径”。

我们提出的方案是:

提供一个运行在root权限级别的Native级服务,提供命令执行接口供上层应用进行IBinder进程间调用,该Native级服务的调用需要提供安全秘钥,以保证只有该应用能够通过服务进行root命令的调用。同时该Native级服务具有一定的鲁棒性,当遇到以外关闭时,系统会自动重启该Native级服务。

本方案的一些功能,如网络访问控制,需要进行iptables规则配置,而iptables配置是需要用到root权限的。为了保证上层应用能够使用root权限,本方案需要设计专供上层应用使用的、足够安全的root权限调用路径。该方法主要依靠Native级服务实现。当上层应用在需要特殊权限时,会调用Native级服务,Native级服务在验证安全秘钥成功后,自行以root权限调用相关的命令,并向应用层返回结果。

目前我们这个方案是在Android5.1上实现的,Android5.1上默认开启了SELinux功能,并且其策略设置非常严格,我们的方案受到很多SELinux策略的拒绝而无法成功执行,因此需要修改SELinux策略,开一个“口子“,放行我们的Native级服务调用。

SELinux策略调整方案主要有两步:

1)添加标签:

1. 声明peki服务的type标签为pekiserver_service

51droidandroid-5.1.0_r3externalsepolicyservice_contexts

Line: 123添加:

peki                                     u:object_r:pekiserver_service:s0

 

2. 定义type标签pekiserver_service为service_manager_type的子标签

51droidandroid-5.1.0_r3externalsepolicyservice.te

Line: 13添加:

type pekiserver_service,        service_manager_type;

 

3. 声明pekiserver守护程序的type标签为pekiserver_exec

51droidandroid-5.1.0_r3externalsepolicyfile_contexts

Line: 166添加:

/system/bin/pekiserver    u:object_r:pekiserver_exec:s0

 

2)配置规则:

4. 添加TE策略文件pekiserver.te

51droidandroid-5.1.0_r3externalsepolicy

添加pekiserver.te文件

pekiserver.te文件内容如下:

# pekiserver - Peki service
type pekiserver, domain;
type pekiserver_exec, exec_type, file_type;

init_daemon_domain(pekiserver)
typeattribute pekiserver mlstrustedsubject;

net_domain(pekiserver)

# Perform Binder IPC to system server.
binder_use(pekiserver)
binder_call(pekiserver, system_server)
binder_call(pekiserver, appdomain)
binder_service(pekiserver)

# Add service
allow pekiserver pekiserver_service:service_manager add;

# Execute commands
allow pekiserver shell_exec:file { execute execute_no_trans read open};
allow pekiserver system_file:file { execute_no_trans };

# popen() failed to execute "iptables -L"
allow pekiserver self:rawip_socket { create getopt setopt };
allow pekiserver self:capability { net_raw net_admin};

# Read iptables configuration file: /data/pekisafe/ctx_current/iptables_cfg.txt
allow pekiserver system_data_file:file { open read };

经过SELinux策略调整后,Native级服务调用成功执行,如下图所示,可以在应用中正常显示出iptables防火墙规则。