Hello, It has been reported to me that read/write syscalls on a pipe created via the pipe(2) family of syscalls spend a large percentage of time in avc_lookup() via selinux_file_permission(). This is specific to pipes (and also accept(2)'d sockets, I think) because these pipe fds are created using alloc_file_pseudo() as opposed to do_dentry_open(), which means that the security_file_open() hook is never called on them. In SELinux, this means that in selinux_file_permission() the read/write permission is always revalidated, leading to suboptimal performance, because SELinux re-checks the read/write perms of an open file only if the subject/target label or policy is different from when these permissions were checked during selinux_file_open(). So I decided to try and see what would happen if I add a security_file_open() call to alloc_file(). This worked well for pipes - all domains that call pipe(2) seem to already have the necessary permissions to pass the open check, at least in Fedora policy - but I got lots of denials from accept(2), which also calls alloc_file() under the hood to create the new socket fd. The problem there is that programs usually call only recvmsg(2)/sendmsg(2) on fds returned by accept(2), thereby avoiding read/write checks on sock_file, which means that the domains don't normally have such permissions. Only programs that open actual socket files on the filesystem would unavoidably need read/write (or so I think), yet they wouldn't need them for the subsequent recvmsg(2)/sendmsg(2) calls. So I'm wondering if anyone has any idea how this could be fixed (optimized) without introducing regressions or awkward exceptions in the code. At this point, I don't see any way to do it regression-free without either adding a new hook or changing security_file_open() to distinguish between do_dentry_open() and alloc_file() + calling it from both places... -- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc.
