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 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.








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