On Thu, Feb 13, 2020 at 2:41 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > Add support for labeling and controlling access to files attached to anon > inodes. Introduce extended interfaces for creating such files to permit > passing a related file as an input to decide how to label the anon > inode. Define a security hook for initializing the anon inode security > attributes. Security attributes are either inherited from a related file > or determined based on some combination of the creating task and policy > (in the case of SELinux, using type_transition rules). As an > example user of the inheritance support, convert kvm to use the new > interface for passing the related file so that the anon inode can inherit > the security attributes of /dev/kvm and provide consistent access control > for subsequent ioctl operations. Other users of anon inodes, including > userfaultfd, will default to the transition-based mechanism instead. > > Compared to the series in > https://lore.kernel.org/selinux/20200211225547.235083-1-dancol@xxxxxxxxxx/, > this approach differs in that it does not require creation of a separate > anonymous inode for each file (instead storing the per-instance security > information in the file security blob), it applies labeling and control > to all users of anonymous inodes rather than requiring opt-in via a new > flag, it supports labeling based on a related inode if provided, > it relies on type transitions to compute the label of the anon inode > when there is no related inode, and it does not require introducing a new > security class for each user of anonymous inodes. > > On the other hand, the approach in this patch does expose the name passed > by the creator of the anon inode to the policy (an indirect mapping could > be provided within SELinux if these names aren't considered to be stable), > requires the definition of type_transition rules to distinguish userfaultfd > inodes from proc inodes based on type since they share the same class, > doesn't support denying the creation of anonymous inodes (making the hook > added by this patch return something other than void is problematic due to > it being called after the file is already allocated and error handling in > the callers can't presently account for this scenario and end up calling > release methods multiple times), and may be more expensive > (security_transition_sid overhead on each anon inode allocation). > > We are primarily posting this RFC patch now so that the two different > approaches can be concretely compared. We anticipate a hybrid of the > two approaches being the likely outcome in the end. In particular > if support for allocating a separate inode for each of these files > is acceptable, then we would favor storing the security information > in the inode security blob and using it instead of the file security > blob. Bringing this back up in hopes of attracting some attention from the fs-devel crowd and Al. As Stephen already mentioned, from a SELinux perspective we would prefer to attach the security blob to the inode as opposed to the file struct; does anyone have any objections to that? -- paul moore www.paul-moore.com
