From: Paul Moore <paul@paul-moore.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Casey Schaufler <casey@schaufler-ca.com>, Alexei Starovoitov <alexei.starovoitov@gmail.com>, Daniel Borkmann <daniel@iogearbox.net>, Ondrej Mosnacek <omosnace@redhat.com>, LSM List <linux-security-module@vger.kernel.org>, James Morris <jmorris@namei.org>, Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>, Stephen Smalley <stephen.smalley.work@gmail.com>, SElinux list <selinux@vger.kernel.org>, ppc-dev <linuxppc-dev@lists.ozlabs.org>, Linux-Fsdevel <linux-fsdevel@vger.kernel.org>, bpf <bpf@vger.kernel.org>, Network Development <netdev@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Jiri Olsa <jolsa@redhat.com>, Alexei Starovoitov <ast@kernel.org>, Andrii Nakryiko <andrii@kernel.org>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org> Subject: Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks Date: Sat, 5 Jun 2021 22:11:00 -0400 [thread overview] Message-ID: <CAHC9VhRJDr6HO8NbEwcqcXCgpzyLL7KEmKM=VLXGz0zPJG5iXw@mail.gmail.com> (raw) In-Reply-To: <CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com> On Sat, Jun 5, 2021 at 2:17 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sat, Jun 5, 2021 at 11:11 AM Casey Schaufler <casey@schaufler-ca.com> wrote: > > > > You have fallen into a common fallacy. The fact that the "code runs" > > does not assure that the "system works right". In the security world > > we face this all the time, often with performance expectations. In this > > case the BPF design has failed [..] > > I think it's the lockdown patches that have failed. They did the wrong > thing, they didn't work, > > The report in question is for a regression. > > THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS. To think I was worried we might end this thread without a bit of CAPS LOCK, whew! :) I don't think anyone in this discussion, even Casey's last comment, was denying that there was a problem. The discussion and the disagreements were about what a "proper" fix would be, and how one might implement that fix; of course there were different ideas of "proper" and implementations vary even when people agree, so things were a bit of a mess. If you want to get upset and shouty, I think there are a few things spread across the subsystems involved that would be worthy targets, but to say that Casey, myself, or anyone else who plays under security/ denied the problem in this thread is not fair, or correct, in my opinion. > Honestly, security people need to understand that "not working" is not > a success case of security. It's a failure case. I can't pretend to know what all of the "security people" are thinking, but I can say with a good degree of certainty that my goal is not to crash, panic, kill, or otherwise disable a user's system. When it comes to things like the LSM hooks, my goal is to try and make sure we have the right hooks in the right places so that admins and users have the tools they need to control access to their data and systems in the way that they choose. Sometimes this puts us at odds with other subsystems in the kernel, we saw that in this thread, but that's to be expected anytime you have competing priorities. The important part is that eventually we figure out some way to move forward, and the fact that we are still all making progress and putting out new kernel releases is proof that we are finding a way. That's what matters to me, and if I was forced to guess, I would imagine that matters quite a lot to most of us here. -- paul moore www.paul-moore.com
WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul@paul-moore.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Olsa <jolsa@redhat.com>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, "David S. Miller" <davem@davemloft.net>, SElinux list <selinux@vger.kernel.org>, Network Development <netdev@vger.kernel.org>, Stephen Smalley <stephen.smalley.work@gmail.com>, Andrii Nakryiko <andrii@kernel.org>, James Morris <jmorris@namei.org>, Steven Rostedt <rostedt@goodmis.org>, Ondrej Mosnacek <omosnace@redhat.com>, Linux-Fsdevel <linux-fsdevel@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>, Casey Schaufler <casey@schaufler-ca.com>, Jakub Kicinski <kuba@kernel.org>, bpf <bpf@vger.kernel.org>, ppc-dev <linuxppc-dev@lists.ozlabs.org>, Alexei Starovoitov <alexei.starovoitov@gmail.com>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks Date: Sat, 5 Jun 2021 22:11:00 -0400 [thread overview] Message-ID: <CAHC9VhRJDr6HO8NbEwcqcXCgpzyLL7KEmKM=VLXGz0zPJG5iXw@mail.gmail.com> (raw) In-Reply-To: <CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com> On Sat, Jun 5, 2021 at 2:17 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sat, Jun 5, 2021 at 11:11 AM Casey Schaufler <casey@schaufler-ca.com> wrote: > > > > You have fallen into a common fallacy. The fact that the "code runs" > > does not assure that the "system works right". In the security world > > we face this all the time, often with performance expectations. In this > > case the BPF design has failed [..] > > I think it's the lockdown patches that have failed. They did the wrong > thing, they didn't work, > > The report in question is for a regression. > > THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS. To think I was worried we might end this thread without a bit of CAPS LOCK, whew! :) I don't think anyone in this discussion, even Casey's last comment, was denying that there was a problem. The discussion and the disagreements were about what a "proper" fix would be, and how one might implement that fix; of course there were different ideas of "proper" and implementations vary even when people agree, so things were a bit of a mess. If you want to get upset and shouty, I think there are a few things spread across the subsystems involved that would be worthy targets, but to say that Casey, myself, or anyone else who plays under security/ denied the problem in this thread is not fair, or correct, in my opinion. > Honestly, security people need to understand that "not working" is not > a success case of security. It's a failure case. I can't pretend to know what all of the "security people" are thinking, but I can say with a good degree of certainty that my goal is not to crash, panic, kill, or otherwise disable a user's system. When it comes to things like the LSM hooks, my goal is to try and make sure we have the right hooks in the right places so that admins and users have the tools they need to control access to their data and systems in the way that they choose. Sometimes this puts us at odds with other subsystems in the kernel, we saw that in this thread, but that's to be expected anytime you have competing priorities. The important part is that eventually we figure out some way to move forward, and the fact that we are still all making progress and putting out new kernel releases is proof that we are finding a way. That's what matters to me, and if I was forced to guess, I would imagine that matters quite a lot to most of us here. -- paul moore www.paul-moore.com
next prev parent reply other threads:[~2021-06-06 2:12 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-17 9:20 [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks Ondrej Mosnacek 2021-05-17 9:20 ` [PATCH v2] lockdown, selinux: " Ondrej Mosnacek 2021-05-17 11:00 ` [PATCH v2] lockdown,selinux: " Michael Ellerman 2021-05-17 11:00 ` Michael Ellerman 2021-05-26 11:44 ` Ondrej Mosnacek 2021-05-26 11:44 ` Ondrej Mosnacek 2021-05-27 4:28 ` James Morris 2021-05-27 4:28 ` James Morris 2021-05-27 14:18 ` Paul Moore 2021-05-27 14:18 ` Paul Moore 2021-05-28 1:37 ` Paul Moore 2021-05-28 1:37 ` Paul Moore 2021-05-28 7:09 ` Daniel Borkmann 2021-05-28 7:09 ` Daniel Borkmann 2021-05-28 9:53 ` Jiri Olsa 2021-05-28 9:53 ` Jiri Olsa 2021-05-28 9:56 ` Daniel Borkmann 2021-05-28 9:56 ` Daniel Borkmann 2021-05-28 10:16 ` Jiri Olsa 2021-05-28 10:16 ` Jiri Olsa 2021-05-28 11:47 ` Jiri Olsa 2021-05-28 11:47 ` Jiri Olsa 2021-05-28 11:54 ` Daniel Borkmann 2021-05-28 11:54 ` Daniel Borkmann 2021-05-28 13:42 ` Ondrej Mosnacek 2021-05-28 13:42 ` Ondrej Mosnacek 2021-05-28 14:20 ` Daniel Borkmann 2021-05-28 14:20 ` Daniel Borkmann 2021-05-28 15:54 ` Paul Moore 2021-05-28 15:54 ` Paul Moore 2021-05-28 15:47 ` Paul Moore 2021-05-28 15:47 ` Paul Moore 2021-05-28 18:10 ` Daniel Borkmann 2021-05-28 18:10 ` Daniel Borkmann 2021-05-28 22:52 ` Paul Moore 2021-05-28 22:52 ` Paul Moore 2021-05-29 18:48 ` Paul Moore 2021-05-29 18:48 ` Paul Moore 2021-05-31 8:24 ` Daniel Borkmann 2021-05-31 8:24 ` Daniel Borkmann 2021-06-01 20:47 ` Paul Moore 2021-06-01 20:47 ` Paul Moore 2021-06-02 12:40 ` Daniel Borkmann 2021-06-02 12:40 ` Daniel Borkmann 2021-06-02 15:13 ` Paul Moore 2021-06-02 15:13 ` Paul Moore 2021-06-03 18:52 ` Daniel Borkmann 2021-06-03 18:52 ` Daniel Borkmann 2021-06-04 4:50 ` Paul Moore 2021-06-04 4:50 ` Paul Moore 2021-06-04 18:02 ` Daniel Borkmann 2021-06-04 18:02 ` Daniel Borkmann 2021-06-04 23:34 ` Paul Moore 2021-06-04 23:34 ` Paul Moore 2021-06-05 0:08 ` Alexei Starovoitov 2021-06-05 0:08 ` Alexei Starovoitov 2021-06-05 18:10 ` Casey Schaufler 2021-06-05 18:10 ` Casey Schaufler 2021-06-05 18:17 ` Linus Torvalds 2021-06-05 18:17 ` Linus Torvalds 2021-06-06 2:11 ` Paul Moore [this message] 2021-06-06 2:11 ` Paul Moore 2021-06-06 1:30 ` Paul Moore 2021-06-06 1:30 ` Paul Moore 2021-06-02 13:39 ` Ondrej Mosnacek 2021-06-02 13:39 ` Ondrej Mosnacek 2021-06-03 17:46 ` Paul Moore 2021-06-03 17:46 ` Paul Moore 2021-06-08 11:01 ` Ondrej Mosnacek 2021-06-08 11:01 ` Ondrej Mosnacek 2021-06-09 2:40 ` Paul Moore 2021-06-09 2:40 ` Paul Moore 2021-05-28 13:58 ` Steven Rostedt 2021-05-28 13:58 ` Steven Rostedt
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='CAHC9VhRJDr6HO8NbEwcqcXCgpzyLL7KEmKM=VLXGz0zPJG5iXw@mail.gmail.com' \ --to=paul@paul-moore.com \ --cc=alexei.starovoitov@gmail.com \ --cc=andrii@kernel.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=casey@schaufler-ca.com \ --cc=daniel@iogearbox.net \ --cc=davem@davemloft.net \ --cc=jmorris@namei.org \ --cc=jolsa@redhat.com \ --cc=kuba@kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mingo@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=omosnace@redhat.com \ --cc=rostedt@goodmis.org \ --cc=selinux@vger.kernel.org \ --cc=stephen.smalley.work@gmail.com \ --cc=torvalds@linux-foundation.org \ /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.