On 6/4/2019 1:39 PM, David Howells wrote: > Andy Lutomirski <luto@xxxxxxxxxx> 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?
