使用Audit审计服务排查linux终端异常关机问题

Posted 2022-03-07 EbowTang

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了使用Audit审计服务排查linux终端异常关机问题相关的知识，希望对你有一定的参考价值。

我将本案例写成了文档案例，可参见阿里云盘链接下载阅读，凡是提及附件的地方本文均未粘贴，可下载文档来阅读：

「spaceos终端不符合预期关机问题」https://www.aliyundrive.com/s/hetkctd2bbD

点击链接保存，或者复制本段内容，打开「阿里云盘」APP ，无需下载极速在线查看，视频原画倍速播放。

【基本信息】

终端：C101LS，装载x64 SpaceOS(linux终端)系统
版本：Workspace E1009
现场使用workspace的方式部署教室云桌面，自动登录云桌面，终端锁在教室讲台里，平时仅关闭显示器，终端独立供电，并且不断电。
客户基本预期就是终端不关机，也不断开云桌面，仅关闭其显示器，第二天上课时仅仅是给显示器上电，并且从授权策略中将关机和重启功能都是禁用了的。

【问题描述】

如上述基本信息，在部署了16间教室后，经过一周表现正常，但是第二周来每天陆续发现linux终端出现9次不符合预期的关机，确定非虚拟机关机。

【定位过程】

实际上，这个问题在出差到达现场之前，就已经定位到是正常的软关机，见下syslog的日志段，依次正确关闭系统服务，并且syslog中并无硬件类的报错记录，包括SpaceAgent和workspace客户端没有执行关机记录。

Jul 11 16:43:50 localhost systemd[1]: Stopped target Timers.

Jul 11 16:43:50 localhost systemd[1]: Closed Load/Save RF Kill Switch Status /dev/rfkill Watch.

Jul 11 16:43:50 localhost systemd[1]: Stopped target Host and Network Name Lookups.

Jul 11 16:43:50 localhost systemd[1]: Stopped Discard unused blocks once a week.

Jul 11 16:43:50 localhost systemd[1]: Stopping Authorization Manager...

Jul 11 16:43:50 localhost systemd[1]: Stopped target Graphical Interface.

Jul 11 16:43:50 localhost systemd[1]: Stopped Daily Cleanup of Temporary Directories.

Jul 11 16:43:50 localhost systemd[1]: Stopped Daily apt upgrade and clean activities.

Jul 11 16:43:50 localhost systemd[1]: Stopped Daily apt download activities.

Jul 11 16:43:50 localhost systemd[1]: Stopped Message of the Day.

Jul 11 16:43:50 localhost systemd[1]: Stopping User Manager for UID 1010...

Jul 11 16:43:50 localhost systemd[1]: Stopping Save/Restore Sound Card State...

Jul 11 16:43:50 localhost systemd[1]: Stopped target Multi-User System.

Jul 11 16:43:50 localhost systemd[1]: Stopping SpaceAgent deamon...

Jul 11 16:43:50 localhost systemd[1]: Stopping Regular background program processing daemon...

Jul 11 16:43:50 localhost systemd[575]: Stopping Virtual filesystem service...

Jul 12 07:56:19 localhost systemd[1]: Starting Flush Journal to Persistent Storage...

Jul 12 07:56:19 localhost systemd[1]: Started Flush Journal to Persistent Storage.

但疑难问题点在于，我们并不清楚关机的触发源，因为客户确定他们不会去关机，也不希望关机，讲台也没有针对终端的关开机按钮(后续事实证明这句话不完全准确)。

1，整理规律如下

出现的终端并不固定，多个教室均出现，从出现的数量来看(加上到现场发现的总共出现16台)，问题概率高
问题发生的时间并不固定，有的是晚上8点多，有的是下午2-4点之间
问题时间尽管不固定，但是11号（周末），出现5台不符合预期关机时间点集中的情况，均在下午4点30-5点之间。

2，部署audit审计服务定位问题

在现场部署了audit服务(见附件1)来审计关机触发源，尽管没定位到触发源，但是从客观上证明了和workspace，spaceagent以及管理平台无关。截取部分审计内容如下：

A）键入last -x | shutdown后的审计结果

type=SYSCALL msg=audit(1626146892.715:736)（2021-07-13 11:28:12）: arch=c000003e syscall=59 success=yes exit=0 a0=557d4e603050 a1=557d4e5de6a0 a2=557d4e5df9f0 a3=8 items=2 ppid=4776 pid=4785 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="shutdown" exe="/bin/systemctl" key="shutdown_call"

type=EXECVE msg=audit(1626146892.715:736): argc=1 a0="shutdown"

type=CWD msg=audit(1626146892.715:736): cwd="/root"

解析：

comm="shutdown" ，命令参数是关机

exe="/bin/systemctl" ，实际执行者是systemctl

key="shutdown_call" ，key是shutdown_call

cwd="/root"，执行进程的路径（因为是人为切换到该目录下执行的）

type=EXECVE msg=audit(1626146892.715:736): argc=1 a0="shutdown"，执行的命令是shutdown。

故该关机审计是人为在/root目录执行shutdown关机

B）通过ws客户端关机后的审计结果

type=SYSCALL msg=audit(1626058718.076:61): arch=c000003e syscall=59 success=yes exit=0 a0=562fe643d738 a1=562fe6443d88 a2=562fe6445240 a3=0 items=2 ppid=1495 pid=1496 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="shutdown" exe="/bin/systemctl" key="shutdown_call"

type=EXECVE msg=audit(1626058718.076:61): argc=3 a0="shutdown" a1="-h" a2="now"

type=CWD msg=audit(1626058718.076:61): cwd="/userdata/H3C/Workspace/E1009"

解析：

comm="shutdown" ，命令参数是shutdown

exe="/bin/systemctl" ，实际执行者是systemctl

key="shutdown_call" ，key是shutdown_call

cwd="/userdata/H3C/Workspace/E1009"，执行进程的路径

type=EXECVE msg=audit(1626058718.076:61): argc=3 a0="shutdown" a1="-h" a2="now"

执行的命令是shutdown -h now

故该关机审计是/userdata/H3C/Workspace/E1009下执行了shutdown -h now的关机

C）通过终端关机后的审计结果

#正常关机审计日志开始日志段1：查询服务状态

type=SYSCALL msg=audit(1626053451.193:483): arch=c000003e syscall=59 success=yes exit=0 a0=55d9e0583dd8 a1=55d9e0583d40 a2=55d9e0583d98 a3=1b6 items=2 ppid=4977 pid=4981 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemctl" exe="/bin/systemctl" key="shutdown_call"

type=EXECVE msg=audit(1626053451.193:483): argc=6 a0="systemctl" a1="-p" a2="LoadState" a3="--value" a4="show" a5="netplan.service"

type=CWD msg=audit(1626053451.193:483): cwd="/"

………（略过）

#正常关机审计日志开始日志段2：陆续停止服务

type=SERVICE_STOP msg=audit(1626053451.269:493): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=cron comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1626053451.269:494): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=udisks2 comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1626053451.273:495): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rsyslog comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1626053451.273:496): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=polkit comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=SYSTEM_SHUTDOWN msg=audit(1626053451.785:518): pid=5017 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-update-utmp" exe="/lib/systemd/systemd-update-utmp" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1626053451.789:519): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-random-seed comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1626053451.789:520): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-update-utmp comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=DAEMON_END msg=audit(1626053451.795:8248): op=terminate auid=0 pid=1 subj= res=success

#正常关机审计日志开始日志段3：审计本次关机事件

type=DAEMON_END msg=audit(1626053451.795:8248): op=terminate auid=0 pid=1 subj= res=success

#正常关机审计日志结束

解析：

Systemctl先在查询系统服务状态
接着systemd服务陆续关闭系统及其第三方服务
系统systemd-update-utmp审计本次关机事件

故该关机审计是，该日志没有显式表明第三方服务参与和触发源，且均是系统服务正常关停流程，自此获得系统正常关机流程。

D）通过/userdata/H3C目录下脚本重启终端审计结果

type=SYSCALL msg=audit(1625820856.452:9): arch=c000003e syscall=59 success=yes exit=0 a0=55df7e0c87a0 a1=55df7e0ca350 a2=55df7e0c5ed0 a3=55df7e0bd010 items=2 ppid=1421 pid=1498 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="reboot" exe="/bin/systemctl" key="shutdown_call"

type=EXECVE msg=audit(1625820856.452:9): argc=1 a0="reboot"

type=CWD msg=audit(1625820856.452:9): cwd="/userdata/H3C"

解析：

comm=" reboot " ，命令参数是reboot

exe="/bin/systemctl" ，实际执行者是systemctl

key="shutdown_call" ，key是shutdown_call

cwd="/userdata/H3C "，执行进程的路径

type=EXECVE msg=audit(1625820856.452:9): argc=1 a0="reboot"

执行的命令是reboot

故该关机审计是/userdata/H3C/下执行了reboot的引起关机(并启动)

E）不符合预期关机审计结果

该日志截取于11号，5台不符合预期关机中的其中一台

#关机审计日志开始1：查询系统服务状态

type=SYSCALL msg=audit(1625993030.468:434): arch=c000003e syscall=59 success=yes exit=0 a0=5643a3c19dd8 a1=5643a3c19d40 a2=5643a3c19d98 a3=1b6 items=2 ppid=3601 pid=3608 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemctl" exe="/bin/systemctl" key="shutdown_call"

type=EXECVE msg=audit(1625993030.468:434): argc=6 a0="systemctl" a1="-p" a2="LoadState" a3="--value" a4="show" a5="netplan.service"

type=CWD msg=audit(1625993030.468:434): cwd="/"

type=PATH msg=audit(1625993030.468:434): item=0 name="/bin/systemctl" inode=105 dev=08:06 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0

type=PATH msg=audit(1625993030.468:434): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=3108 dev=08:06 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0

type=PROCTITLE msg=audit(1625993030.468:434): proctitle=73797374656D63746C002D70004C6F61645374617465002D2D76616C75650073686F77006E6574706C616E2E73657276696365

#关机审计日志开始2：陆续关闭系统服务

type=SERVICE_STOP msg=audit(1625993030.532:440): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=cron comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1625993030.532:441): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=udisks2 comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1625993030.540:442): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rsyslog comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

#关机审计日志开始3：审计本次关机事件

type=SYSTEM_SHUTDOWN msg=audit(1625993031.060:472): pid=3639 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-update-utmp" exe="/lib/systemd/systemd-update-utmp" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1625993031.064:473): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-random-seed comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=SERVICE_STOP msg=audit(1625993031.068:474): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-update-utmp comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

type=DAEMON_END msg=audit(1625993031.069:8248): op=terminate auid=0 pid=1 subj= res=success

#关机审计日志结束

解析：

和通过终端关机键关机流程一样，有以下结论

Systemctl先在查询系统服务状态
接着systemd服务陆续关闭系统及其第三方服务

3，系统systemd-update-utmp审计本次关机事件

故该关机审计是，该日志没有显式表明第三方服务参与和触发源，且均是系统服务正常关停流程，即评估只可能是系统正常关机流程。

结合上面五个案例，可以得出

如果是显式调用关机必有执行源，并且/bin/systemctl是真正的执行者；
不符合预期关机审计看出，是正常系统关机，由于确定不是终端按钮触发，肯定存在另外触发源

3，定位后期

当比对和排除软件层面的因素后，剩下的：

电源稳定性(可能性小)
终端硬件本身有问题(可能性小)
讲台中控环境，或者人为因素

结合问题规律，实际上只能往3方向分析，通过调用监控发现每次出现问题的时间点均有学生在打扫卫生，或者现场有人。通过反复琢磨讲台最终发现11号下午的不符合预期关机均是人为无意导致，同时通过调用监控在后续也发现了他因，见【问题原因】

【问题原因】

问题的原因有两个：

大部分教室的键盘配置有power键，按下后终端立刻关机，在现场调用监控可知，一方面是打扫卫生用毛巾擦桌子（或者其他行为）时无意触碰到该按钮，另一方面也是教员有意为之(教员并不知道维护人员系希望永不停机)

教员在下课后习惯性注销虚拟机(本意应该是关机)，导致vdsession断开虚拟机，然后教员在客户端右上角点击关机。这个通过日志和监控也当场确认无疑。

【问题解决】

针对原因1：编写了一键配置禁用power键的脚本(见附件2)，键盘不再对终端关机。

针对原因2：目前可以引导客户使用，尽量避免客户人为关机，针对终端可以每天设置定时任务开机。

同时可以通过客户端toolbar返回客户端关机的问题，和代表处唐宇沟通，提ALM电子流需求(实现可以通过策略取消返回本地客户端的功能)。

注意：

局点平时会关闭显示器，如果自动开机，客户端自动连接云桌面后，此时未连接显示器，客户端将无法知悉显示器分辨率，会产生小窗口问题。

【问题小结】

事后来看，原因都是人为，并且都能通过调用监控查到。问题难在：

这个问题怎么分析日志都是正常关机，无法分析到明确触发源。即使当我们调用audit服务来审计关机源时，怎么定位都是系统服务执行的正常关机流程。
现场无法远程，只能搜集日志，以及言语沟通，而传递的信息中有的是不准确的，混淆了定位方向。比如客户认为不可能是人为，因为盒子是锁着的，电源也没断，讲台没有针对该终端关机功能(键盘上实际有)。方向的混淆，导致在现场甚至关注过电源稳定性。
并且该问题有两个触发源，即使原因1解释了大部分，有部分教室也无法解释清楚。
现场的教室由于部分键盘没有power键，逃过了法眼，导致没有过早抓到原因。

这个问题在现场，实际是通过缩小问题范围逐步定位的，事后诸葛亮来看，其实当11号下午出现集中时间点出现5台不符合预期关机，基本就应该确定有人为规律迹象，同时也应该调转方向往监控和讲台更进一步全面排查。即我们应该准确的抓住既有事实及其规律深入往下分析，减少弯路。

附录

1,audit审计服务部署脚本及其安装包

解压后的文件中有readme.txt，安装包和安装脚本，请参考部署

2,配置软绘，软解，禁用power键

解压后的文件中有readme.txt和安装脚本，请参考部署

3,部署audit服务

本文配置对象：所有非arm架构的SpaceOS终端

3.1 手动安装auditd审计服务

第一步：安装auditd包以及依赖，见audit,zip

dpkg -i xxx.deb

第二步：添加审计规则文件audit.rules(见audit,zip解压后)，到/etc/audit/rules.d目录下

第三步：重启终端，确认auditd服务启动正常，audit.rules生效

如图，auditd服务启动生效

如图，添加审计规则生效

3.2 批量安装auditd审计服务

1，首先通过命令下发功能，上传audit.zip包(见附件1)，并输入命令,然后选择指定终端或者终端分组下发即可

sudo unzip /userdata/H3C/SpaceAgent/RecvFiles/audit.zip

2, 接着依然通过命令下发功能，并输入命令,然后选择指定终端或者终端分组下发即可

sudo chmod +x /userdata/H3C/SpaceAgent/RecvFiles/install_audit.sh;sudo /userdata/H3C/SpaceAgent/RecvFiles/install_audit.sh

3，如果后续想卸载audit （注意，有个参数1）

sudo chmod +x /userdata/H3C/SpaceAgent/RecvFiles/install_audit.sh;sudo /userdata/H3C/SpaceAgent/RecvFiles/install_audit.sh 1

说明：

如果终端已经成功执行过一次该脚本，第二次将不会执行和重启

3.3 验证auditd规则是否生效

我们添加了两条审计规则，

1) shutdown/poweroff命令执行

2) reboot系统调用执行

审计日志在/var/log/audit/audit.log

3.3.1 审计系统poweroff

root@localhost:~$ ls -la /sbin/poweroff

lrwxrwxrwx 1 root root 14 11月 15 2019 /sbin/poweroff -> /bin/systemctl

poweroff与shutdown其实执行的都是/bin/systemctl，通过参数来分区

命令行执行poweroff ，audit.log有如下输出

可以看到执行的是/bin/systemctl 参数为poweroff，key为shutdown_call

3.3.2 审计系统reboot

是否能够有效的审计reboot调用，答案是不能（shutdown/poweroff对应的系统调用是reboot）

原因：目前auditd版本，filter对应的匹配过滤，filter可以为：task,exit，user，exclude；已经没有entry了，也就是内核auditd线程，只有在系统调用返回的时候才会通知用户态auditd服务，不会在执行调用时刻发起通知，执行reboot, 这个时候用户态auditd，往往收不到消息的；

为了进一步验证，写一个手动调用reboot API的程序，进行验证，以spaceos用户执行，因没有权限，系统调用返回-1，可以看到其实是可以审计的，也就是系统调用返回时刻通知用户

4,audit审计日志与规则

4.1 audit审计规则

可参考：audit.rules(7) - Linux man page (die.net)

本文audit.rules规则解读如下

#监控文件系统行为，下表示，监控/bin/systemctl文件修改、写、读、执行修为，并指定关键词为shutdown_call

-w /bin/systemctl -p rwxa -k shutdown_call

#监控系统调用行为，下表示，行为完成后总是记录审计

-a always,exit -F arch=b64 -S reboot -k reboot_call

4.1.1 监控文件系统行为

规则格式：-w 路径 -p 权限 -k 关键字

其中权限动作分为四种（依靠文件、目录的权限属性来识别）

r 读取文件

w 写入文件

x 执行文件

a 修改文件属性

示例：

监控/etc/passwd文件的修改行为（写，权限修改）

-w /etc/passwd -p wa

4.1.2定义系统调用规则：

规则格式：-a action,filter -S system_call -F field=value -k key_name

action和filter明确一个事件被记录。
action可以为always或者never，
filter明确出对应的匹配过滤，filter可以为：task,exit(行为完成后审计)，user，exclude。
system_call明确出系统调用的名字，几个系统调用可以写在一个规则里，如-S xxx -S xxx。系统调用的名字可以在/usr/include/asm/unistd_64.h文件中找到。
field=value 作为附加选项，修改规则以匹配特定架构、GroupID，ProcessID等的事件。具体有哪些字段

4.2 audit审计日志关键词解析

可参考：

默认Audit日志存放在/var/log/audit/andit.log中，可以通过auditctl命令来定义自己的audit规则，auditctl的使用方法参考：https://linux.die.net/man/8/auditctl。

以下面三条audit log为例：

type=SYSCALLmsg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=500uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500tty=pts0 ses=1 comm="cat" exe="/bin/cat"subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023key="sshd_config"

type=CWD msg=audit(1364481363.243:24287): cwd="/home/shadowman"

type=PATHmsg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config"inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00obj=system_u:object_r:etc_t:s0

type=SYSCALL这一行说明了audit的消息类型，audit消息类型可以对照https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sec-Audit_Record_Types.html的表格进程查看，SYSCALL说明此次audit记录的是一次系统调用Kernel的记录
msg=audit(1364481363.243:24287)这一行的格式是(time_stamp:ID)，time_stamp是unix时间，可以将其转化为其他时间格式，可以使用站长工具进行转换：http://tool.chinaz.com/Tools/unixtime.aspx。相同的audit event可能会产生多条time_stamp和event ID相同的log
msg后面跟了很多形式为“name=value”的键值对，这些键值对由kernel或者用户空间的进程产生。
arch=c000003e标明CPU的类型，c000003e对应x86_64，使用ausearch查看audit日志时会自动将其解码
syscall=2指出了发送给kernel的系统调用的类型，可以使用ausyscall --dump来显示所有的syscall的说明
succeed=yes/no，说明此次syscall成功或失败
exit=-13说明syscall的返回值是-13
a0，a1，a2，a3指明了前4个参数，也是编码成16进制，通过ausearch命令可以解码查看
items指出event中的path记录的数量
ppid指明Parent Process ID，即父进程ID
pid指明了进程ID
auid指出audit user ID，即当时的登陆uid
uid指出了对应进程的所有者ID
gid对应进程的group ID
euid对应进程的effective user ID
suid对应set user ID
fsuid对应file system user ID
egid对应effective group ID
sgid对应set group ID
fsgid对应file system group ID
tty指出对应进程是在哪个终端启动的
ses指出了对应进程的session ID
comm对应了进程执行的命令
exe指出了进程的执行文件的路径
subj指出进程执行时selinux上下文
key是管理员定义的标明是哪条rule输出了这条audit日志
第二条日志中CWD指出了进程的执行目录（current working directory，当前工作目录），cwd字段指出了第一条日志中syscall的执行路径
第三条日中用来记录所有传递给syscall作为参数的路径，在这个audit事件中，仅有/etc/ssh/sshd_config作为参数进行传递，通过name字段指明
inode指出了与文件或目录相对应的inode number，可以通过下面的命令查看inode对应的文件或目录：find/ -inum <inode number> -print
dev=fd:00指出文件或目录对应的device ID，在例子中，对应/dev/fd/0这个设备
mode=0100600对应文件或目录的权限，这里0100600被解析为-rw-------
ouid对应文件的owner’s user ID
ogid对应文件的owner’s group ID

以上是关于使用Audit审计服务排查linux终端异常关机问题的主要内容，如果未能解决你的问题，请参考以下文章