On 2/14/20 1:08 PM, Stephen Smalley wrote:
On 2/14/20 1:02 PM, Stephen Smalley wrote:
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.
At least that's the way our patch worked with the /dev/kvm example.
However, if we are introducing a separate anoninode class for the
type_transition case, maybe we should apply that to all anon inodes
regardless of how they are labeled (based on context_inode or
transition) and then we'd need to write two allowx rules, one for ioctls
on the original device node and one for those on anon inodes created
from it. Not sure how Android wants to handle that as the original
developer and primary user of SELinux ioctl whitelisting.
I would tentatively argue for inheriting both sclass and SID from the
context_inode for the sake of sane policy writing. In the userfaultfd
case, that will still end up using the new SECCLASS_ANONINODE or
whatever since the sclass will be initially set to that value for the
transition SID case and then inherited on fork. But for /dev/kvm, it
would be the class from the /dev/kvm inode, i.e. SECCLASS_CHR_FILE.
