On Thu, Nov 9, 2023 at 1:26 PM Chris PeBenito <chpebeni@xxxxxxxxxxxxxxxxxxx> wrote: > > systemd is increasing usage of memfds, pidfds, etc. This is resulting > in a need for wide inheritance of fds across the system. For example in > a lot of systemd interfaces that have a pid field now have a comparable > pidfd interface. dbus-broker and polkit are similarly updated. > > Some references from an All Systems Go! talk: > https://cfp.all-systems-go.io/media/all-systems-go-2023/submissions/T3LJAM/resources/ASG_2023_PID_FD-ize_all_the_things_E98Zw9Q.pdf > This is from a few months ago; the switch to PIDFDs is nearly > complete, and we're already seeing denials for this usage. > > > Since file descriptors are increasing use as references for various > operations, I think it would be useful to have a finer-grained fd class, > so we can limit file descriptor inheritance, particularly as it looks > like systemd/pid1 will need to inherit pidfd file descriptors from > possibly all domains. Specifically, I propose adding new permissions to > the fd class, such as use_pidfd and use_memfd. Then systemd can use > pidfds from any domain, but only use regular fds from trusted domains. > > Thoughts? I think adding some granularity to the fd:use permission makes sense, although I'm wondering if we are better served by creating new object classes for these new types of reference fds, e.g. pidfd:use, memfd:user, etc.? When I read "use_pidfd" my first thought is that we are encoding an object class in the permission. Have you looked at the associated kernel code yet? I suspect we might need to augment the existing memfd/pidfd/etc. code paths with an additional LSM hook to be able to mark the fd's LSM/SELinux state with class info, but I'm not sure off the top of my head. -- paul-moore.com
