lkml.org 
[lkml]   [2019]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2]
    From
    Date
    On 6/4/2019 1:39 PM, David Howells wrote:
    > Andy Lutomirski <luto@kernel.org> wrote:
    >
    >>> Here's a set of patches to add a general variable-length notification queue
    >>> concept and to add sources of events for:
    >> I asked before and didn't see a response, so I'll ask again. Why are you
    >> paying any attention at all to the creds that generate an event?
    > Casey responded to you. It's one of his requirements.

    Process A takes an action. As a result of that action,
    an event is written to Process B's event buffer. This isn't
    a covert channel, it's a direct access, just like sending
    a signal. Process A is the subject and the event buffer,
    which is part of Process B, is the object.


    > I'm not sure of the need, and I particularly don't like trying to make
    > indirect destruction events (mount destruction keyed on fput, for instance)
    > carry the creds of the triggerer. Indeed, the trigger can come from all sorts
    > of places - including af_unix queue destruction, someone poking around in
    > procfs, a variety of processes fputting simultaneously. Only one of them can
    > win, and the LSM needs to handle *all* the possibilities.

    Yes, it's a hairy problem. It was a significant factor in the
    demise of kdbus.

    > However, the LSMs (or at least SELinux) ignore f_cred and use current_cred()
    > when checking permissions. See selinux_revalidate_file_permission() for
    > example - it uses current_cred() not file->f_cred to re-evaluate the perms,
    > and the fd might be shared between a number of processes with different creds.
    >
    >> This seems like the wrong approach. If an LSM wants to prevent covert
    >> communication from, say, mount actions, then it shouldn't allow the
    >> watch to be set up in the first place.
    > Yeah, I can agree to that. Casey?

    Back to your earlier point, you don't know where the
    event is coming from when you create the event watch.
    If you enforce a watch time, what are you going to check?
    Isn't this going to be considered too restrictive?


    \
     
     \ /
      Last update: 2019-06-04 23:13    [W:2.362 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site