On Tue, 2006-06-27 at 14:35 -0400, Stephen Smalley wrote: > On Tue, 2006-06-27 at 12:29 -0500, Kris Wilson wrote: > > inotify_init > > This creates an inotify object. Question is how it would end up being > labeled and subsequently controlled if it can be shared between > processes. Seems a bit suspect - not sure why genfs is being used for > inotifyfs in the policy; I'd have expected it to use fs_use_task, > similar to pipes. Then the inodes would inherit the level of the > creating task, and the checks on execve and/or local IPC would control > sharing.
Correction: There is only one inode object (the root of the inotifyfs filesystem); all of the inotify instances/objects reference it. So the only distinct object that SELinux sees for checking purposes is the struct file (open file description), and that will get the creating task's SID, and that would be checked by the fd use permission check when the descriptor is inherited, passed over local IPC, or read from. However, current MLS policy doesn't impose constraints on fd use permission. futex fds are similar; they share a reference to a single inode object. epoll fds get their own inodes, so the inode label could reflect the creating task label if we use fs_use_task for eventpollfs (currently uses genfs_contexts, but could be changed), as we do for pipefs (for pipes). -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
