☰

systemd DynamicUser= 服务与日志拆分

tag-icon • tag-icon systemd security systemd-journald uid
systemd DynamicUser= 服务与日志拆分

systemd-journald具有默认配置SplitMode=uid，为每个用户创建单独的日志（日志）文件，并允许他们读取。

当使用 运行服务时DynamicUser=，这是否意味着该服务可以读取随机旧DynamicUser=服务的日志？

如果是这样，是否存在能够读取不完全属于您自己的日志文件的潜在问题（安全性？）？

编辑：肯定有人担心 systemd 将核心转储保存为单独的文件或日志中？ （系统核心转储）

DynamicUser= 的博客文章在讨论重用 UID 的影响时没有提及该期刊。

http://0pointer.net/blog/dynamic-users-with-systemd.html

您可能想知道为什么当注册系统用户的包从系统中卸载时（至少在大多数发行版上），系统用户通常不会被释放。其原因是用户概念的一个相关属性（您甚至可能希望将其称为设计缺陷）：用户 ID 与文件（以及其他对象，例如 IPC 对象）粘在一起。如果以特定系统用户身份运行的服务在某个位置创建一个文件，然后终止并删除其包和用户，则创建的文件仍属于系统用户最初分配的数字 ID（“UID”）。当分配下一个系统用户时，由于 ID 回收，碰巧被分配了相同的数字 ID，那么它也将获得对该文件的访问权限，这通常被认为是一个问题，因为该文件属于可能非常不同的文件服务从前，并且很可能不应该被其后的任何内容读取或更改。因此，分配倾向于避免 UID 回收，这意味着系统用户在分配一次后将永远在系统上注册。

...

为了解决这个问题，我很容易想到两种策略：

  1. 禁止服务创建任何文件/目录或IPC对象

  2. 自动删除服务关闭时创建的文件/目录或 IPC 对象。

在 systemd 中，我们实现了这两种策略，但是针对执行环境的不同部分......

答案1

这不存在安全问题。 （我检查了 systemd v239）。

DynamicUser= 使用的 UID 范围内的用户无法读取自己的 systemd 日志或 systemd 核心转储。同样的限制适用于“系统”用户（通常 UID < 1000）和nobody.

https://github.com/systemd/systemd/blob/v239/src/coredump/coredump.c#L157

if (uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY)
        return 0;


/* Make sure normal users can read (but not write or delete)
 * their own coredumps */

https://github.com/systemd/systemd/blob/v239/src/journal/journald-server.c#L225

static bool uid_for_system_journal(uid_t uid) {

        /* Returns true if the specified UID shall get its data stored in the system journal*/

        return uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY;
}

答案2

SplitMode=uid 只是意味着日志被分成针对每个用户的不同 systemd 实例的不同文件，对于 uid 1000 的 systemd，一个用于 pid1（系统日志），并且访问模式由日志守护进程相应设置。目前，你不能以任何其他方式分割它，我认为这是一种耻辱。

相关内容