linux audit原理内核,Linux安全审计机制模块总体描述

最新推荐文章于 2024-03-22 10:00:00 发布

弄哭你

最新推荐文章于 2024-03-22 10:00:00 发布

阅读量979

点赞数

文章标签： linux audit原理内核

原标题：Linux安全审计机制模块总体描述

1总体描述1.1概述

审计是事后认定违反安全规则的分析技术，安全审计为管理员在用户违反安全法则时提供及时的警告信息，实现对系统信息的追踪、审查、统计和报告等功能[1]。linux提供了用来记录系统安全事件的审计系统，审计系统包括用户空间审计系统和内核空间审计系统，用户空间审计系统由一些用户空间的审计程序组成，用来开启内核审计功能、设置审计规则和审计系统状态、接收内核审计系统发送来的审计消息并写入log文件，以及审计消息的检索和生成审计总结报告。内核审计系统用于产生和过滤内核的各种审计消息，本报告重点分析内核审计系统[2]。分析的内容包括：

1.审计消息的生成和发送；

2.审计消息的过滤；

3.对进程和系统调用的审计；

4.对文件或目录的审计。

1.2涉及到的源码范围说明

本文所涉及到的源码有以下文件：

linux/audit.h 主要包括审计事件、规则域的定义和规则结构类型的定义以及部分钩子

函数的定义。

kernel/audit.h 包括审计状态的结构类型、规则链表条目、基于节点的哈希规则链表的定义和部分外部函数的声明。

kernel/audit.c 审计系统实现的主要文件，包括审计缓冲区的定义，表示审计系统状态的全局变量的定义，审计消息发送和接收所使用的等待队列的声明和审计消息生成和发送的函数audit_log、audit_log_start、audit_log_format和audit_log_end等函数的定义。

kernel/auditsc.c 对系统调用审计提供支持的文件，包括系统调用进入和退出时执行的函数，进程创建时执行规则过滤的函数和系统调用进入或退出时执行的规则过滤函数。

kernel/auditfilter.c 对规则过滤提供支持的文件，包括规则链表及其锁的定义，添加、删除规则的函数、对规则域表达式进行计算的函数以及根据user规则链表和type规则链表进行规则过滤的函数。

kernel/audit_watch.c 对inode监视提供支持的文件，包括审计监视相关数据结构的定义，审计监视处理实例的初始化函数和审计监视事件处理函数及添加、删除审计监视的函数等。

linux/fs/notify中与fsnotify支持相关的文件fsnotify.c、fsnotify.h、group.c、mark.c、inode_mark.c。

1.3技术方案及原理

审计系统是评价计算机安全性的重要标准之一，审计系统提供了一种记录系统安全信息的方法。审计系统的审计信息包括:可被审计的事件名称、事件状态(成功或失败)和安全信息等.

1.3.1 Linux审计系统的架构

Linux 审计系统子系统之间的关系如图1-1所示。应用程序 auditctl用来设置审计消息过滤规则、查询内核审计系统状态等,它通过 netlink机制与内核审计系统的 socket线程进行双向通信。内核其他线程的审计信息由内核审计API先经过规则链表的过滤，然后写入netlink套接字缓冲区队列中，内核线程 kauditd通过 netlink机制将审计消息定向发送给用户空间的审计后台 auditd的主线程,auditd主线程再通过事件队列将审计消息传给审计后台的写 log文件线程，由写 log文件线程将审计消息写入 log文件[2]。

图1-1 Linux审计系统的架构

1.3.2 审计事件分类

所有与安全相关的行为都被生成了相应的的审计消息，为了把审计消息准确地传送给目的用户，审计系统将系统的审计消息事件分为以下几大部分(数字表示审计事件号)：

1000~1099 用于审计系统的命令。

1100~1199 用户空间可信的应用程序消息。

1200~1299 审计后台进程的内部消息。

1300~1399 审计事件消息。

1400~1499 SELinux 使用的消息。

1500~1599 内核 LSPP事件。

1600~1699 内核加密(crypto)事件。

1700~1799 内核正常记录。

1800~199 内核完整性事件。

2000 用于其他没有分类的内核审计消息(假想)。

2001~2099 未使用(内核)。

2100~2199 用户空间正常记录。

2200~2299 用户空间对正常记录相应的动作。

2300~2399 用户空间产生的 LSPP事件。

2400~2499 用户空间加密事件。

2500~2999 用户空间将来使用(可能是整数标签和相应的事件)。

1000~1199 是内核和用户空间双向使用的，1200~1299和 2100~2999是用户空间专有的，1300~2099是内核-->用户空间通信用的。事件的定义在内核和用户空间的审计系统都是一致的。内核审计系统根据审计事件执行相应的操作或者完成相应的审计消息过滤。

内核审计系统将审计消息写入审计缓冲区，然后通过netlink机制将消息发往用户空间后台进程，因此，每个审计缓冲区都对应着一个netlink套接字缓冲区，netlink套接字缓冲区用来存储用于发送的审计消息记录。

每条审计消息在送往审计缓冲区时，需要查看是否有空闲缓冲区，如果缓冲区全满，则当前进程阻塞自己等待审计后台进程auditd取走至少一条消息时才能进行发送，另一方面，当审计后台进程存在时，审计消息被发送给审计后台auditd,否则，则由printk发送给日志后台进程，由日志后台将审计消息作为普通的日志记录存放在日志文件中。

在内核的其它部分会频繁地记录安全审计事件，为了方便用户查看自己关心的审计消息，必须对审计消息进行过滤。在Linux审计系统中，提供了设置审计规则的auditctl工具，在auditctl设置的规则传入内核保存在规则链表上生成审计消息前，必须先经过规则链表的过滤，只有消息是符合某条规则的才会生成这条消息。

对于进程的审计，系统调用的审计是在系统调用的入口和出口处加上审计函数，内核函数的审计是在函数内部的审计点加上审计hook 函数，这些审计函数将需要截获的消息通过规则过滤后，填充到审计上下文，在系统调用退出时，进程将审计上下文发送给审计后台。有关进程审计的信息，存放在进程审计上下文中。每当进程进入系统调用和退出系统调用时,使用审计上下文记录系统调用进入和退出的各种属性数据，如：时间戳、系统调用号、系统调用参数等。审计上下文还通过进程审计辅助数据记录进程运行中的各种关键数据的审计信息(比如进程打开的文件的inode号和所在设备号)。对于系统调用来说，审计上下文只能记录系统调用进入和退出时的审计信息，审计上下文所描述的数据在系统调用退出时通过内核审计系统发送给审计后台后，审计上下文就可以清空，为下次系统调用做好准备。

对于文件系统的审计，在新版本的的内核中，不再使用inotify来监视文件系统的变化，而是直接使用文件系统监视变化的框架fsnotify来进行文件系统的监视，包括对目录的监视和对文件的监视。对文件系统的审计是借助于fsnotify机制完成的。fsnotify负责监视文件的变化，然后由审计系统生成相关的审计消息。和进程一样，为了截获文件系统的变化，fsnotify机制在文件系统的各个操作函数中加入了 hook函数，当文件系统调用了这些操作函数改变了文件系统中的文件或目录时，就调用 hook函数发出相应的事件。

fsnotify采用事件模型来监视和处理文件系统的变化。

fsnotify监视审计事件并处理审计事件的过程如图2-1所示。