From: Casey Schaufler <casey@schaufler-ca.com> To: Andy Lutomirski <luto@kernel.org> Cc: David Howells <dhowells@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, 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, LSM List <linux-security-module@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, casey@schaufler-ca.com Subject: Re: [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] Date: Wed, 5 Jun 2019 10:01:30 -0700 [thread overview] Message-ID: <9a9406ba-eda4-e3ec-2100-9f7cf1d5c130@schaufler-ca.com> (raw) In-Reply-To: <CALCETrVSBwHEm-1pgBXxth07PZ0XF6FD+7E25=WbiS7jxUe83A@mail.gmail.com> On 6/5/2019 9:04 AM, Andy Lutomirski wrote: > On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 6/5/2019 1:41 AM, David Howells wrote: >>> Casey Schaufler <casey@schaufler-ca.com> 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. >> YES! >> >> Threat is about what you can do, not what you intend to do. >> >> And it would be really great if you put some thought into what >> a rational model would be for UID based controls, too. >> >>> But there are problems with not sending the event: >>> >>> (1) B's internal state is then corrupt (or, at least, unknowingly invalid). >> Then B is a badly written program. > Either I'm misunderstanding you or I strongly disagree. A program needs to be aware of the conditions under which it gets event, *including the possibility that it may not get an event that it's not allowed*. Do you regularly write programs that go into corrupt states if an open() fails? Or where read() returns less than the amount of data you ask for? > If B has > authority to detect a certain action, and A has authority to perform > that action, then refusing to notify B because B is somehow missing > some special authorization to be notified by A is nuts. You are hand-waving the notion of authority. You are assuming that if A can read X and B can read X that A can write B. > This is just > introducing incorrectness into the design in support of a > not-actually-helpful security idea. Where is the incorrectness? Are you seriously saying that you expect all events to be generated exactly as you think they should? Have you ever even used systemd? > If I can read /proc/self/mounts, I can detect changes to my mount > namespace. Then read /proc/self/mounts! Can't you poll on an fd open on /proc/self/mounts? > Giving me a faster and nicer way to do this is fine, AS > LONG AS IT ACTUALLY WORKS. "Works" means it needs to detect all > changes. So long as "WORKS" includes maintaining the system security policy, I agree. No, I don't. We already have too many bizarre and unnatural mechanisms to address whimsical special cases. If speed is such an issue you could look at making /proc better.
WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com> To: Andy Lutomirski <luto@kernel.org> Cc: David Howells <dhowells@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, 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, LSM List <linux-security-module@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, casey@schaufler-ca.com Subject: Re: [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] Date: Wed, 05 Jun 2019 17:01:30 +0000 [thread overview] Message-ID: <9a9406ba-eda4-e3ec-2100-9f7cf1d5c130@schaufler-ca.com> (raw) In-Reply-To: <CALCETrVSBwHEm-1pgBXxth07PZ0XF6FD+7E25=WbiS7jxUe83A@mail.gmail.com> On 6/5/2019 9:04 AM, Andy Lutomirski wrote: > On Wed, Jun 5, 2019 at 7:51 AM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 6/5/2019 1:41 AM, David Howells wrote: >>> Casey Schaufler <casey@schaufler-ca.com> 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. >> YES! >> >> Threat is about what you can do, not what you intend to do. >> >> And it would be really great if you put some thought into what >> a rational model would be for UID based controls, too. >> >>> But there are problems with not sending the event: >>> >>> (1) B's internal state is then corrupt (or, at least, unknowingly invalid). >> Then B is a badly written program. > Either I'm misunderstanding you or I strongly disagree. A program needs to be aware of the conditions under which it gets event, *including the possibility that it may not get an event that it's not allowed*. Do you regularly write programs that go into corrupt states if an open() fails? Or where read() returns less than the amount of data you ask for? > If B has > authority to detect a certain action, and A has authority to perform > that action, then refusing to notify B because B is somehow missing > some special authorization to be notified by A is nuts. You are hand-waving the notion of authority. You are assuming that if A can read X and B can read X that A can write B. > This is just > introducing incorrectness into the design in support of a > not-actually-helpful security idea. Where is the incorrectness? Are you seriously saying that you expect all events to be generated exactly as you think they should? Have you ever even used systemd? > If I can read /proc/self/mounts, I can detect changes to my mount > namespace. Then read /proc/self/mounts! Can't you poll on an fd open on /proc/self/mounts? > Giving me a faster and nicer way to do this is fine, AS > LONG AS IT ACTUALLY WORKS. "Works" means it needs to detect all > changes. So long as "WORKS" includes maintaining the system security policy, I agree. No, I don't. We already have too many bizarre and unnatural mechanisms to address whimsical special cases. If speed is such an issue you could look at making /proc better.
next prev parent reply other threads:[~2019-06-05 17:01 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-04 16:34 [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] David Howells 2019-06-04 16:34 ` David Howells 2019-06-04 16:35 ` [PATCH 1/8] security: Override creds in __fput() with last fputter's creds " David Howells 2019-06-04 16:35 ` David Howells 2019-06-04 16:35 ` David Howells 2019-06-04 18:15 ` Andy Lutomirski 2019-06-04 18:15 ` Andy Lutomirski 2019-06-04 16:35 ` [PATCH 2/8] General notification queue with user mmap()'able ring buffer " David Howells 2019-06-04 16:35 ` David Howells 2019-06-04 16:35 ` [PATCH 3/8] keys: Add a notification facility " David Howells 2019-06-04 16:35 ` David Howells 2019-06-04 16:35 ` [PATCH 4/8] vfs: Add a mount-notification " David Howells 2019-06-04 16:35 ` David Howells 2019-06-04 16:35 ` [PATCH 5/8] vfs: Add superblock notifications " David Howells 2019-06-04 16:35 ` David Howells 2019-06-04 16:36 ` [PATCH 6/8] fsinfo: Export superblock notification counter " David Howells 2019-06-04 16:36 ` David Howells 2019-06-04 16:36 ` [PATCH 7/8] block: Add block layer notifications " David Howells 2019-06-04 16:36 ` David Howells 2019-06-04 16:36 ` [PATCH 8/8] Add sample notification program " David Howells 2019-06-04 16:36 ` David Howells 2019-06-04 17:43 ` [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications " Andy Lutomirski 2019-06-04 17:43 ` Andy Lutomirski 2019-06-04 20:31 ` Casey Schaufler 2019-06-04 20:31 ` Casey Schaufler 2019-06-04 21:05 ` Andy Lutomirski 2019-06-04 21:05 ` Andy Lutomirski 2019-06-04 22:03 ` Casey Schaufler 2019-06-04 22:03 ` Casey Schaufler 2019-06-05 8:41 ` David Howells 2019-06-05 8:41 ` David Howells 2019-06-05 14:50 ` Casey Schaufler 2019-06-05 14:50 ` Casey Schaufler 2019-06-05 16:04 ` Andy Lutomirski 2019-06-05 16:04 ` Andy Lutomirski 2019-06-05 17:01 ` Casey Schaufler [this message] 2019-06-05 17:01 ` Casey Schaufler 2019-06-05 17:47 ` Andy Lutomirski 2019-06-05 17:47 ` Andy Lutomirski 2019-06-05 18:12 ` Casey Schaufler 2019-06-05 18:12 ` Casey Schaufler 2019-06-05 18:25 ` Stephen Smalley 2019-06-05 18:25 ` Stephen Smalley 2019-06-05 19:28 ` Greg KH 2019-06-05 19:28 ` Greg KH 2019-06-05 21:01 ` Stephen Smalley 2019-06-05 21:01 ` Stephen Smalley 2019-06-05 16:56 ` Rational model for UID based controls David Howells 2019-06-05 16:56 ` David Howells 2019-06-05 17:40 ` Casey Schaufler 2019-06-05 17:40 ` Casey Schaufler 2019-06-05 21:06 ` David Howells 2019-06-05 21:06 ` David Howells 2019-06-05 17:21 ` [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] David Howells 2019-06-05 17:21 ` David Howells 2019-06-04 20:39 ` David Howells 2019-06-04 20:39 ` David Howells 2019-06-04 20:57 ` Andy Lutomirski 2019-06-04 20:57 ` Andy Lutomirski [not found] ` <CAB9W1A0AgMYOwGx9c-TmAt=1O6Bjsr2P3Nhd=2+QV39dgw0CrA@mail.gmail.com> 2019-06-05 4:19 ` Andy Lutomirski 2019-06-05 4:19 ` Andy Lutomirski 2019-06-05 13:47 ` Stephen Smalley 2019-06-05 13:47 ` Stephen Smalley 2019-06-04 21:11 ` Casey Schaufler 2019-06-04 21:11 ` Casey Schaufler
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=9a9406ba-eda4-e3ec-2100-9f7cf1d5c130@schaufler-ca.com \ --to=casey@schaufler-ca.com \ --cc=dhowells@redhat.com \ --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=luto@kernel.org \ --cc=raven@themaw.net \ --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.