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,URIBL_BLOCKED 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 8B0E6C282DE for ; Wed, 5 Jun 2019 08:41:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6F3BF20866 for ; Wed, 5 Jun 2019 08:41:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726776AbfFEIlo (ORCPT ); Wed, 5 Jun 2019 04:41:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33614 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726636AbfFEIlo (ORCPT ); Wed, 5 Jun 2019 04:41:44 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0AB11B9AD5; Wed, 5 Jun 2019 08:41:39 +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 BEF6160576; Wed, 5 Jun 2019 08:41:35 +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: <50c2ea19-6ae8-1f42-97ef-ba5c95e40475@schaufler-ca.com> References: <50c2ea19-6ae8-1f42-97ef-ba5c95e40475@schaufler-ca.com> <155966609977.17449.5624614375035334363.stgit@warthog.procyon.org.uk> To: Casey Schaufler Cc: dhowells@redhat.com, Andy Lutomirski , Al Viro , 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: <20191.1559724094.1@warthog.procyon.org.uk> Date: Wed, 05 Jun 2019 09:41:34 +0100 Message-ID: <20192.1559724094@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 05 Jun 2019 08:41:44 +0000 (UTC) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Casey Schaufler wrote: > I will try to explain the problem once again. If process A > sends a signal (writes information) to process B the kernel > checks that either process A has the same UID as process B > or that process A has privilege to override that policy. > Process B is passive in this access control decision, while > process A is active. In the event delivery case, process A > does something (e.g. modifies a keyring) that generates an > event, which is then sent to process B's event buffer. I think this might be the core sticking point here. It looks like two different situations: (1) A explicitly sends event to B (eg. signalling, sendmsg, etc.) (2) A implicitly and unknowingly sends event to B as a side effect of some other action (eg. B has a watch for the event A did). The LSM treats them as the same: that is B must have MAC authorisation to send a message to A. But there are problems with not sending the event: (1) B's internal state is then corrupt (or, at least, unknowingly invalid). (2) B can potentially figure out that the event happened by other means. I've implemented four event sources so far: (1) Keys/keyrings. You can only get events on a key you have View permission on and the other process has to have write access to it, so I think this is good enough. (2) Block layer. Currently this will only get you hardware error events, which is probably safe. I'm not sure you can manipulate those without permission to directly access the device files. (3) Superblock. This is trickier since it can see events that can be manufactured (R/W <-> R/O remounting, EDQUOT) as well as events that can't without hardware control (EIO, network link loss, RF kill). (4) Mount topology. This is the trickiest since it allows you to see events beyond the point at which you placed your watch (in essence, you place a subtree watch). The question is what permission checking should I do? Ideally, I'd emulate a pathwalk between the watchpoint and the eventing object to see if the owner of the watchpoint could reach it. I'd need to do a reverse walk, calling inode_permission(MAY_NOT_BLOCK) for each directory between the eventing object and the watchpoint to see if one rejects it - but some filesystems have a permission check that can't be called in this state. It would also be necessary to do this separately for each watchpoint in the parental chain. Further, each permissions check would generate an audit event and could generate FAN_ACCESS and/or FAN_ACCESS_PERM fanotify events - which could be a problem if fanotify is also trying to post those events to the same watch queue. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Date: Wed, 05 Jun 2019 08:41:34 +0000 Subject: Re: [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] Message-Id: <20192.1559724094@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <50c2ea19-6ae8-1f42-97ef-ba5c95e40475@schaufler-ca.com> <155966609977.17449.5624614375035334363.stgit@warthog.procyon.org.uk> In-Reply-To: <50c2ea19-6ae8-1f42-97ef-ba5c95e40475@schaufler-ca.com> To: Casey Schaufler Cc: dhowells@redhat.com, Andy Lutomirski , Al Viro , raven@themaw.net, Linux FS Devel , Linux API , linux-block@vger.kernel.org, keyrings@vger.kernel.org, LSM List , LKML Casey Schaufler wrote: > I will try to explain the problem once again. If process A > sends a signal (writes information) to process B the kernel > checks that either process A has the same UID as process B > or that process A has privilege to override that policy. > Process B is passive in this access control decision, while > process A is active. In the event delivery case, process A > does something (e.g. modifies a keyring) that generates an > event, which is then sent to process B's event buffer. I think this might be the core sticking point here. It looks like two different situations: (1) A explicitly sends event to B (eg. signalling, sendmsg, etc.) (2) A implicitly and unknowingly sends event to B as a side effect of some other action (eg. B has a watch for the event A did). The LSM treats them as the same: that is B must have MAC authorisation to send a message to A. But there are problems with not sending the event: (1) B's internal state is then corrupt (or, at least, unknowingly invalid). (2) B can potentially figure out that the event happened by other means. I've implemented four event sources so far: (1) Keys/keyrings. You can only get events on a key you have View permission on and the other process has to have write access to it, so I think this is good enough. (2) Block layer. Currently this will only get you hardware error events, which is probably safe. I'm not sure you can manipulate those without permission to directly access the device files. (3) Superblock. This is trickier since it can see events that can be manufactured (R/W <-> R/O remounting, EDQUOT) as well as events that can't without hardware control (EIO, network link loss, RF kill). (4) Mount topology. This is the trickiest since it allows you to see events beyond the point at which you placed your watch (in essence, you place a subtree watch). The question is what permission checking should I do? Ideally, I'd emulate a pathwalk between the watchpoint and the eventing object to see if the owner of the watchpoint could reach it. I'd need to do a reverse walk, calling inode_permission(MAY_NOT_BLOCK) for each directory between the eventing object and the watchpoint to see if one rejects it - but some filesystems have a permission check that can't be called in this state. It would also be necessary to do this separately for each watchpoint in the parental chain. Further, each permissions check would generate an audit event and could generate FAN_ACCESS and/or FAN_ACCESS_PERM fanotify events - which could be a problem if fanotify is also trying to post those events to the same watch queue. David