审核 netlink 响应没有正确的数据包长度

分享于2022年07月17日 audit-trail go linux netlink 问答
【问题标题】:审核 netlink 响应没有正确的数据包长度(Audit netlink response don't have the right packet length)
【发布时间】:2022-03-10 13:52:09
【问题描述】:

我一直在尝试使用 mdlayher/netlink 从 go 读取 linux 审计日志。我能够建立连接并设置 PID,以便能够通过单播和多播从 netlink 套接字接收日志。

问题是,当库尝试解析来自 netlink 的消息时,它会失败,并且 不是因为库 。我试图转储发送到我的连接的消息,这就是我发现的。

([]uint8) (len=48 cap=4096) {
 00000000  1d 00 00 00 28 05 00 00  00 00 00 00 00 00 00 00  |....(...........|
 00000010  61 75 64 69 74 28 31 36  31 32 30 33 31 38 36 32  |audit(1612031862|
 00000020  2e 36 33 31 3a 32 37 31  30 34 29 3a 20 00 00 00  |.631:27104): ...|
}

这是来自日志流的消息之一。根据 packet structure ,前16个字节是 netlink message header nlmsghdr 的一部分。

struct nlmsghdr {
    __u32       nlmsg_len;  /* Length of message including header */
    __u16       nlmsg_type; /* Message content */
    __u16       nlmsg_flags;    /* Additional flags */
    __u32       nlmsg_seq;  /* Sequence number */
    __u32       nlmsg_pid;  /* Sending process port ID */
};

注意, nlmsg_len 是如何标记为 length of the message including header 的。如果查看消息转储,第一个 __u32 1d 00 00 00 ,在网络字节顺序中是 29。这意味着整个数据包应该是 29 字节。但是,如果你计算字节,它是 45 + 3 字节的填充,这就是数据包的对齐方式。消息在字节 45 处结束,即 (29 + 16) 或 29 + 消息头大小的长度。

但是,奇怪的是,它只发生在审计日志消息上,而不是审计控制消息回复上。有关如何解析数据包结构的示例,请参阅 https://play.golang.com/p/mA7_MJdVSv8

这是预期的吗?查看 go stdlib syscall.ParseNetlinkMessage ,似乎遵守了 header + body 的约束。我无法在负责 auditd auditctl 和它的工具系列的 userspace-audit code 中找到它。

另一个流行的库 slackhq/go-audit 似乎不依赖标头长度,而是根据从套接字读取的缓冲区大小进行解析。

mdlayher/netlink 库上的这个差异似乎解决了上述问题,并且还可以获得有效负载的字节转储。但事实并非如此。

diff --git a/conn_linux.go b/conn_linux.go
index ef18ef7..561ac69 100644
--- a/conn_linux.go
+++ b/conn_linux.go
@@ -11,6 +11,8 @@ import (
        "time"
        "unsafe"

+       "github.com/davecgh/go-spew/spew"
+       "github.com/josharian/native"
        "golang.org/x/net/bpf"
        "golang.org/x/sys/unix"
 )
@@ -194,7 +196,13 @@ func (c *conn) Receive() ([]Message, error) {

        raw, err := syscall.ParseNetlinkMessage(b[:n])
        if err != nil {
-               return nil, err
+               spew.Dump(b[:n])
+               bl := native.Endian.Uint32(b[:4]) + syscall.NLMSG_HDRLEN
+               native.Endian.PutUint32(b[:4], bl)
+               raw, err = syscall.ParseNetlinkMessage(b[:n])
+               if err != nil {
+                       return nil, err
+               }
        }

        msgs := make([]Message, 0, len(raw))

重现上述行为的代码


更新 1

当我尝试通过 AUDIT_SET 消息类型更改审核状态时,似乎会出现上述行为。如果我尝试连接到只读多播组 AUDIT_NLGRP_READLOG ,它似乎不会发生。另外,如果我关闭单播连接然后尝试多播,问题又回来了。基本上,只要我的 PID 绑定到套接字,这个问题就会再次出现。 仅通过多播组连接时的示例转储

([]uint8) (len=76 cap=4096) {
 00000000  49 00 00 00 1d 05 00 00  00 00 00 00 00 00 00 00  |I...............|
 00000010  61 75 64 69 74 28 31 36  31 32 31 36 35 31 33 31  |audit(1612165131|
 00000020  2e 30 31 36 3a 33 33 34  37 32 29 3a 20 61 72 67  |.016:33472): arg|
 00000030  63 3d 32 20 61 30 3d 22  61 75 64 69 74 63 74 6c  |c=2 a0="auditctl|
 00000040  22 20 61 31 3d 22 2d 73  22 00 00 00              |" a1="-s"...|
}

注意如果 0x49 = 73 的大小,确切的数据包长度。


【解决方案1】:

所以我个人对此一无所知,但我通过搜索找到了这个问题,该搜索的另一个结果是这篇博客文章: https://blog.des.no/2020/08/netlink-auditing-and-counting-bytes/

总而言之,其他人也发现了这种行为,这似乎是一个错误。 以下是相关引述:

错误 #3 :审计数据消息的长度字段不包括 标题的长度。

这令人瞠目结舌。这是根本错误的。代表着 任何想使用自己的代码与审计子系统对话的人 而不是 libaudit 将不得不向 Netlink 层添加一个解决方法 他们的堆栈来修复或忽略错误,并应用它 解决方法 仅适用于某些消息类型

这是怎么被忽视的?好吧,libaudit 没有做太多的输入 验证。

(...)

这些错误得到修复的几率几乎为零,因为 如果内核以有趣的方式破坏现有应用程序 开始正确设置长度字段。