All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Mosnacek <omosnace@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Linux Security Module 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>,
	linuxppc-dev@lists.ozlabs.org,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, network dev <netdev@vger.kernel.org>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] lockdown,selinux: fix bogus SELinux lockdown permission checks
Date: Wed, 12 May 2021 15:21:37 +0200	[thread overview]
Message-ID: <CAFqZXNtr1YjzRg7fTm+j=0oZF+7C5xEu5J0mCZynP-dgEzvyUg@mail.gmail.com> (raw)
In-Reply-To: <a8d138a6-1d34-1457-9266-4abeddb6fdba@schaufler-ca.com>

On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote:
> > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > lockdown") added an implementation of the locked_down LSM hook to
> > SELinux, with the aim to restrict which domains are allowed to perform
> > operations that would breach lockdown.
> >
> > However, in several places the security_locked_down() hook is called in
> > situations where the current task isn't doing any action that would
> > directly breach lockdown, leading to SELinux checks that are basically
> > bogus.
> >
> > Since in most of these situations converting the callers such that
> > security_locked_down() is called in a context where the current task
> > would be meaningful for SELinux is impossible or very non-trivial (and
> > could lead to TOCTOU issues for the classic Lockdown LSM
> > implementation), fix this by adding a separate hook
> > security_locked_down_globally()
>
> This is a poor solution to the stated problem. Rather than adding
> a new hook you should add the task as a parameter to the existing hook
> and let the security modules do as they will based on its value.
> If the caller does not have an appropriate task it should pass NULL.
> The lockdown LSM can ignore the task value and SELinux can make its
> own decision based on the task value passed.

The problem with that approach is that all callers would then need to
be updated and I intended to keep the patch small as I'd like it to go
to stable kernels as well.

But it does seem to be a better long-term solution - would it work for
you (and whichever maintainer would be taking the patch(es)) if I just
added another patch that refactors it to use the task parameter?

--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.


WARNING: multiple messages have this Message-ID (diff)
From: Ondrej Mosnacek <omosnace@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: SElinux list <selinux@vger.kernel.org>,
	network dev <netdev@vger.kernel.org>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	James Morris <jmorris@namei.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Linux Security Module list
	<linux-security-module@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] lockdown, selinux: fix bogus SELinux lockdown permission checks
Date: Wed, 12 May 2021 15:21:37 +0200	[thread overview]
Message-ID: <CAFqZXNtr1YjzRg7fTm+j=0oZF+7C5xEu5J0mCZynP-dgEzvyUg@mail.gmail.com> (raw)
In-Reply-To: <a8d138a6-1d34-1457-9266-4abeddb6fdba@schaufler-ca.com>

On Sat, May 8, 2021 at 12:17 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote:
> > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > lockdown") added an implementation of the locked_down LSM hook to
> > SELinux, with the aim to restrict which domains are allowed to perform
> > operations that would breach lockdown.
> >
> > However, in several places the security_locked_down() hook is called in
> > situations where the current task isn't doing any action that would
> > directly breach lockdown, leading to SELinux checks that are basically
> > bogus.
> >
> > Since in most of these situations converting the callers such that
> > security_locked_down() is called in a context where the current task
> > would be meaningful for SELinux is impossible or very non-trivial (and
> > could lead to TOCTOU issues for the classic Lockdown LSM
> > implementation), fix this by adding a separate hook
> > security_locked_down_globally()
>
> This is a poor solution to the stated problem. Rather than adding
> a new hook you should add the task as a parameter to the existing hook
> and let the security modules do as they will based on its value.
> If the caller does not have an appropriate task it should pass NULL.
> The lockdown LSM can ignore the task value and SELinux can make its
> own decision based on the task value passed.

The problem with that approach is that all callers would then need to
be updated and I intended to keep the patch small as I'd like it to go
to stable kernels as well.

But it does seem to be a better long-term solution - would it work for
you (and whichever maintainer would be taking the patch(es)) if I just
added another patch that refactors it to use the task parameter?

--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.


  reply	other threads:[~2021-05-12 13:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-07 11:40 [PATCH] lockdown,selinux: fix bogus SELinux lockdown permission checks Ondrej Mosnacek
2021-05-07 11:40 ` [PATCH] lockdown, selinux: " Ondrej Mosnacek
2021-05-07 22:17 ` [PATCH] lockdown,selinux: " Casey Schaufler
2021-05-07 22:17   ` Casey Schaufler
2021-05-12 13:21   ` Ondrej Mosnacek [this message]
2021-05-12 13:21     ` [PATCH] lockdown, selinux: " Ondrej Mosnacek
2021-05-12 16:17     ` [PATCH] lockdown,selinux: " Casey Schaufler
2021-05-12 16:17       ` Casey Schaufler
2021-05-12 16:44       ` Ondrej Mosnacek
2021-05-12 16:44         ` [PATCH] lockdown, selinux: " Ondrej Mosnacek
2021-05-12 17:12         ` [PATCH] lockdown,selinux: " Casey Schaufler
2021-05-12 17:12           ` Casey Schaufler
2021-05-14 15:12           ` Ondrej Mosnacek
2021-05-14 15:12             ` [PATCH] lockdown, selinux: " Ondrej Mosnacek
2021-05-15  0:57             ` [PATCH] lockdown,selinux: " Casey Schaufler
2021-05-15  0:57               ` Casey Schaufler
2021-05-17  8:34               ` Ondrej Mosnacek
2021-05-17  8:34                 ` [PATCH] lockdown, selinux: " Ondrej Mosnacek

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='CAFqZXNtr1YjzRg7fTm+j=0oZF+7C5xEu5J0mCZynP-dgEzvyUg@mail.gmail.com' \
    --to=omosnace@redhat.com \
    --cc=bpf@vger.kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=jmorris@namei.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=rostedt@goodmis.org \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    /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: link
Be 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.