On Sun, Nov 12, 2023 at 11:52 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > 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. We don't actually store SECCLASS_FD in any security blobs currently (i.e. there is no sclass field in the file_security_struct); we just always check against SECCLASS_FD in file_has_perm(), selinux_binder_transfer_file(), ioctl_has_perm(), selinux_kernel_module_from_file(). As you note, we don't have a way of knowing what kind of fd it is at those points so we would need to somehow pass that information to selinux_file_alloc_security() and save the class at that time, or otherwise introduce new hooks. There are three approaches that could be taken here: 1. Introduce new permissions on the existing class, as proposed by Chris, 2. Introduce new classes, as you proposed, 3. Label different kinds of fds via type_transitions or similar so that we can distinguish them by type in policy rather than needing separate permissions or classes. We've used all three approaches in the past for different kinds of checks so it is more a question of what is optimal for this use case. The last one is the heaviest approach since it imposes extra overhead upon allocation/labeling that doesn't currently exist for fds. All that said, I am not entirely sure how useful the current fd use permission is, nor how useful these finer-grained checks will be. Fedora policy by default allows every domain to use every other domain's fds (controllable via domain_fd_use boolean, default is true). Android I think is more selective.
