Linux【9】-进程管理4-2-6--安全模块--SELinux auditd日志
一、 auditd日志系统的安装与启动
当查看特定安全上下文的策略规则时，SELinux 会使用被称为 AVC（Access Vector Cache，访问矢量缓存）的缓存，如果访问被拒绝（也被称为 AVC 拒绝），则会在一个日志文件中记录下拒绝消息。
这些被拒绝的消息可以帮助诊断和解决常规的 SELinux 策略违规行为，至于这些拒绝消息到底被记录在什么位置，则取决于 auditd 和 rsyslogd 守护进程的状态：
- 若 auditd 守护进程正在运行，则拒绝消息将被记录与 /var/log/audit/audit.log 中。
- 若 auditd 守护进程没有运行，但 rsyslogd 守护进程正在运行，则拒绝消息会记录到 /var/log/messages 中。
注意，如果 auditd 和 rsyslogd 都在运行，那么拒绝消息将发送到 audit.log 和 messages 日志文件中。
因此，当 SELinux 出现问题时，就可以求助 SELinux 的日志系统，该日志系统中详细地记录了 SELinux 中出现的问题，并提供了解决建议。
我们当前可以使用的日志系统只有 auditd，当然这个服务是需要安装的，在我们的系统中 auditd 服务是已经安装的。如果没有安装，则使用 yum 安装即可。命令如下：
[root@localhost ~]# yum -y install auditd
安装完成之后，只需启动 auditd 服务即可。命令如下：
[root@localhost ~]# service auditd start
当然，还要使 auditd 服务是开机自启动的。命令如下：
[root@localhost ~]# chkconfig auditd on
[root@localhost ~]# chkconfig --list | grep auditd
auditd 0：关闭 1：关闭 2：启用 3：启用 4：启用 5：启用 6：关闭
其实这些工作，系统都已经帮我们完成了，不过为了保险起见，最好还是检查一下。
当开启了 SELinux 之后，很多服务的一些正常行为都会被视为违规行为（标题及下文中的错误均指违规行为）。
这时候我们就需要借助 SELinux 违规日志来分析解决。
SELinux 违规日志保存在 /var/log/audit/audit.log 中。
/var/log/audit/audit.log 的内容大概是这样的。
type=LOGIN msg=audit(1507898701.391:515): pid=8523 uid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=25 res=1
type=USER_START msg=audit(1507898701.421:516): pid=8523 uid=0 auid=0 ses=25 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
...
该文件的内容很多，而且混有很多与 SELinux 错误无关的系统审计日志。我们要借助 sealert 这个实用工具来帮忙分析（如果提示找不到命令的话请安装 setroubleshoot 软件包）。
二、auditd日志使用方法
auditd 会把 SELinux 的信息都记录在 /var/log/auditd/auditd.log 中。这个文件中记录的信息会非常多，如果手工查看，则效率将非常低下。比如笔者的 Linux 中这个日志的大小就有 386KB。
[root@localhost ~]# ll -h /var/log/audit/audit.log
-rw-------.1 root root 386K 6月 5 15：53 /var/log/audit/audit.log
而且我们这里的 Linux 只是实验用的虚拟机，如果是真正的生产服务器，那么这个日志的大小将更加恐怖（注意：audit.log 并没有自动加入 logrotate 日志轮替当中，需要手工让这个日志进行轮替）。所以，如果我们手工查看这个日志，那么效率会非常低下。
还好，Linux 较为人性化，给我们准备了几个工具，来帮助我们分析这个日志，下面分别来学习一下。
2.1 audit2why命令
audit2why 命令用来分析 audit.log 日志文件，并分析 SELinux 为什么会拒绝进程的访问。也就是说，这个命令显示的都是 SELinux 的拒绝访问信息，而正确的信息会被忽略。命令的格式也非常简单，如下：
[root@localhost ~]# audit2why < 日志文件名
例如：
[root@localhost ~]# audit2why < /var/log/audit/audit.log
type=AVC msg=audit(1370412789.400:858): avc: denied { getattr ) for pid=25624 comm="httpd" path="/var/www/htirl/index.html" dev=sda3 ino=918426
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file
#这条信息的意思是拒绝7 PID 是 25624的进程访间"/var/uww/html/Index.html",原因是主体的安全上下文和目标的安全上下文不匹配。其中，denied代表拒绝，path指定目标的文件名,scontext代表全体的安全上下文。tcontext代表目标的安全上下文，仔细看看，其实就是主体的安全上下文类型httpd_t和目标的安全上下文类型var_t不匹配导致的
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
#给你的处理建议是使用audi t2allow命令来再次分析这个曰志文件
2.2 audit2allow命令
audit2allow 命令的作用是分析日志，并提供允许的建议规则或拒绝的建议规则。这么说很难理解，我们还是尝试一下吧，命令如下：
[root@localhost ~]# audit2allow -a /var/log/audit/audit.log
#选项-a：指定日志文件名
#============= httpd_t ==============
allow httpd_t var_t：file getattr;
#提示非常简单，我们只需定义一个规则，允许httpd_t类型对var_t类型拥有getattr权限，即可解决这个问题
可是我们到现在还没有学习如果修改策略规则，这该如何是好？其实像这种因为主体和目标安全上下文类型不匹配的问题，全部可以使用 restorecon 命令恢复目标（文件）的安全上下文为默认安全上下文，即可解决问题，简单方便，完全不用自己定义规则。但是 audit2allow 命令对其他类型的 SELinux 错误还是很有帮助的。
2.3 sealert命令
命令基本用法
sealert -a /var/log/audit/audit.log
执行完命令之后，系统需要花一段时间去分析日志中的违规行为并给出分析报告。分析报告的结构讲解请看下图：
sealert 命令是 setroubleshoot 客户端工具，也就是 SELinux 信息诊断客户端工具。虽然 setroubleshoot 服务已经不存在了，但是 sealert 命令还是可以使用的。命令格式如下：
[root@localhost ~]# sealert [选项] 日志文件名
选项：
arw——-：分析指定的日志文件；
也使用这个工具分析一下我们的 audit.log 日志，命令如下：
[root@localhost ~]# sealert -a /var/log/audit/audit.log
100％ done'tuple' object has no attribute 'split'
100％ donefound 2 alerts in /var/log/audit/audit.log
———————————————————————————————————————————————————
SELinux is preventing /usr/sbin/httpd from getattr access on the 文 件 /var/www/html/index.html.
***插件 restorecon (94.8 置信度) 建议 *********************************
If 您想要修复标签。
/var/www/html/index.html 默认标签应为 httpd_sys_content_t。
Then 您可以运行 restorecon。
Do
# /sbin/restorecon -v /var/www/html/index.html
#提示非常明确，只要运行以上命令，即可修复index.html文件的问题
有了这些日志分析工具，我们就能够处理常见的 SELinux 错误了。这些工具非常好用，要熟练掌握。
参考资料
