From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58AF7C28CC6 for ; Tue, 4 Jun 2019 20:39:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 331D2207E0 for ; Tue, 4 Jun 2019 20:39:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726674AbfFDUjt convert rfc822-to-8bit (ORCPT ); Tue, 4 Jun 2019 16:39:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60664 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726033AbfFDUjt (ORCPT ); Tue, 4 Jun 2019 16:39:49 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 946E83001461; Tue, 4 Jun 2019 20:39:43 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-120-173.rdu2.redhat.com [10.10.120.173]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3D0C619C69; Tue, 4 Jun 2019 20:39:39 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <155966609977.17449.5624614375035334363.stgit@warthog.procyon.org.uk> To: Andy Lutomirski Cc: dhowells@redhat.com, Al Viro , Casey Schaufler , raven@themaw.net, Linux FS Devel , Linux API , linux-block@vger.kernel.org, keyrings@vger.kernel.org, LSM List , LKML Subject: Re: [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1206.1559680778.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Tue, 04 Jun 2019 21:39:38 +0100 Message-ID: <1207.1559680778@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Tue, 04 Jun 2019 20:39:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Lutomirski 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. 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. 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? David