Messages in this thread | | | Subject | Re: [PATCH 2/3] Teach SELinux about anonymous inodes | From | Stephen Smalley <> | Date | Fri, 14 Feb 2020 13:02:43 -0500 |
| |
On 2/14/20 12:21 PM, Daniel Colascione wrote: > On Fri, Feb 14, 2020 at 8:38 AM Stephen Smalley <sds@tycho.nsa.gov> wrote: >> That's assuming you are ok with having to define these type_transition >> rules for the userfaultfd case instead of having your own separate >> security class. Wondering how many different anon inode names/classes >> there are in the kernel today and how much they change over time; for a >> small, relatively stable set, separate classes might be ok; for a large, >> dynamic set, type transitions should scale better. > > I think we can get away without a class per anonymous-inode-type. I do > wonder whether we need a class for all anonymous inodes, though: if we > just give them the file class and use the anon inode type name for the > type_transition rule, isn't it possible that the type_transition rule > might also fire for plain files with the same names in the last path > component and the same originating sid? (Maybe I'm not understanding > type_transition rules properly.) Using a class to encompass all > anonymous inodes would address this problem (assuming the problem > exists in the first place).
It shouldn't fire for non-anon inodes because on a (non-anon) file creation, security_transition_sid() is passed the parent directory SID as the second argument and we only assign task SIDs to /proc/pid directories, which don't support (userspace) file creation anyway.
However, in the absence of a matching type_transition rule, we'll end up defaulting to the task SID on the anon inode, and without a separate class we won't be able to distinguish it from a /proc/pid inode. So that might justify a separate anoninode or similar class.
This however reminded me that for the context_inode case, we not only want to inherit the SID but also the sclass from the context_inode. That is so that anon inodes created via device node ioctls inherit the same SID/class pair as the device node and a single allowx rule can govern all ioctl commands on that device.
| |