lkml.org 
[lkml]   [2020]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/3] Teach SELinux about anonymous inodes
From
Date
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.

\
 
 \ /
  Last update: 2020-02-14 21:24    [W:0.078 / U:2.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site