内核为audit规则设置了六个列表：User、Task、Entry、Watch、Exit和Type，依次对应audit_filter_list数组的第0～第5个元素。代码如下。
audit_filter_list用于规则匹配，audit_rules_list只用于规则显示。当用户态进程通过netlink套接字传送“AUDIT_LIST_RULES”消息给内核时，内核就会把所有的审计规则发还给用户态进程。Watch列表已经没有用处，保留它多半是为了和旧版本的用户态程序兼容。用户态程序，大多数情况下是auditctl，会向内核请求访问某个规则列表。比如，请求向编号为4（Exit）的列表中加入规则。Watch列表的编号是3，删除它会导致其后的列表编号变动。这或许是保留它的原因。
下面逐一解释规则列表。
1.User
此处的User指用户态审计消息。内核缺省是将所有接收到的用户态类型的审计消息发送给auditd。通过这个规则队列，管理员可以配置规则让内核忽略某些用户态类型audit消息。相关代码如下：
下面看一下audit_filter_user的实现：
2.Type
前面的User规则列表针对的是用户态消息类型，下面要介绍的Type规则列表针对的是内核产生的消息类型。如果管理员不想看到某种类型的内核audit消息，则可以生成一条规则，让内核不发送这种类型的audit消息到auditd。
前面讲过，其他内核子系统如果要产生一条内核审计消息（日志性质的消息），需要先调用audit_log_start函数。下面看一下audit_log_start：(www.xing528.com)
如果在Type规则队列中有条规则规定某个消息类型“不受欢迎”，则使用此消息类型获取的audit_buffer是空的，也就产生不了相应的audit消息。
3.Task
audit子系统对进程创建有特殊照顾，为它专门创建了一个规则列表。所以，对于clone和fork系统调用，除了要经过下面提到的Entry和Exit两个规则列表外，还会检查Task规则列表中的规则。
4.Entry
Entry对应于系统调用的入口。在刚刚进入系统调用时能检查的只是系统调用号和系统调用的前四个参数。
5.Exit
Exit列表是最重要的。Exit规则的检查点是在系统调用结束时，此时是数据最丰富的时候调用它的地方在audit_get_context中，audit_get_context这个函数名很难让人想到规则匹配。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
