标签：安全 android 学术 访问控制 security
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策略配置案例。
DTE Linux和SELinux都实现了DTE模型，主要包括以下三类访问控制：
1）Type Access
2）Domain Access
3）Domain Transition
DTE Linux采用了集中式的策略文件方案，其策略文件存储路径为/etc/dte.conf；而SELinux采用了分散式的策略文件方案，其策略文件存储在/etc/selinux/文件夹下，包括policy.conf文件。我个人认为SELinux的方案更优，不同的策略文件更为模块化，方便了不同组织、公司针对自身负责的程序逻辑进行策略编写，最后通过策略编译，所有的SELinux策略文件被编译成一个完整的策略库，在内核可以高效运行，不会产生效率损失。
DTE Linux在访问授权时，先判断DTE策略，再判断DAC策略；而SELinux相反，先判断DAC策略，再判断DTE策略。我个人认为SELinux的实现更好，这是考虑到DTE策略是以阻止恶意攻击为目的，只有在攻击出现时DTE策略才会执行拒绝，正常情况下的一个访问被DAC策略拒绝的可能性比被DTE策略拒绝的可能性高得多，因此从性能角度考虑，将DAC策略判断逻辑放在前面是合适的。
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。
相比DTE Linux文章中只涉及DTE模型而言，SELinux在实现DTE模型的同时，还实现了RBAC模型和MLS模型（可选）。
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级服务调用。
\51droid\android-5.1.0_r3\external\sepolicy\service_contexts
Line: 123添加：
peki u:object_r:pekiserver_service:s0
\51droid\android-5.1.0_r3\external\sepolicy\service.te
Line: 13添加：
type pekiserver_service, service_manager_type;
\51droid\android-5.1.0_r3\external\sepolicy\file_contexts
Line: 166添加：
/system/bin/pekiserver u:object_r:pekiserver_exec:s0
\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防火墙规则。
DTE Linux、SELinux与SEAndroid之间的对比分析
标签：安全 android 学术 访问控制 security
原文地址：http://blog.csdn.net/hsluoyc/article/details/45534619
