From: Chris PeBenito <pebenito@ieee.org>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: Paul Moore <paul@paul-moore.com>,
Ondrej Mosnacek <omosnace@redhat.com>,
SElinux mailing list <selinux@vger.kernel.org>
Subject: Re: cgroup2 labeling status
Date: Mon, 6 May 2024 09:32:52 -0400 [thread overview]
Message-ID: <485379b5-93c2-4f24-86b8-e101ed7bc3c6@ieee.org> (raw)
In-Reply-To: <CAEjxPJ66_2jic8erKo6RBE4psXxF3AK=1jvS7ERpB7Hmot0PCw@mail.gmail.com>
On 5/3/2024 8:00 AM, Stephen Smalley wrote:
> On Thu, May 2, 2024 at 3:16 PM Chris PeBenito <pebenito@ieee.org> wrote:
>>
>> On 5/2/2024 2:53 PM, Stephen Smalley wrote:
>>> On Thu, May 2, 2024 at 2:37 PM Chris PeBenito <pebenito@ieee.org> wrote:
>>>>
>>>> The state of cgroup2 labeling and memory.pressure came up for me again.
>>>> This was discussed March last year[1]. To summarize, refpolicy has a
>>>> type_transition for the memory.pressure file in cgroup2 to a default of
>>>> memory_pressure_t. For example this file:
>>>>
>>>> /sys/fs/cgroup/system.slice/systemd-journald.service/memory.pressure
>>>>
>>>> with the idea that we allow daemons to write to this without allowing
>>>> writes to all cgroup_t. Unfortunately, the thread ended and I haven't
>>>> seen any improvement.
>>>>
>>>> The conclusion was[3]:
>>>>
>>>>> Ah, now I remembered that we made it such that the transitions would
>>>>> only apply if the parent directory has a label explicitly set by
>>>>> userspace (via setxattr). Not sure if we can improve it easily, since
>>>>> we can't use the normal inode-based logic for cgroupfs (the xattrs are
>>>>> stored in kernfs nodes, each of which can be exposed via multiple
>>>>> inodes if there is more than one cgroupfs mount).
>>>>
>>>> Testing on a 6.6 kernel and systemd 255, I still see the same issues,
>>>> where most are stuck at cgroup_t, with user.slice entries get
>>>> memory_pressure_t[2]. Based on my investigations, the user.slice works
>>>> because systemd sets the user.invocation_id xattr on these dirs.
>>>>
>>>> Next, I tried modifying systemd to use it's version of
>>>> setfscreatecon()+mkdir() when it creates the cgroup directories. This
>>>> did not change the labeling behavior. Next I changed the code to a
>>>> post-mkdir setfilecon() and then all the memory.pressures finally had
>>>> expected labeling.
>>>>
>>>> This setxattr() requirement is unfortunate, and the fact the
>>>> setfscreatecon() doesn't work makes it more unfortunate. Is there any
>>>> improvement being worked?
>>>
>>> Possibly I misunderstand, but selinux_kernfs_init_security() appears
>>> to honor the create_sid (setfscreatecon) if set, so I would have
>>> expected that to work.
>>
>> Does there need to be an xattr on the cgroup2 fs root directory for this
>> to work? Based on the tracing I did on the systemd code, the post-mkdir
>> setfilecon() would have happened on the root dir, but the
>> setfscreatcon() version of the code change obviously wouldn't have
>> changed anything when it ran on the cgroup2 root dir.
>
> That could be the case, based on Ondrej's statement on the earlier
> thread. So it isn't a limitation of the SELinux code per se but rather
> the cgroup2/kernfs code.
I think I've reached the end of what I can debug from userspace. I
changed the genfscon to no_access_t so it would be obvious where the
genfs label was still in use on a file. It indicated a relabel is
needed due to entries being created during initramfs, despite systemd
supposedly relabeling /sys/fs/cgroup (still looking into this) just
after loading the policy. I added a tmpfiles.d entry to get the fs
relabeled and retried the setfscreatecon() version and the results were
quite weird:
root [ /home/pebenito ]# ls -lZ /sys/fs/cgroup/*/*/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:cgroup_t:s0 0 May 6 12:21
/sys/fs/cgroup/system.slice/auditd.service/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:memory_pressure_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/boot-efi.mount/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:cgroup_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/chronyd.service/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:cgroup_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/crond.service/memory.pressure
-rw-r--r--. 1 messagebus messagebus
system_u:object_r:cgroup_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/dbus.service/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:cgroup_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/hypervkvpd.service/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:cgroup_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/hypervvssd.service/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:cgroup_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/irqbalance.service/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:cgroup_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/sshd.service/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:memory_pressure_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/sysroot.mount/memory.pressure
-rw-r--r--. 1 root root
system_u:object_r:memory_pressure_t:s0 0 May 6 12:19
/sys/fs/cgroup/system.slice/system-getty.slice/memory.pressure
[...]
In case it was due to entries created in the initramfs, I tried
restarting auditd and still got cgroup_t on the memory.pressure. I
added a type_transition for all domains, but still get cgroup_t. I
can't explain why some memory.pressures would get the expected label,
but others not.
--
Chris PeBenito
prev parent reply other threads:[~2024-05-06 13:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 18:37 cgroup2 labeling status Chris PeBenito
2024-05-02 18:53 ` Stephen Smalley
2024-05-02 19:16 ` Chris PeBenito
2024-05-03 12:00 ` Stephen Smalley
2024-05-06 13:32 ` Chris PeBenito [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=485379b5-93c2-4f24-86b8-e101ed7bc3c6@ieee.org \
--to=pebenito@ieee.org \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).