From: Casey Schaufler <casey@schaufler-ca.com> To: Andy Lutomirski <luto@kernel.org> Cc: Stephen Smalley <sds@tycho.nsa.gov>, David Howells <dhowells@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, USB list <linux-usb@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, raven@themaw.net, Linux FS Devel <linux-fsdevel@vger.kernel.org>, Linux API <linux-api@vger.kernel.org>, linux-block@vger.kernel.org, keyrings@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, Paul Moore <paul@paul-moore.com>, casey@schaufler-ca.com Subject: Re: [RFC][PATCH 00/13] Mount, FS, Block and Keyrings notifications [ver #4] Date: Mon, 10 Jun 2019 11:01:58 -0700 [thread overview] Message-ID: <dac74580-5b48-86e4-8222-cac29a9f541d@schaufler-ca.com> (raw) In-Reply-To: <CALCETrX5O18q2=dUeC=hEtK2=t5KQpGBy9XveHxFw36OqkbNOg@mail.gmail.com> On 6/10/2019 9:42 AM, Andy Lutomirski wrote: > On Mon, Jun 10, 2019 at 9:34 AM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 6/10/2019 8:21 AM, Stephen Smalley wrote: >>> On 6/7/19 10:17 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: >>>> >>>> (1) Mount topology events, such as mounting, unmounting, mount expiry, >>>> mount reconfiguration. >>>> >>>> (2) Superblock events, such as R/W<->R/O changes, quota overrun and I/O >>>> errors (not complete yet). >>>> >>>> (3) Key/keyring events, such as creating, linking and removal of keys. >>>> >>>> (4) General device events (single common queue) including: >>>> >>>> - Block layer events, such as device errors >>>> >>>> - USB subsystem events, such as device/bus attach/remove, device >>>> reset, device errors. >>>> >>>> One of the reasons for this is so that we can remove the issue of processes >>>> having to repeatedly and regularly scan /proc/mounts, which has proven to >>>> be a system performance problem. To further aid this, the fsinfo() syscall >>>> on which this patch series depends, provides a way to access superblock and >>>> mount information in binary form without the need to parse /proc/mounts. >>>> >>>> >>>> LSM support is included, but controversial: >>>> >>>> (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. >>>> >>>> (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. >>>> >>>> (?) Do I need to add security_set_watch(), say, to rule on whether a watch >>>> may be set in the first place? I might need to add a variant per >>>> watch-type. >>>> >>>> (?) Do I really need to keep track of the process creds in which an >>>> implicit object destruction happened? For example, imagine you create >>>> an fd with fsopen()/fsmount(). It is marked to dissolve the mount it >>>> refers to on close unless move_mount() clears that flag. Now, imagine >>>> someone looking at that fd through procfs at the same time as you exit >>>> due to an error. The LSM sees the destruction notification come from >>>> the looker if they happen to do their fput() after yours. >>> I remain unconvinced that (1), (2), (3), and the final (?) above are a good idea. >>> >>> For SELinux, I would expect that one would implement a collection of per watch-type WATCH permission checks on the target object (or to some well-defined object label like the kernel SID if there is no object) that allow receipt of all notifications of that watch-type for objects related to the target object, where "related to" is defined per watch-type. >>> >>> I wouldn't expect SELinux to implement security_post_notification() at all. I can't see how one can construct a meaningful, stable policy for it. I'd argue that the triggering process is not posting the notification; the kernel is posting the notification and the watcher has been authorized to receive it. >> I cannot agree. There is an explicit action by a subject that results >> in information being delivered to an object. Just like a signal or a >> UDP packet delivery. Smack handles this kind of thing just fine. The >> internal mechanism that results in the access is irrelevant from >> this viewpoint. I can understand how a mechanism like SELinux that >> works on finer granularity might view it differently. > I think you really need to give an example of a coherent policy that > needs this. I keep telling you, and you keep ignoring what I say. > As it stands, your analogy seems confusing. It's pretty simple. I have given both the abstract and examples. > If someone > changes the system clock, we don't restrict who is allowed to be > notified (via, for example, TFD_TIMER_CANCEL_ON_SET) that the clock > was changed based on who changed the clock. That's right. The system clock is not an object that unprivileged processes can modify. In fact, it is not an object at all. If you care to look, you will see that Smack does nothing with the clock. > Similarly, if someone > tries to receive a packet on a socket, we check whether they have the > right to receive on that socket (from the endpoint in question) and, > if the sender is local, whether the sender can send to that socket. > We do not check whether the sender can send to the receiver. Bzzzt! Smack sure does. > The signal example is inapplicable. From a modeling viewpoint the actions are identical. > Sending a signal to a process is > an explicit action done to that process, and it can easily adversely > affect the target. Of course it requires permission. > > --Andy
WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com> To: Andy Lutomirski <luto@kernel.org> Cc: Stephen Smalley <sds@tycho.nsa.gov>, David Howells <dhowells@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, USB list <linux-usb@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, raven@themaw.net, Linux FS Devel <linux-fsdevel@vger.kernel.org>, Linux API <linux-api@vger.kernel.org>, linux-block@vger.kernel.org, keyrings@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, Paul Moore <paul@paul-moore.com>, casey@schaufler-ca.com Subject: Re: [RFC][PATCH 00/13] Mount, FS, Block and Keyrings notifications [ver #4] Date: Mon, 10 Jun 2019 18:01:58 +0000 [thread overview] Message-ID: <dac74580-5b48-86e4-8222-cac29a9f541d@schaufler-ca.com> (raw) In-Reply-To: <CALCETrX5O18q2=dUeC=hEtK2=t5KQpGBy9XveHxFw36OqkbNOg@mail.gmail.com> On 6/10/2019 9:42 AM, Andy Lutomirski wrote: > On Mon, Jun 10, 2019 at 9:34 AM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 6/10/2019 8:21 AM, Stephen Smalley wrote: >>> On 6/7/19 10:17 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: >>>> >>>> (1) Mount topology events, such as mounting, unmounting, mount expiry, >>>> mount reconfiguration. >>>> >>>> (2) Superblock events, such as R/W<->R/O changes, quota overrun and I/O >>>> errors (not complete yet). >>>> >>>> (3) Key/keyring events, such as creating, linking and removal of keys. >>>> >>>> (4) General device events (single common queue) including: >>>> >>>> - Block layer events, such as device errors >>>> >>>> - USB subsystem events, such as device/bus attach/remove, device >>>> reset, device errors. >>>> >>>> One of the reasons for this is so that we can remove the issue of processes >>>> having to repeatedly and regularly scan /proc/mounts, which has proven to >>>> be a system performance problem. To further aid this, the fsinfo() syscall >>>> on which this patch series depends, provides a way to access superblock and >>>> mount information in binary form without the need to parse /proc/mounts. >>>> >>>> >>>> LSM support is included, but controversial: >>>> >>>> (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. >>>> >>>> (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. >>>> >>>> (?) Do I need to add security_set_watch(), say, to rule on whether a watch >>>> may be set in the first place? I might need to add a variant per >>>> watch-type. >>>> >>>> (?) Do I really need to keep track of the process creds in which an >>>> implicit object destruction happened? For example, imagine you create >>>> an fd with fsopen()/fsmount(). It is marked to dissolve the mount it >>>> refers to on close unless move_mount() clears that flag. Now, imagine >>>> someone looking at that fd through procfs at the same time as you exit >>>> due to an error. The LSM sees the destruction notification come from >>>> the looker if they happen to do their fput() after yours. >>> I remain unconvinced that (1), (2), (3), and the final (?) above are a good idea. >>> >>> For SELinux, I would expect that one would implement a collection of per watch-type WATCH permission checks on the target object (or to some well-defined object label like the kernel SID if there is no object) that allow receipt of all notifications of that watch-type for objects related to the target object, where "related to" is defined per watch-type. >>> >>> I wouldn't expect SELinux to implement security_post_notification() at all. I can't see how one can construct a meaningful, stable policy for it. I'd argue that the triggering process is not posting the notification; the kernel is posting the notification and the watcher has been authorized to receive it. >> I cannot agree. There is an explicit action by a subject that results >> in information being delivered to an object. Just like a signal or a >> UDP packet delivery. Smack handles this kind of thing just fine. The >> internal mechanism that results in the access is irrelevant from >> this viewpoint. I can understand how a mechanism like SELinux that >> works on finer granularity might view it differently. > I think you really need to give an example of a coherent policy that > needs this. I keep telling you, and you keep ignoring what I say. > As it stands, your analogy seems confusing. It's pretty simple. I have given both the abstract and examples. > If someone > changes the system clock, we don't restrict who is allowed to be > notified (via, for example, TFD_TIMER_CANCEL_ON_SET) that the clock > was changed based on who changed the clock. That's right. The system clock is not an object that unprivileged processes can modify. In fact, it is not an object at all. If you care to look, you will see that Smack does nothing with the clock. > Similarly, if someone > tries to receive a packet on a socket, we check whether they have the > right to receive on that socket (from the endpoint in question) and, > if the sender is local, whether the sender can send to that socket. > We do not check whether the sender can send to the receiver. Bzzzt! Smack sure does. > The signal example is inapplicable. From a modeling viewpoint the actions are identical. > Sending a signal to a process is > an explicit action done to that process, and it can easily adversely > affect the target. Of course it requires permission. > > --Andy
next prev parent reply other threads:[~2019-06-10 18:02 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-07 14:17 [RFC][PATCH 00/13] Mount, FS, Block and Keyrings notifications [ver #4] David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 14:17 ` [PATCH 01/13] security: Override creds in __fput() with last fputter's creds " David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 14:17 ` [PATCH 02/13] uapi: General notification ring definitions " David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 15:12 ` Darrick J. Wong 2019-06-07 15:12 ` Darrick J. Wong 2019-06-07 15:30 ` David Howells 2019-06-07 15:30 ` David Howells 2019-06-07 15:51 ` David Howells 2019-06-07 15:51 ` David Howells 2019-06-09 4:35 ` Randy Dunlap 2019-06-09 4:35 ` Randy Dunlap 2019-06-13 13:34 ` David Howells 2019-06-13 13:34 ` David Howells 2019-06-13 14:49 ` Randy Dunlap 2019-06-13 14:49 ` Randy Dunlap 2019-06-07 14:17 ` [PATCH 03/13] security: Add hooks to rule on setting a watch " David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 14:17 ` [PATCH 04/13] security: Add a hook for the point of notification insertion " David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 14:17 ` David Howells 2019-06-07 14:18 ` [PATCH 05/13] General notification queue with user mmap()'able ring buffer " David Howells 2019-06-07 14:18 ` David Howells 2019-06-07 14:18 ` [PATCH 06/13] keys: Add a notification facility " David Howells 2019-06-07 14:18 ` David Howells 2019-06-10 17:11 ` Jonathan Corbet 2019-06-10 17:11 ` Jonathan Corbet 2019-06-10 17:47 ` David Howells 2019-06-10 17:47 ` David Howells 2019-06-07 14:18 ` [PATCH 07/13] vfs: Add a mount-notification " David Howells 2019-06-07 14:18 ` David Howells 2019-06-07 14:18 ` [PATCH 08/13] vfs: Add superblock notifications " David Howells 2019-06-07 14:18 ` David Howells 2019-06-07 14:18 ` [PATCH 09/13] fsinfo: Export superblock notification counter " David Howells 2019-06-07 14:18 ` David Howells 2019-06-07 14:18 ` [PATCH 10/13] Add a general, global device notification watch list " David Howells 2019-06-07 14:18 ` David Howells 2019-06-07 14:19 ` [PATCH 11/13] block: Add block layer notifications " David Howells 2019-06-07 14:19 ` David Howells 2019-06-07 14:19 ` [PATCH 12/13] usb: Add USB subsystem " David Howells 2019-06-07 14:19 ` David Howells 2019-06-07 14:19 ` [PATCH 13/13] Add sample notification program " David Howells 2019-06-07 14:19 ` David Howells 2019-06-10 15:21 ` [RFC][PATCH 00/13] Mount, FS, Block and Keyrings notifications " Stephen Smalley 2019-06-10 15:21 ` Stephen Smalley 2019-06-10 16:33 ` Casey Schaufler 2019-06-10 16:33 ` Casey Schaufler 2019-06-10 16:42 ` Andy Lutomirski 2019-06-10 16:42 ` Andy Lutomirski 2019-06-10 18:01 ` Casey Schaufler [this message] 2019-06-10 18:01 ` Casey Schaufler 2019-06-10 18:22 ` Andy Lutomirski 2019-06-10 18:22 ` Andy Lutomirski 2019-06-10 19:33 ` Casey Schaufler 2019-06-10 19:33 ` Casey Schaufler 2019-06-10 19:53 ` Andy Lutomirski 2019-06-10 19:53 ` Andy Lutomirski 2019-06-10 21:25 ` Casey Schaufler 2019-06-10 21:25 ` Casey Schaufler 2019-06-11 0:13 ` Andy Lutomirski 2019-06-11 0:13 ` Andy Lutomirski 2019-06-11 14:32 ` Stephen Smalley 2019-06-11 14:32 ` Stephen Smalley 2019-06-12 8:55 ` David Howells 2019-06-12 8:55 ` David Howells 2019-06-10 22:07 ` David Howells 2019-06-10 22:07 ` David Howells 2019-06-11 14:21 ` What do LSMs *actually* need for checks on notifications? David Howells 2019-06-11 15:57 ` Stephen Smalley 2019-06-11 16:22 ` Casey Schaufler 2019-06-12 11:43 ` David Howells 2019-06-13 18:46 ` Stephen Smalley 2019-06-12 17:41 ` David Howells 2019-06-12 18:14 ` Casey Schaufler 2019-06-12 18:36 ` David Howells
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=dac74580-5b48-86e4-8222-cac29a9f541d@schaufler-ca.com \ --to=casey@schaufler-ca.com \ --cc=dhowells@redhat.com \ --cc=gregkh@linuxfoundation.org \ --cc=keyrings@vger.kernel.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=luto@kernel.org \ --cc=paul@paul-moore.com \ --cc=raven@themaw.net \ --cc=sds@tycho.nsa.gov \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.