All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>,
	Nikolay Borisov <nborisov@suse.com>,
	Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>,
	Linux FSDEVEL Mailinglist <linux-fsdevel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: [PATCH] fs/open: Fix most outstanding security bugs
Date: Mon, 1 Apr 2019 14:27:10 -0700	[thread overview]
Message-ID: <20190401212710.GA28345@beast> (raw)
In-Reply-To: <CACT4Y+Yh-bbrn1x139gxo8B0MqR9NbMoZJeN6iJMTgAnDKp9EA@mail.gmail.com>

On Mon, Apr 1, 2019 at 10:50 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Mon, Apr 1, 2019 at 4:14 PM Nikolay Borisov <nborisov@suse.com> wrote:
> > On 1.04.19 г. 12:01 ч., Johannes Thumshirn wrote:
> > > One common pattern in most of these security related reports is processes
> > > called "syzkaller", "trinity" or "syz-executor" opening files and then
> > > abuse kernel interfaces causing kernel crashes or even worse threats using
> > > memory overwrites or by exploiting race conditions.
> > >
> > > Hunting down these bugs has become time consuming and very expensive, so
> > > I've decided to put an end to it.
> > >
> > > If one of the above mentioned processes tries opening a file, return -EPERM
> > > indicating this process does not have the permission to open files on Linux
> > > anymore.
> > >
> > > Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
> >
> > Ack-by: Nikolay Borisov <nborisov@suse.com>
>
> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: stable@vger.kernel.org # v1.0+
>
> Do we want to extend this to other subsystems?
> Should it be a default secomp filter?

Yes, this protection could make those processes fail too many syscalls. I
agree: it would be better to have all syscalls return 0 with a seccomp
filter. I have updated the patch:


Subject: [PATCH] exec: Fix most outstanding security bugs
From: Kees Cook <keescook@chromium.org>

Over the last 20 years, the Linux kernel has accumulated hundreds if
not thousands of security vulnerabilities.

One common pattern in most of these security related reports is processes
called "syzkaller", "trinity" or "syz-executor" opening files and then
abuse kernel interfaces causing kernel crashes or even worse threats
using memory overwrites or by exploiting race conditions.

Hunting down these bugs has become time consuming and very expensive,
so we've decided to put an end to it.

If one of the above mentioned processes tries to execute a system
call, the call will be skipped but will return zero. This will keep
the process happy without changing kernel state, keeping things safe.

Co-developed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Singed-off-by: Kees Cook <keescook@chromium.org>
---
 fs/exec.c               |  1 +
 include/linux/seccomp.h |  2 ++
 kernel/seccomp.c        | 39 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 42 insertions(+)

diff --git a/fs/exec.c b/fs/exec.c
index 2e0033348d8e..c0a73c8e22ff 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1393,6 +1393,7 @@ void finalize_exec(struct linux_binprm *bprm)
 	task_lock(current->group_leader);
 	current->signal->rlim[RLIMIT_STACK] = bprm->rlim_stack;
 	task_unlock(current->group_leader);
+	seccomp_default(current);
 }
 EXPORT_SYMBOL(finalize_exec);
 
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 84868d37b35d..2d98cd0d79ed 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -45,6 +45,7 @@ extern void secure_computing_strict(int this_syscall);
 
 extern long prctl_get_seccomp(void);
 extern long prctl_set_seccomp(unsigned long, void __user *);
+extern void seccomp_default(struct task_struct *task);
 
 static inline int seccomp_mode(struct seccomp *s)
 {
@@ -73,6 +74,7 @@ static inline long prctl_set_seccomp(unsigned long arg2, char __user *arg3)
 {
 	return -EINVAL;
 }
+static inline void seccomp_default(struct task_struct *task) { }
 
 static inline int seccomp_mode(struct seccomp *s)
 {
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 54a0347ca812..92faee4cded4 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -1395,6 +1395,45 @@ SYSCALL_DEFINE3(seccomp, unsigned int, op, unsigned int, flags,
 	return do_seccomp(op, flags, uargs);
 }
 
+/* Certain processes should see all syscalls succeed. */
+void seccomp_default(struct task_struct *task)
+{
+	struct sock_filter filter[] = {
+		BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ERRNO | 0),
+	};
+	struct sock_fprog prog = {
+		.len = ARRAY_SIZE(filter),
+		.filter = filter,
+	};
+	static const char * const list[] = {
+		"syzkaller",
+		"syz-executor",
+		"trinity",
+	};
+	char comm[TASK_COMM_LEN];
+	mm_segment_t old_fs;
+	bool found = false;
+	int i;
+
+	get_task_comm(comm, task);
+
+	for (i = 0; i < ARRAY_SIZE(list); i++) {
+		if (!strncmp(comm, list[i], strlen(list[i]))) {
+			found = true;
+			break;
+		}
+	}
+
+	if (!found)
+		return;
+
+	old_fs = get_fs();
+	set_fs(KERNEL_DS);
+	seccomp_set_mode_filter(0, (void * __user)&prog);
+	set_fs(old_fs);
+}
+EXPORT_SYMBOL_GPL(seccomp_default);
+
 /**
  * prctl_set_seccomp: configures current->seccomp.mode
  * @seccomp_mode: requested mode to use
-- 
2.17.1


-- 
Kees Cook

  reply	other threads:[~2019-04-01 21:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01  9:01 [PATCH] fs/open: Fix most outstanding security bugs Johannes Thumshirn
2019-04-01 11:22 ` Matthew Wilcox
2019-04-01 11:48   ` Johannes Thumshirn
2019-04-01 11:53 ` Mukesh Ojha
2019-04-01 13:04 ` Torsten Duwe
2019-04-01 14:14 ` Nikolay Borisov
2019-04-01 17:28   ` Dmitry Vyukov
2019-04-01 21:27     ` Kees Cook [this message]
2019-04-01 17:38 ` Eric Biggers
2019-04-01 20:35 ` Darrick J. Wong
2019-04-02  7:56 ` Jessica Yu

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=20190401212710.GA28345@beast \
    --to=keescook@chromium.org \
    --cc=dvyukov@google.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=stable@vger.kernel.org \
    --cc=syzkaller@googlegroups.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.