ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

osquery 内嵌 libaudit(Linux Audit 用户空间库)的构建与集成深度解析

osquery 内嵌 libaudit(Linux Audit 用户空间库)的构建与集成深度解析 观测代理网络安全【免费下载链接】osquerySQL powered operating system instrumentation, monitoring, and analytics.项目地址https://gitcode.com/gh_mirrors/os/osquery点击查看免费下载导读本文以 osquery 仓库中 libaudit 构建说明 为骨架完整还原 Linux Audit 用户空间库libaudit在 osquery 中的静态交叉编译流程并结合仓库源码剖析其构建产物如何被 CMake 集成、生成的系统调用表头如何按架构落地、以及 osquery 的 Audit 事件发布器如何调用 libaudit API 读取内核 netlink 审计流。读完本文你将掌握 osquery 第三方 C 库的离线构建范式、config.h/生成头文件的分发布局以及process_events、socket_events等审计表背后的底层依赖链。1. libaudit 在 osquery 中的角色审计功能的地基osquery 在 Linux 平台上借助内核 Audit 子系统实现进程执行与网络连接的近实时记录对应表为process_events与socket_events详见 process-auditing 文档。这些事件的采集由 osquery/events/linux/ 下的 Audit 事件发布器完成而它与内核审计子系统通信所依赖的用户空间库正是libauditLinux 内核 audit 子系统的官方用户空间工具包仓库内对应上游版本为 audit 2.4.3见 config.h 版本宏。一个关键事实运行时 osquery并不要求系统安装 auditd 或 libaudit它只使用内核自带 audit 功能因此 libaudit 必须以静态形式内嵌进 osquery 二进制。这正是本仓库将 libaudit 作为third_party 源码子模块纳入libraries/cmake/source/的原因。2. 构建环境前提Toolchain 与最低 glibc 约束原文档明确指出该构建方案基于Ubuntu 14.04glibc 2.12并用如下命令验证ldd --version ldd (GNU libc) 2.12.2选择如此低的 glibc 基线是为了让构建出的静态库能够兼容更广泛的旧发行版运行环境——静态链接进 osquery 后库的 glibc 符号依赖不能高于目标运行环境。因此构建主机必须是足够旧的发行版或等价 glibc 环境这是复现该构建流程的最重要前提。此外整个编译使用 osquery 自带的 LLVM/clang 工具链/usr/local/osquery-toolchain而非系统 gcc以保证编译期行为与 osquery 主体一致、并利用其 sysroot 实现隔离式交叉构建。3. 交叉编译环境变量配置逐项解析构建前需导出以下环境变量将工具链与 sysroot 注入编译过程export PATH/usr/local/osquery-toolchain/usr/bin:$PATH export CFLAGS--sysroot /usr/local/osquery-toolchain export CXXFLAGS${CFLAGS} export LDFLAGS${CFLAGS} export CCclang export CXXclang变量作用PATH将 osquery toolchain 的 bin 目录置于最前确保clang、autoconf等工具优先来自工具链CFLAGS通过--sysroot指定工具链根目录让编译器在该目录下查找头文件与库实现与宿主系统隔离CXXFLAGS继承CFLAGS覆盖 C 编译本库为纯 C但保持一致无副作用LDFLAGS同样继承 sysroot保证链接阶段也只在工具链内解析依赖CC/CXX显式指定clang/clang作为编译器注意此时不能依赖系统自带的 autoconf 产物因为 configure 脚本会探测宿主环境特性并写入config.hsysroot 的作用正是让探测结果反映 toolchain 目标环境而非宿主环境。4. 三步构建流程autogen → configure → make4.1 生成构建脚本./autogen.shautogen.sh依次驱动 autoconf 系列工具autoreconf/autoheader 等从configure.ac生成configure脚本与config.h.in模板。仓库内 config.h 的文件头注释即为佐证/* config.h. Generated from config.h.in by configure. */ /* config.h.in. Generated from configure.ac by autoheader. */4.2 配置静态库并启用多架构表./configure --enable-static --with-arm --with-aarch64配置项含义--enable-static生成静态库.a这是 osquery 内嵌链接的前提--with-arm生成 32 位 ARM 架构的系统调用编号表--with-aarch64生成 64 位 ARMAArch64架构的系统调用编号表libaudit 需要将架构相关的系统调用号映射为字符串供审计记录解析时把syscall59还原为execve这些映射表是构建期用 perl 脚本从内核头文件生成的。除 ARM 外libaudit 原生支持 i386、ia64、ppc、s390、s390x、x86_64 等架构见下节 generated 目录的文件清单。4.3 仅编译 lib 子目录(cd lib make)只编译lib/下的库源码不构建auditctl、ausearch、auparse等二进制工具符合 osquery 只取所需 的第三方库裁剪策略。5. 构建产物分发生成的系统调用表头与 config.h5.1 复制 17 个生成头文件构建完成后将lib/下生成的架构表头复制到仓库的generated/目录for header in aarch64_tables actiontabs arm_tables errtabs fieldtabs flagtabs ftypetabs gen_tables i386_tables ia64_tables machinetabs msg_typetabs optabs ppc_tables s390_tables s390x_tables x86_64_tables; \ do cp ./lib/${header}.h ../generated/${header}.h; \ done这 17 个头文件可分为两类架构系统调用表8 个aarch64_tables.h、arm_tables.h、i386_tables.h、ia64_tables.h、ppc_tables.h、s390_tables.h、s390x_tables.h、x86_64_tables.h消息/字段解析表9 个actiontabs.h、errtabs.h、fieldtabs.h、flagtabs.h、ftypetabs.h、gen_tables.h、machinetabs.h、msg_typetabs.h、optabs.h。它们均已随仓库分发在 libraries/cmake/source/libaudit/generated/。以 aarch64_tables.h 为例其内容是把accept、execve、execveat、connect、bind等系统调用名压入字符串表并配套索引偏移表——osquery 的socket_events监听bind/connect与process_events监听execve/execveat正是依赖这类映射来解码审计记录。5.2 按架构分发 config.hcp ./config.h ../config/ARCH/config.hconfig.h是 configure 探测结果的固化产物记录了平台特性宏如HAVE_CLOCK_GETTIME、HAVE_EPOLL_CTL、HAVE_INOTIFY_INIT等。仓库内按目标架构分发为两份config/x86_64/config.hconfig/aarch64/config.h对比可见x86_64 与 aarch64 两份配置在SIZEOF_UNSIGNED_LONG、WITH_AARCH64、WITH_ARM等宏上存在差异这正是必须按架构分别固化配置的原因。6. 仓库落地形态与 CMake 集成6.1 src 以 git 子模块方式引入libaudit/src/目录在仓库中为空其源码通过 Findlibaudit.cmake 的importSourceSubmodule(NAME libaudit SUBMODULES src)机制按需拉取。也就是说README 描述的 autogen/configure/make 流程是在子模块源码被下载后于本地执行的产出的头文件与 config.h 则固化进仓库从而让 osquery 的常规构建不依赖网络与 autotools。6.2 CMake 侧静态编译 7 个源文件libaudit/CMakeLists.txt 定义了thirdparty_libaudit目标仅编译 libaudit 库的最小核心子集lib/audit_logging.c、lib/deprecated.c、lib/libaudit.c、lib/lookup_table.c、lib/message.c、lib/netlink.c、lib/strsplit.c并施加私有编译宏_GNU_SOURCE、HAVE_CONFIG_H、PIC其中HAVE_CONFIG_H让源码包含config.h对应上一节按架构分发的配置_GNU_SOURCE启用 GNU 扩展 API如recvfrom需要的特性宏PIC保证生成位置无关代码便于链接进 osquery 可执行文件。头文件搜索路径按顺序为config/${TARGET_PROCESSOR}架构相关 config.h→generated/架构表头→src库源码→src/auparse→src/lib。其中TARGET_PROCESSOR正是编译期决定使用 x86_64 还是 aarch64 配置的关键变量。7. 源码级验证osquery 如何消费 libaudit APIosquery 的 Audit 事件发布器位于 osquery/events/linux/auditdnetlink.h 与 auditdnetlink.cpp二者直接#include libaudit.h构成了对 libaudit 的完整使用证据netlink 句柄管理通过 libaudit 的 netlink 句柄audit_netlink_handle_见 auditdnetlink.h与内核 audit 子系统通信audit_close()负责释放见 auditdnetlink.cpp状态查询audit_request_status()获取审计状态据此判断审计是否可用auditdnetlink.cpp性能与缓冲调参audit_set_backlog_wait_time()、audit_set_backlog_limit()、audit_set_failure()分别设置 backlog 等待时间、backlog 上限与失败模式auditdnetlink.cpp与 CLI 标志--audit_backlog_wait_time默认 0、--audit_backlog_limit默认 4096一一对应auditdnetlink.cpp事件读取数据通过recvfrom()从 netlink socket 读取auditdnetlink.cpp读取侧与解析侧由 AuditdNetlinkReader / AuditdNetlinkParser 两个线程协作中间经AuditdContext共享未处理记录与已解析事件队列规则安装configureAuditService()依据--audit_allow_config等标志向内核安装审计规则监听execve/execveat/bind/connect等系统调用安装过的规则在退出时由restoreAuditServiceConfiguration()还原。由此可见libaudit 提供的是打开句柄 状态查询 规则管理 backlog 调优的成套 APIosquery 在其之上构建了完整的读取→解析→发布审计流水线。8. 延伸审计相关的运行时配置虽然构建层面只需按上文产出静态库但若要真正启用审计表运行时还需配合相应 CLI 标志详见 process-auditing 文档--disable_auditfalse允许 osquery 打开内核 audit 的 netlink socket默认true关闭--audit_allow_configtrue允许 osquery 修改审计配置安装/删除规则、设置全局使能标志与性能参数--audit_allow_process_eventstrue启用process_events--audit_allow_sockets启用socket_events需单独开启因为负载较高。同时需确保auditd服务未运行否则会与osqueryd争抢 audit netlink socket且--audit_persisttrue会让 osquery 在句柄被抢占后尝试重新获取。9. 小结从上游 audit 2.4.3 源码到本仓库的固化产物再到 osquery 运行时对 libaudit API 的调用整个链路清晰完整低 glibc 基线的老发行版 osquery clang toolchain提供可复现的构建环境autogen → configure--enable-static --with-arm --with-aarch64→ make产出静态库、架构表头与 config.h17 个生成头 按架构分发的 config.h固化进仓库generated/与config/ARCH/CMake通过子模块引入源码并以最小源文件集静态编译auditdnetlink在运行时使用 libaudit API 与内核审计子系统交互支撑process_events/socket_events表。对想要复现或改造该构建流程的开发者建议从 libaudit/README.md 出发对照 libaudit/CMakeLists.txt 与 auditdnetlink.cpp 按图索骥若需新增目标架构则要同时更新 autogen 阶段的--with-*参数、generated 表头以及config/ARCH/config.h三处。赞分享观测代理网络安全【免费下载链接】osquerySQL powered operating system instrumentation, monitoring, and analytics.项目地址https://gitcode.com/gh_mirrors/os/osquery点击查看免费下载相关推荐原神启动器Plus上手指南国服国际服切换只要点两下顺带解锁60帧原神启动器Plus上手指南国服国际服切换只要点两下顺带解锁60帧 晚上十一点好友发来消息国际服周本就差你了。你心算了一下流程退出游戏、翻出教程、桌面应用eBPF 与 Linux 事件采集从 Audit 框架到 osquery 的 bpf_process_events / bpf_socket_events 实战解析eBPF 与 Linux 事件采集从 Audit 框架到 osquery 的 bpf_process_events / bpf_socket_events 实后端前端企业应用运维网络安全osquery 中 libdevmapperLVM2的 Linux 静态构建指南与源码级集成解析osquery 中 libdevmapperLVM2的 Linux 静态构建指南与源码级集成解析 libdevmapper 是 LVM2Logical V观测代理网络安全上一篇GPT-OSS-120B 4-bit 量化版完全指南OpenAI开源大模型在单张H100 GPU上的终极部署方案下一篇HCB分布式锁应用Redis确保跨服务数据一致性创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进