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=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 D85A5C28EB6 for ; Thu, 6 Jun 2019 21:17:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B8F89208C0 for ; Thu, 6 Jun 2019 21:17:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728127AbfFFVRS (ORCPT ); Thu, 6 Jun 2019 17:17:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44388 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727915AbfFFVRS (ORCPT ); Thu, 6 Jun 2019 17:17:18 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CC70644BC4; Thu, 6 Jun 2019 21:17:15 +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 572707838F; Thu, 6 Jun 2019 21:17:07 +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: <155981411940.17513.7137844619951358374.stgit@warthog.procyon.org.uk> <3813.1559827003@warthog.procyon.org.uk> <8382af23-548c-f162-0e82-11e308049735@tycho.nsa.gov> <0eb007c5-b4a0-9384-d915-37b0e5a158bf@schaufler-ca.com> <07e92045-2d80-8573-4d36-643deeaff9ec@schaufler-ca.com> To: Andy Lutomirski Cc: dhowells@redhat.com, Casey Schaufler , Stephen Smalley , Al Viro , Greg Kroah-Hartman , USB list , raven@themaw.net, Linux FS Devel , Linux API , linux-block@vger.kernel.org, keyrings@vger.kernel.org, LSM List , LKML , Paul Moore Subject: Re: [RFC][PATCH 00/10] Mount, FS, Block and Keyrings notifications [ver #3] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23610.1559855827.1@warthog.procyon.org.uk> Date: Thu, 06 Jun 2019 22:17:07 +0100 Message-ID: <23611.1559855827@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 06 Jun 2019 21:17:17 +0000 (UTC) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Andy Lutomirski wrote: > > > You are allowing arbitrary information flow between T and W above. Who > > > cares about notifications? > > > > I do. If Watched object is /dev/null no data flow is possible. > > There are many objects on a modern Linux system for which this > > is true. Even if it's "just a file" the existence of one path > > for data to flow does not justify ignoring the rules for other > > data paths. > > Aha! > > Even ignoring security, writes to things like /dev/null should > probably not trigger notifications to people who are watching > /dev/null. (There are probably lots of things like this: /dev/zero, > /dev/urandom, etc.) Even writes to /dev/null might generate access notifications; leastways, vfs_read() will call fsnotify_access() afterwards on success. Whether or not you can set marks on open device files is another matter. > David, are there any notification types that have this issue in your > patchset? If so, is there a straightforward way to fix it? I'm not sure what issue you're referring to specifically. Do you mean whether writes to device files generate notifications? > Generically, it seems like maybe writes to device nodes shouldn't trigger > notifications since, despite the fact that different openers of a device > node share an inode, there isn't necessarily any connection between them. With the notification types I have currently implemented, I don't even notice any accesses to a device file unless: (1) Someone mounts over the top of one. (2) The access triggers an I/O error or device reset or causes the device to be attached or detached. (3) Wangling the device causes some other superblock event. (4) The driver calls request_key() and that creates a new key. > Casey, if this is fixed in general, do you have another case where the > right to write and the right to read do not imply the right to > communicate? > > > An analogy is that two processes with different UIDs can open a file, > > but still can't signal each other. > > What do you mean "signal"? If two processes with different UIDs can > open the same file for read and write, then they can communicate with > each other in many ways. For example, one can write to the file and > the other can read it. One can take locks and the other can read the > lock state. They can both map it and use any number of memory access > side channels to communicate. But, of course, they can't send each > other signals with kill(). > > If, however, one of these processes is using some fancy mechanism > (inotify, dnotify, kqueue, fanotify, whatever) to watch the file, and > the other one writes it, then it seems inconsistent to lie to the > watching process and say that the file wasn't written because some > security policy has decided to allow the write, allow the read, but > suppress this particular notification. Hence my request for a real > example: when would it make sense to do this? Note that fanotify requires CAP_SYS_ADMIN, but inotify and dnotify do not. dnotify is applied to an open file, so it might be usable on a chardev such as /dev/null, say. David