SELinux最初是由美国安全局NSA发起的项目，是基于强制访问控制(MAC)策略的，为每一个主体和客户都提供了个虚拟的安全“沙箱”，只允许进程操作安全策略中明确允许的文件。当Linux开启了SELinux安全策略，所有的主体对客户的访问必须同时满足传统的自主访问控制(DAC)和SELinux提供的强制访问控制(MAC)策略。
在虚拟化环境下，通常是多个VM运行在同一个宿主机（物理机）上，通常由同一个用户启动多个VM管理进程（如：qemu-kvm或者vmx等），而这些VM可能为不同的租户服务，如果其中一个VM由于某些脆弱性被恶意控制了，而hypervisor层有缺陷，攻击者就有机会利用被控制的VM发起对同宿主机或其它VM进行恶意攻击。如下图：宿主机中的SELinux安全策略阻止了VM的Attack行为。
SELinux与KVM
sVirt 项目集成SELinux强制访问控制 (MAC) 安全和基于 Linux 的KVM虚拟化。
确认SELinux策略正常开启
创建img文件
通过dd命令创建两个大小为20GB的img文件，作为虚拟机的磁盘：
dd if=/dev/zero of=/opt/vm/vm01.img bs=1M count=20480 dd if=/dev/zero of=/opt/vm/vm02.img bs=1M count=20480
查看img文件安全上下文
从上图可知两个img文件的安全上下文，其中用户域为unconfined_u，表示不限制用户；角色域为object_r通常表示普通文件或目录；类型域为usr_t；MCS为s0；
qemu-kvm命令配合VNC
/usr/libexec/qemu-kvm -cpu qemu64 \ -drive file=/opt/vm/vm01.img \ -m 2048 \ -cdrom \ /opt/CentOS-6.5-x86_64-bin-DVD1.iso \ -vnc :1 /usr/libexec/qemu-kvm \ -cpu qemu64 \ -drive file=/opt/vm/vm02.img \ -m 2048 \ -cdrom \ /opt/CentOS-6.5-x86_64-bin-DVD1.iso \ -vnc :2
给两个img文件安装上CentOS-6.5-x86_64操作系统并处于运行状态，此时的两个img文件的安全上下文还是与之前的保持不变。（注：实际在部署KVM虚拟机里以上步骤不是必须，这里是为了演示SELinux安全上下文的变化而考虑的）
virt-manager启动KVM虚拟机
结束qemu-kvm进程，用专用的virsh或virt-manager工具（这里以图形工具virt-manager为例）启动两个虚拟机，先ssh –X连接到宿主机，再执行virt-manager命令：
在弹出的窗口里“新建”一个虚拟机，输入名称，单选“Import existing disk image”根据向导创建并启动虚拟机：
当两个虚拟机都通过virt-manager启动之后管理窗口如下：
确认安全上下文变化
此时再看一下两个img文件的安全上下文，除了角色域object_r没有变化之外，用户域、类型域、MCS都发生了变化。
再确认一下对应进程的安全上下文：
可以看出img文件的MCS与进程的MCS是严格对应的，且对虚拟机进行重启操作时会自动给进程和img文件重新分配MCS。这种安全机制可以严格控制威胁的范围，提高云平台的安全性。
SELinux阻止非法访问
介绍一下MCS不同时阻止相互访问，将/bin/bash拷贝一个为/opt/test_sh，并查看一下当前的安全上下文：
由于在SELinux的默认安全策略里，使用svirt_t类型的入口程序必须类型为qemu_exec_t，这里修改一下test_sh的类型：
MCS为s0:c0,c1的操作
以特定的SELinux安全策略来运行，这里切换一下类型为svirt_t和MCS为s0:c0,c1，并查看当前用户的安全上下文以确认，之后通过echo命令向/tmp/test文件（由于SELinux安全策略限制，此时只能向/tmp目录下写新建文件）里随便写内容，写成功后再查看一下/tmp/test的安全上下文。MCS都是一致的。
MCS为s0:c0,c2的操作
再以特定的SELinux安全策略来运行，这里切换一下类型为svirt_t和MCS为s0:c0,c2，并查看当前用户的安全上下文以确认，之后通过echo命令向/tmp/test文件（这个文件是前一步创建的）里随便写内容，由于安全策略的限制会写入失败，提示：Permission denied（下图红线部分）。确认文件MCS与当前环境的MCS是不一致的。
来点感动自己的鸡汤
所有被SELinux安全策略阻止的操作都会有相应的日志记录，当系统auditd服务启动时会记录在audit.log日志，否则记录在message日志里。
