目录
1. 学习Rootkit需要了解的基础知识 2. 挂钩(HOOKING) 3. 直接内核对象操作 4. LSM框架(Linux Security Module)于LKM安全 5. rootkit检测技术及工具
1. 学习Rootkit需要了解的基础知识
0x1: 什么是rootkit
rootkit是允许某人控制操作系统的特定方面而不暴露他或她的踪迹的一组代码。从根本上说来，用户无法察觉这种特性构成了rootkit。rootkit会想尽办法去隐藏自己的网络、进程、I/O等信息(注意，这里所谓的隐藏，只是针对ring3的ui隐藏，内核层的功能不能隐藏，否则rootkit自己也无法使用功能了)，所以，rootkit的攻防问题很大程度上是一个ring0争夺战的问题，监控程序必须直接深入到系统的底层去获取最原始的数据，才能避免因为rootkit的ring3隐藏导致的误判
0x2: 可装载内核模块(LKM)
Linux就是通常所说的单内核(monolithic kernel)，它与微型内核(windows系统中常见)不同
1. Linux中的单内核 操作系统的大部分功能都被称为内核，并在特权模式下运行。同时，linux也提供动态扩充系统功能的机制(可以将新的功能加载到内核、从内核去除某个功能)，通过Linux内核模块(LKM)可以在运行时动态地更改Linux的内核，以达到动态扩充和裁剪的目的，这样可以最小化内核的内存占用 2. 微型内核 只把基本的功能(进程间通信[IPC]、调度、基本的输入/输出[I/O]和内存管理)当作内核运行，而把其他功能(驱动程序、网络堆栈和文件系统)排除在特权空间之外
LKM与直接编译到内核或典型程序的元素有根本区别
1. 典型的程序有一个main函数 2. LKM包含entry和exit函数(这里所谓的entry、exit只是一个称号，我们可以任意命名这些函数，只要通过module_init、module_exit宏进行明确声明)。当向内核插入模块时，调用module_init声明的函数，从内核删除模块时则调用module_exit声明的函数。LKM还包含一组必要的宏和一组可选的宏，用于定义模块的许可证、模块的作者、模块的描述等等
2.6及以上的本的Linux内核提供了更简单的bash命令用于构建LKM
1. insmod: 安装LKM 2. rmmod: 删除LKM 3. modprobe: insmod和rmmod的包装器 4. depmod: 用于创建模块依赖项 5. modinfo: 用于为模块宏查找值
Relevant Link:
http://www.ibm.com/developerworks/cn/linux/l-lkm/ BSD ROOTKIT 设计.pdf 第一章
0x3: ELF文件格式
关于ELF文件格式的内容请参阅另一篇文章：
http://www.cnblogs.com/LittleHann/p/3871092.html
0x4: 系统调用
关于系统调用的基本原理和内核代码，请参阅另外的文章
http://www.cnblogs.com/LittleHann/p/3871630.html http://www.cnblogs.com/LittleHann/p/3850653.html
0x5: rootkit技术种类
1. 应用级rootkit
通过替换login、ps、ls、netstat等系统工具，或修改.rhosts等系统配置文件等实现隐藏及后门
2. 内核级rootkit
2.1 挂钩hook技术
1) 系统调用hook
2) 函数api hook
2.2 直接内核对象操作
主要是指在系统不支持lkm机制时修改内核的一种方法，主要通过/dev/mem、/dev/kmem设备直接操作内存，从而对内核进行修改
3. 硬件级rootkit
主要指bios rootkit，可以在系统加载前获得控制权，通过向磁盘中写入文件，再由引导程序加载该文件重新获得控制权，也可以采用虚拟机技术，使整个操作系统运行在rootkit掌握之中
http://www.rootkitanalytics.com/firmware/hypervisor.php
http://www.rootkitanalytics.com/kernelland/linux-kernel-rootkit.php
0x6: rootkit的目的
1. 隐藏文件
通过strace ls可以发现ls命令其实是通过sys_getdents64获得文件目录的，因此可以通过修改sys_getdents64系统调用或者更底层的readdir实现隐藏文件及目录
2. 隐藏进程
隐藏进程的方法和隐藏文件类似，ps命令是通过读取/proc文件系统下的进程目录获得进程信息的，只要能够隐藏/proc文件系统下的进程目录就可以达到隐藏进程的效果，即hook sys_getdents64和readdir等。
3. 隐藏连接
netstat命令是通过读取/proc文件系统下的net/tcp和net/udp文件获得当前连接信息，因此可以通过hook sys_read调用实现隐藏连接，也可以修改tcp4_seq_show和udp4_seq_show等函数实现。
4. 隐藏模块
lsmod命令主要是通过sys_query_module系统调用获得模块信息，可以通过hook sys_query_module系统调用隐藏模块，也可以通过将模块从内核模块链表中摘除从而达到隐藏效果
5. 嗅探工具
1) 嗅探工具可以通过libpcap库直接访问链路层，截获数据包
2) 也可以通过linux的netfilter框架在IP层的hook点上截获数据包
嗅探器要获得网络上的其他数据包需要将网卡设置为混杂模式，这是通过ioctl系统调用的SIOCSIFFLAGS命令实现的，查看网卡的当前模式是通过SIOCGIFFLAGS命令，因此可以通过hook sys_ioctl隐藏网卡的混杂模式
6. 密码记录
密码记录可以通过hook sys_read系统调用实现，比如通过判断当前运行的进程名或者当前终端是否关闭回显，可以获取用户的输入密码。hook sys_read还可以实现login后门等其它功能
7. 日志擦除
传统的unix日志主要在
1) /var/log/messages
2) /var/log/lastlog
3) /var/run/utmp
4) /var
5) /log/wtmp下
可以通过编写相应的工具对日志文件进行修改，还可以将HISTFILE等环境变设为/dev/null隐藏用户的一些操作信息
8. 内核后门
1) 本地的提权后门
本地的提权可以通过对内核模块发送定制命令实现
2) 网络的监听后门
网络内核后门可以在IP层对进入主机的数据包进行监听，发现匹配的指定数据包后立刻启动回连进程 http://www.freebuf.com/articles/web/19798.htm
Relevant Link:
http://la-samhna.de/library/rootkits/list.html http://wenku.baidu.com/view/70ee7a29647d27284b735161.html http://www.rootkitanalytics.com/
2. 挂钩(HOOKING)
挂钩是一种使用处理程序(叫做挂钩)来修改控制流的编程技术。新的挂钩把它的地址注册为特定函数的地址，这样当那个函数被调用时，挂钩程序就代替它运行。一般，挂钩还会调用原先的函数，目的是维为了持原来的行为
可以看出，挂钩可用来扩展(或削弱)一个子程序的功能。挂钩可按照rootkit的设计目的来修改操作系统的应用程序编程接口(API)的运行效果(有点类似设计模式中的装饰器设计模式)
0x1: 系统调用挂钩(Hooking a System Call)
系统调用是一种入口点，应用程序通过它向操作系统请求服务。通过挂住这些入口点，rootkit就能改变内核返回给某个或所有用户空间进程的数据。实际上，系统调用挂钩非常地有效，以至被大多数(可公开获取到的)rootkit在某种程度上都使用到了系统调用hook技术
从目前的情况看来，不论是对于尝试编写rootkit的攻击者、还是如要进行入侵检测防御的安全研究员来说，它们都会解除到的系统调用挂钩(Common System Call Hooks)大致有如下
1. read, readv, pread, preadv
1) 监控: 通过监控系统的读取流，达到恶意文件、webshell内容检测
2) rootkit: 劫持系统的输入记录，达到以隐蔽方式获取敏感数据
2. write, writev, pwrite, pwritev
1) 监控: 监控系统的输出，以达到debug的目的
2) rootkit: 劫持并修改系统的输出记录，或者隐藏恶意程序行为的目的
3. open
1) 监控: 通过监控磁盘的I/O(open)记录，可以发现rootkit、webshell的产生
2) rootkit: 隐藏文件内容，使普通ring3程序无法发现rootkit文件本身
4. 关键文件/目录保护
4.1 unlink: 禁止删除文件
4.2 chdir: 禁止切换目录
4.3 chmod: 禁止修改文件属性
4.4 chown: 禁止修改所有者
4.5 rename: 禁止重命名文件
4.6 rmdir: 禁止删除目录
4.7 stat, lstat: 隐藏文件状态
4.8 getdirentries: 隐藏文件
4.9 truncate: 禁止文件截短或扩展
5. kill
禁止信号传递
6. ioctl
操作ioctl请求
7. execve
重定向文件的执行
8. LKM监控/保护
8.1 kldload: 禁止加载模块
8.2 kldunload: 禁止卸载模块
关于系统调用hook的姿势，请参阅另一篇文章
http://www.cnblogs.com/LittleHann/p/3854977.html
对于系统调用挂钩，这里有几点核心的概念需要我们牢记
1. 系统调用挂钩实际上是改变函数指针，而修改这个函数指针的过程我们可以简单概括为:
1) 找到这个函数指针的原始位置
1.1) 通过系统提供的API
1.2) 寄存器直接获得基址，在内核数据结构偏移的基础上进行直接内存定位
2) 保存原始函数指针的地址
3) 通过C语言的指针操作指令进行赋值修改函数指针地址
4) 完成系统调用hook
2. 要为了完成一个特定的任务，通常存在一些不同的入口点可供你挂钩，在整个系统调用的流程中的任何点理论上都可以进行劫持hook
例如: 通过挂钩read系统调用编写了一个击键记录程序；但是，这个任务还可以通过挂钩终端线路规则(termios)转换表中的l_read 入口点来完成
3. 直接内核对象操作
所有的操作系统(linux、windows)都会把内核中的运行状态(包括进程信息、系统内核状态)这些数据以对象的形式保存下来，包括:
1. 结构体 2. 队列 3. 数组
这些内核状态信息往往保存在内核空间的某个地址段中，当我们通过系统向内核查询这些"内核状态信息"(运行进程的列表、开放的端口等)时，这些数据就被解析并返回。
因为这些数据是保存在内存中的，所以可以直接去操作它们，我们没有必要安装一个调用挂钩来改变控制流。这个技术通常叫做"直接内核对象操作(DKOM)"
0x1: 内核队列数据结构(Kernel Queue Data Structures)
关于linux内核中的队列数据结构的相关知识，请参阅另一篇文章
http://www.cnblogs.com/LittleHann/p/3865490.html
0x2: 隐藏运行进程(Hiding a Running Process)
现在，我们已经linux在内核中是通过链表将各个进程串联起来，也掌握了如何操作这些链表的的"操作宏"。接下来可以继续学习一下如何通过直接修改这些"内核队列结构"来实现改变系统状态的，需要明白的是，不论是在linux还是在windows，所谓的系统状态就是内核中的一个个数据结构、链表共同组成的，我们平时使用API、系统调用去get()、set()各种状态，本质上就是在读写这些内核中的变量，所以，对内核变量进行直接定位并修改是改变linux内核状态的一个最好的思路
现在，我们已经linux在内核中是通过链表将各个进程串联起来，也掌握了如何操作这些链表的的"操作宏"。接下来可以继续学习一下如何通过直接修改这些"内核队列结构"来实现改变系统状态的，需要明白的是，不论是在linux还是在windows，所谓的系统状态就是内核中的一个个数据结构、链表共同组成的，我们平时使用API、系统调用去get()、set()各种状态，本质上就是在读写这些内核中的变量，所以，对内核变量进行直接定位并修改是改变linux内核状态的一个最好的思路
按照这个思想，我们可以直接去操作linux系统中表示进程的链表，断开其中某个元素后，系统在遍历这个链表的时候找不到指定元素，这个进程就被我们"隐藏"了
1. The LINUX kernel contains an array of task_struct’s. 2. A task_struct is similar to an EPROCESS block in Windows 3. task_struct contains pointers to the prev_task and next_task 4. task_struct also contains pointers to the prev_run and next_run for the running processes 5. To hide a process, remove the process from the list of prev_task and next_task and Leave next_run and prev_run alone
简单来说，这就是windows驱动hacking中常说的"断链法"
这里，我们需要对系统内核进程隐藏的攻防进行一下理解梳理
1. 对于黑客来说，隐藏进程可以通过将某个上层rin3会用到的内核链表(内核状态变量)进行断链，以实现隐藏的目的 2. 而对于安全研究员防守方来说，要对抗这种攻击，就必须在内核中的其他地方找到另一个同样可以表示进程列表的数据结构，以此来再次绕过黑客的隐藏攻击 3. 那这个攻防过程能不能无限的进行下去呢？答案是否定的！黑客在使用"断链法"进行进程隐藏的时候，不能去破坏CPU调度所使用到的链表(这是最低的底线)，如果把CPU的调度所依赖的链表都断开了，隐藏进程的目的是达到了，可是这个进程也废了，因为它失去了被调度的能力
回到我们文章的例子上来看，task_struct链表就是CPU调度的依赖，我们如果对这个链表进行断链，则CPU自然也不会去调度这个进程了，为了解决这个问题，我们需要给内核打上hot-patch
hp.c
#define __KERNEL__
#define MODULE
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/sched.h>
pid_t pid = 0 ;
struct task_struct *task = 0 ;
unsigned char method = 0x3 ;
int init_module ( ) {
if ( pid ) {
task = find_task_by_pid(pid) ;
printk ( "[HP] address of task struct for pid %i is 0x%p\n" , pid , task ) ;
if ( task ) {
write_lock_irq(&tasklist_lock) ;
if ( method & 0x1 ) {
printk("[HP] removing process links\n") ;
REMOVE_LINKS(task) ;
}
if ( method & 0x2 ) {
printk("[HP] unhashing pid\n") ;
unhash_pid(task) ;
}
if ( method & 0x4 ) {
printk("[HP] zerofing pid\n") ;
task->pid == 0 ;
}
write_unlock_irq(&tasklist_lock) ;
}
} else if ( task ) {
printk ( "[HP] unhideing task at addr 0x%x\n" , task ) ;
write_lock_irq(&tasklist_lock) ;
if ( method & 0x1 ) {
printk("[HP] setting process links\n") ;
SET_LINKS(task) ;
}
if ( method & 0x2 ) {
printk("[HP] hashing pid\n") ;
hash_pid(task) ;
}
if ( method & 0x4 ) {
printk ( "[HP] reverting 0 pid to %i\n" , task->tgid ) ;
task->pid = task->tgid ;
}
write_unlock_irq(&tasklist_lock) ;
}
return 1 ;
}
MODULE_PARM ( pid , "i" ) ;
MODULE_PARM_DESC ( pid , "the pid to hide" ) ;
MODULE_PARM ( task , "l" ) ;
MODULE_PARM_DESC ( task , "the address of the task struct to unhide" ) ;
MODULE_PARM ( method , "b" ) ;
MODULE_PARM_DESC ( method , "a bitwise OR of the method to use , 0x1 - linked list , 0x2 - pidhash , 0x4 - zerofy pid" ) ;
MODULE_AUTHOR("ubra @ PHI Group") ;
MODULE_DESCRIPTION("hp - hide pid v1.0.0 - hides a task with 3 possible methods") ;
MODULE_LICENSE("GPL") ;
EXPORT_NO_SYMBOLS ;
sht.c
#define __KERNEL__
#define MODULE
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
struct idta {
unsigned short size ;
unsigned long addr __attribute__((packed)) ;
} ;
struct idt {
unsigned short offl ;
unsigned short seg ;
unsigned char pad ;
unsigned char flags ;
unsigned short offh ;
} ;
unsigned long get_idt_addr ( void ) {
struct idta idta ;
asm ( "sidt %0" : "=m" (idta) ) ;
return idta.addr ;
}
unsigned long get_int_addr ( unsigned int intp ) {
struct idt idt ;
unsigned long idt_addr ;
idt_addr = get_idt_addr() ;
idt = *((struct idt *) idt_addr + intp) ;
return idt.offh << 16 | idt.offl ;
}
void hook_int ( unsigned int intp , unsigned long new_func , unsigned long *old_func ) {
struct idt idt ;
unsigned long idt_addr ;
if ( old_func )
*old_func = get_int_addr(intp) ;
idt_addr = get_idt_addr() ;
idt = *((struct idt *) idt_addr + intp) ;
idt.offh = (unsigned short) (new_func >> 16 & 0xFFFF) ;
idt.offl = (unsigned short) (new_func & 0xFFFF) ;
*((struct idt *) idt_addr + intp) = idt ;
return ;
}
asmlinkage void check_task ( struct pt_regs *regs , struct task_struct *task ) ;
asmlinkage void stub_func ( void ) ;
unsigned long new_handler = (unsigned long) &check_task ;
unsigned long old_handler ;
void stub_handler ( void ) {
asm(".globl stub_func \n"
".align 4,0x90 \n"
"stub_func : \n"
" pushal \n"
" pushl %%eax \n"
" movl $-8192 , %%eax \n"
" andl %%esp , %%eax \n"
" pushl %%eax \n"
" movl -4(%%esp) , %%eax \n"
" pushl %%esp \n"
" call *%0 \n"
" addl $12 , %%esp \n"
" popal \n"
" jmp *%1 \n"
:: "m" (new_handler) , "m" (old_handler) ) ;
}
asmlinkage void check_task ( struct pt_regs *regs , struct task_struct *task ) {
struct task_struct *task_p = &init_task ;
unsigned char on_ll = 0 , on_ph = 0 ;
if ( ! task->mm )
return ;
do {
if ( task_p == task ) {
on_ll = 1 ;
break ;
}
task_p = task_p->next_task ;
} while ( task_p != &init_task ) ;
if ( find_task_by_pid(task->pid) == task )
on_ph = 1 ;
if ( ! on_ll || ! on_ph || ! task->pid )
printk ( "[SHT] task pid %i <%s> task addr 0x%x syscall %i - TASK IS HIDDEN ( %s / %s / %s )\n" , task->pid , task->comm , task , regs->orig_eax , on_ll ? \"on linked list" : "NOT ON LINKED LIST" , on_ph ? "on pidhash list" : "NOT ON PIDHASH LIST" , task->pid ? "pid is valid" : "PID IS INVALID" ) ;
return ;
}
int sht_init ( void ) {
hook_int ( 128 , (unsigned long) &stub_func , &old_handler ) ;
printk("[SHT] loaded - monitoring tasks integrity\n") ;
return 0 ;
}
void sht_exit ( void ) {
hook_int ( 128 , old_handler , NULL ) ;
printk("[SHT] unloaded\n") ;
return ;
}
module_init(sht_init) ;
module_exit(sht_exit) ;
MODULE_AUTHOR("ubra / PHI Group") ;
MODULE_DESCRIPTION("sht - search hidden tasks v1.0.0") ;
MODULE_LICENSE("GPL") ;
EXPORT_NO_SYMBOLS ;
Makefile
all: sht.c hp.c
gcc -c -I/EDIT_HERE_YOUR_LINUX_SOURCE_TREE/linux/include sht.c hp.c
sh.patch
--- linux-2.4.30/kernel/sched_orig.c 2004-11-17 11:54:22.000000000 +0000
+++ linux-2.4.30/kernel/sched.c 2005-07-08 13:29:16.000000000 +0000
@@ -534,6 +534,25 @@
__schedule_tail(prev);
}
+asmlinkage void phi_sht_check_task(struct task_struct *prev, struct task_struct *next)
+{
+ struct task_struct *task_p = &init_task;
+ unsigned char on_ll = 0, on_ph = 0;
+
+ do {
+ if(task_p == prev) {
+ on_ll = 1;
+ break;
+ }
+ task_p = task_p->next_task ;
+ } while(task_p != &init_task);
+ if (find_task_by_pid(prev->pid) == prev)
+ on_ph = 1 ;
+ if (!on_ll || !on_ph || !prev->pid)
+ printk("[SHT] task pid %i <%s> task addr 0x%x ( next task pid %i <%s> next task addr 0x%x ) - TASK IS HIDDEN ( %s / %s / %s )\n", prev->pid, prev->comm, prev, next->pid, \next->comm, next, on_ll ? "on linked list" : "NOT ON LINKED LIST", on_ph ? "on pidhash list" : "NOT ON PIDHASH LIST", prev->pid ? "pid is valid" : "PID IS INVALID");
+ return;
+}
+
/*
* 'schedule()' is the scheduler function. It's a very simple and nice
* scheduler: it's not perfect, but certainly works for most things.
@@ -634,6 +653,13 @@
task_set_cpu(next, this_cpu);
spin_unlock_irq(&runqueue_lock);
+ /*
+ * check task`s structures before we do any scheduling decision
+ * skip any kernel thread which might yeld false positives
+ */
+ if(prev->mm)
+ phi_sht_check_task(prev, next);
+
if (unlikely(prev == next)) {
/* We won't go through the normal tail, so do this by hand */
prev->policy &= ~SCHED_YIELD;
0x3: 对抗VFS HOOK进程隐藏检测
不论是在Linux、window下，进程隐藏的检测技术的核心思想都是类似的
1. 确定用户态枚举列表的数据来源 2. 在内核态确定另一个更底层的表示进程列表的数据结构(常常是链表) 3. 对比两者比较的结果，确定是否发生隐藏行为
process_list.c
#include <linux/module.h>
#include <linux/init.h>
#include <linux/proc_fs.h>
#include <linux/fs.h>
#include <linux/slab.h>
#include <linux/sched.h>
#include <linux/stat.h>
#include <linux/version.h>
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 24)
#define ITERATE_NAME readdir
#define READ_PROC_PROTO char *buffer, char **start, off_t off,int count, int *eof, void *data
#else
#define ITERATE_NAME iterate
#define READ_PROC_PROTO struct file* file, char* buffer, size_t count, loff_t* offset
#endif
static struct file_operations proc_file_ops;
static unsigned short int read_flag;
void *get_vfs_readdir ( const char *path )
{
void *ret;
struct file *filep;
if ( (filep = filp_open(path, O_RDONLY, 0)) == NULL )
return NULL;
if(!IS_ERR(filep))
{
if ((ret = filep->f_op->ITERATE_NAME)==NULL)
return NULL;
filp_close(filep, 0);
return ret;
}
else{
return 0;
}
}
int read_proc(READ_PROC_PROTO)
{
int len=0;
struct task_struct *task_list;
char path[64]="\0";
if(read_flag)
read_flag = 0;
else
{
read_flag = 1;
return 0;
}
len += sprintf(buffer+len, "\t\t\tRootkit Checker Demo\n\t\t\tbeta v0.1 [only vfs hook rootkit]\tby xti9er\n");
for_each_process(task_list)
{
strcpy(path,"/proc/");
sprintf(path,"%s%d",path,task_list->pid);
len += sprintf(buffer+len, "[%d] %s",task_list->pid,task_list->comm);
printk("[%d] %s",task_list->pid,task_list->comm);
if(get_vfs_readdir(path))
{
len += sprintf(buffer+len, "\n");
printk("\n");
}
else{
len += sprintf(buffer+len, "\t[may be hiddened by vfs_readdir hook]\n");
printk("\t[maybe hiddened by vfs_readdir hook]\n");
}
}
return len;
}
int functn_init (void) {
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 24)
create_proc_read_entry("ps_list",0,NULL,read_proc,NULL);
#else
proc_create("ps_list",0,NULL,&proc_file_ops);
proc_file_ops.read=read_proc;
#endif
read_flag = 1;
return 0;
}
void functn_cleanup(void) {
remove_proc_entry("ps_list",NULL);
}
MODULE_LICENSE("GPL");
module_init(functn_init);
module_exit(functn_cleanup);
Relevant Link:
http://phrack.org/issues/63/18.html http://files.cnblogs.com/LittleHann/HiddenProcesses.ppt http://security.tencent.com/index.php/opensource/detail/16
4. LSM框架(Linux Security Module)于LKM安全
LSM框架自身并不提供任何安全策略，它只是为安全模型提供了一致性接口。它使得各种不同的安全模型以内核模块的方式得到实现，而且不需改动内核源代码以及重新编译内核。目前基于LSM框架实现的最主要的安全模块主要有
1. SELinux(安全增强型Linux)
SELinux模型的安全体系结构被称为Flask体系，它是基于动态策略配置的MAC(强制访问控制)子系统，能够支持较细粒度的权限管理，在Linux 2.6内核中是以模块形式出现。
SELinux 由三部分组成：
1) 安全服务器
安全服务器为获得安全策略的决策判定提供通用接口，使其余部分保持安全策略的独立性
2) 访问向量缓存
访问向量缓存(AVC)
提供了从安全服务器获得的访问策略决策结果的缓冲区，以减少性能开销
3) 对象管理器
对象管理器集成在内核的各个子系统，如进程管理子系统，文件子系统，它从安全服务器或者访问向量缓存AVC中获得安全策略判定结果，然后应用这些判定结果给进程和对象的安全标记赋值，最后根据这些安全标记控制系统上的各种操作
2. LIDS(Linux 入侵检测系统)
3. POSIX 1e Capabilities
4. DTE(域和类安全增强)
在传统的安全机制下，Linux安全是基于自主存取控制(DAC)机制的，只要符合规定的权限，如规定的所有者和文件属性(读、写、执行)等，就可存取资源。一些通过setuid/setgid的程序就能形成严重的安全隐患，甚至一些错误的配置就可引发巨大漏洞，使系统被轻易攻击
而SELinux则基于强制存取控制(MAC)，透过强制性的安全策略，应用程序或用户必须同时符合DAC 及对应SELinux的MAC才能进行正常操作，否则都将遭到拒绝或失败，而这些问题将不会影响其他正常运作的程序和应用，并保持它们的安全系统结构。
LKM 注入攻击一般是对/lib/modules/(uname-r)/kernel/下的模块文件进行修改，SELinux下的权限设置能限制对模块文件的修改，为模块文件的完整性提供保证，从而防止针对模块文件的 LKM注入攻击。同时 SELinux下的权限设置限制了恶意程序对/dev目录下文件访问和修改。由于进行了基于CAP_SYS_MODULE 权能的加载权限的检查，阻止了许多获取root权限后的恶意加载
Relevant Link:
论文： Linux 2.6 内核下LKM 安全性研究 徐敏，熊盛武
5. rootkit检测技术及工具
0x1: rootkit防御技术
on prevention
1. Create MD5 checksums of critical system utilities 2. Record all open ports 3. Save copies of system utilities to floppy or CD-ROM 4. Configure remote syslog hosts 5. Introduce network logging 6. Secure your systems (patch, administer, harden)
Detection
rootkit一般会集成很多的组件和功能，检测rootkit本质上就是在理解rootkit的行为的基础上进行针对性的分类、聚类、以及行为定性
1. Trojan horse system utilities that prevent the system administrator from detecting attacker activity 2. Back doors that allow the hacker to enter the system at will 3. Log-wiping utilities that erase the attacker's access record from system log files 4. Packet sniffers that capture network traffic for the attacker 5. Other utilities that can be used for communication or further attacks
Relevant Link:
http://www.techrepublic.com/article/detecting-rootkits/
0x2: rootkit检测工具
1. KsiD [Kernel Symbol Interception Detection]
http://www.rootkitanalytics.com/kernelland/ksid.php
2. Autodesk DWF Toolkit 7.7
http://usa.autodesk.com/adsk/servlet/index?id=823771&siteID=123112
3. ElfStat
http://www.rootkitanalytics.com/kernelland/elfstat.php
4. Unhide
http://www.unhide-forensics.info/?Linux
Unhide是一个查找系统隐藏进程和TCD/UDP端口的小工具，利用rootkits/LVMS及其他隐藏技术实现。这个工具可以工作中Linux/unix和Windows系统下
unhide检测隐藏进程基于以下技术
1) Compare /proc vs /bin/ps output
2) Compare info gathered from /bin/ps with info gathered by walking thru the procfs.
3) Compare info gathered from /bin/ps with info gathered from syscalls(syscall scanning)
4) Full PIDs space occupation (PIDs bruteforcing)
5) Reverse search, verify that all thread seen by ps are also seen by the kernel(/bin/ps output vs /proc, procfs walking and syscall)
6) Quick compare /proc, procfs walking and syscall vs /bin/ps output.
unhide检测隐藏端口基于以下技术
1) Identify TCP/UDP ports that are listening but not listed in /bin/netstat doing brute forcing of all TCP/UDP ports availables.
Copyright (c) 2014 LittleHann All rights reserved
来源：https://www.cnblogs.com/LittleHann/p/3870974.html