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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH autolearn=unavailable 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 C494AC282CE for ; Tue, 4 Jun 2019 17:43:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9E7492070B for ; Tue, 4 Jun 2019 17:43:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559670227; bh=q9FCF59QilTvzP7T56Okch9a0m+P6mELSmCw7lx2Jdg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=kP22YhGSu0VuY3CWWyo36UGh3fEDFrxb3h3ua3ETOwWOUkQX6isTle8SaEcRvyXQx tHJJfwkMkhDfeZPwQjRzO9mU1H1esDXz7CAh1lGemu0KtrWZB4dyj+voCWU6QB4oo2 zLBFW3xWguXHVujPi8+E+KSeR0mXAVw/l8OGZ9LI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726373AbfFDRnr (ORCPT ); Tue, 4 Jun 2019 13:43:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:52428 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725932AbfFDRnp (ORCPT ); Tue, 4 Jun 2019 13:43:45 -0400 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 850E72070B for ; Tue, 4 Jun 2019 17:43:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559670224; bh=q9FCF59QilTvzP7T56Okch9a0m+P6mELSmCw7lx2Jdg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iUJtv0HucSbDarovWS1Z7qwfmDSbs5V9BN4rc4AfZZPIhTLPWwcEgKdhs+XzNMK+s pP8EDf6d0HflzvWnlJ4iq2AvL5hnyP/MdAXApObUvjiErqeduqz/IyMephgucibraL 8s2h2J/D8oHyhQ7Laf/f2tfZG/DdDxC54JI8t/7o= Received: by mail-wm1-f53.google.com with SMTP id s3so963914wms.2 for ; Tue, 04 Jun 2019 10:43:44 -0700 (PDT) X-Gm-Message-State: APjAAAV65yTqMezWYy7epLLaekSkOPBGMf+8SHPSazCNUp4Sc5xjGzYD lJBUCKbIdCkh7yhyWsX6RDdHIX/k3pVsDtjgANGsUA== X-Google-Smtp-Source: APXvYqxmFA0LxGXReVPmYeoh54PQ9wGQ/UBD/iQSPrsklI94PoCtyKGznvMTvJtTVRnlwuNsvcMNxx02fdTaRs78X5M= X-Received: by 2002:a1c:6242:: with SMTP id w63mr15439095wmb.161.1559670223114; Tue, 04 Jun 2019 10:43:43 -0700 (PDT) MIME-Version: 1.0 References: <155966609977.17449.5624614375035334363.stgit@warthog.procyon.org.uk> In-Reply-To: <155966609977.17449.5624614375035334363.stgit@warthog.procyon.org.uk> From: Andy Lutomirski Date: Tue, 4 Jun 2019 10:43:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] To: David Howells Cc: Al Viro , Casey Schaufler , raven@themaw.net, Linux FS Devel , Linux API , linux-block@vger.kernel.org, keyrings@vger.kernel.org, LSM List , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 4, 2019 at 9:35 AM David Howells wrote: > > > Hi Al, > > 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? It seems like the resulting security model will be vary hard to understand and probably buggy. Can't you define a sensible model in which only the listener creds matter? > LSM support is included: > > (1) The creds of the process that did the fput() that reduced the refcount > to zero are cached in the file struct. > > (2) __fput() overrides the current creds with the creds from (1) whilst > doing the cleanup, thereby making sure that the creds seen by the > destruction notification generated by mntput() appears to come from > the last fputter. That looks like duct tape that is, at best, likely to be very buggy. > > (3) security_post_notification() is called for each queue that we might > want to post a notification into, thereby allowing the LSM to prevent > covert communications. 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.