DTE Linux、SELinux与SEAndroid之间的对比分析
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
\51droid\android-5.1.0_r3\external\sepolicy\service_contexts
Line: 123添加:
peki u:object_r:pekiserver_service:s0
2. 定义type标签pekiserver_service为service_manager_type的子标签
\51droid\android-5.1.0_r3\external\sepolicy\service.te
Line: 13添加:
type pekiserver_service, service_manager_type;
3. 声明pekiserver守护程序的type标签为pekiserver_exec
\51droid\android-5.1.0_r3\external\sepolicy\file_contexts
Line: 166添加:
/system/bin/pekiserver u:object_r:pekiserver_exec:s0
2)配置规则:
4. 添加TE策略文件pekiserver.te
\51droid\android-5.1.0_r3\external\sepolicy\
添加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防火墙规则。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。