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

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《审核 netlink 响应没有正确的数据包长度》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

我一直在尝试使用 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): ...|
}

这是来自日志流的消息之一。根据数据包结构，前16个字节是netlink消息头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 如何标记为消息的 长度（包括 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 及其工具系列的用户空间审核代码中弄清楚这一点。

另一个流行的库，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))

用于重现上述行为的代码

• 读取审核日志的代码：https://play.golang.com/p/kj4dol0pkrq
• 查看 golang 如何解析不同数据包的代码：https://play.golang.com/p/ma7_mjdvsv8
• audit.h 文件：include/audit.h
• uname -a：linux linux-dev 4.15.0-135-generic #139-ubuntu smp 1 月 18 日星期一 17:38:24 utc 2021 x86_64 x86_64 x86_64 gnu/linux

更新 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，则大小是确切的数据包长度。

解决方案

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

总而言之，其他人也发现了这种行为，而且它似乎是一个错误。 以下是相关引用：

错误#3：审核数据消息的长度字段不包括 标头的长度。

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

这怎么会被忽视呢？好吧，libaudit 没有做太多输入 验证。

(...)

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

理论要掌握，实操不能落！以上关于《审核 netlink 响应没有正确的数据包长度》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！