On Mon, Mar 20, 2023 at 3:25 AM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > > > Hi, > > I was reading this pull request [1] and looked into how I might be able > to implement this in policy but there seem to be some technical > difficulties. > > * I already use getfscon to seperate the systemd user.slice because the > system manager delegates the user.slice to the user manager. > > (genfscon "cgroup2" "/user.slice" cgroupfile_context) > > In the past the proved to be a racy where systemd attempts to > write before the object has the context associated with the genfscon. I don't understand how this could be racy - genfscon-assigned contexts should be assigned when the dentry is first instantiated via inode_donit_with_dentry and therefore the inode shouldn't be accessible to userspace prior to this initial assignment AFAIK. Possibly I am missing something. > I decided to dontaudit attempts to write to the mislabeled object and > it *seems* as if systemd retries until it can write it i.e. when the > object carries the expected label and so that seems to work eventually > but it looks fragile. > > * The challenge with memory pressure implementation [2] is that these > "memory.pressure" files end up in random locations under > "/system.slice" for example: > > /sys/fs/cgroup/system.slice/systemd-journald.service/memory.pressure > > Where in the above systemd-journald.service might be > templated (systemd-journald@FOO.service). Point is that the path is > random. genfscon does not support regex and glob. I can't do for example: > > (genfscon "cgroup2" "/system.slice/.*/memory.pressure" > cgroupfile_context) > > Fortunately cgroup2fs supports relabeling but if systemd has to > manually relabel the cgroup files then I would imagine that this is > racy as well, and that does not really solve the underlying issue. > > I am looking for ideas and suggestions Optimally one of two things would happen: 1. The kernel would label the inode correctly when it is first created (e.g. by augmenting genfscon to support more general matching), or 2. The userspace component that creates these files would label them correctly at creation (via setfscreatecon() prior to creation). Pardon my ignorance but what creates these files initially? The kernel in response to some event or systemd or some other userspace component? > [1] https://github.com/SELinuxProject/refpolicy/pull/607 > [2] https://github.com/systemd/systemd/blob/main/docs/MEMORY_PRESSURE.md
