All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Laura Abbott <labbott@redhat.com>
Cc: "Tobin C. Harding" <me@tobin.cc>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Kees Cook <keescook@chromium.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Tycho Andersen <tycho@docker.com>,
	"Roberts, William C" <william.c.roberts@intel.com>,
	Tejun Heo <tj@kernel.org>,
	Jordan Glover <Golden_Miller83@protonmail.ch>,
	Greg KH <gregkh@linuxfoundation.org>,
	Petr Mladek <pmladek@suse.com>, Joe Perches <joe@perches.com>,
	Ian Campbell <ijc@hellion.org.uk>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <wilal.deacon@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Chris Fries <cfries@google.com>,
	Dave Weinstein <olorin@google.com>,
	Daniel Micay <danielmicay@gmail.com>,
	Djalal Harouni <tixxdz@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl
Date: Tue, 7 Nov 2017 16:59:56 -0800	[thread overview]
Message-ID: <CA+55aFwiaQezaPi2nzmyuFZNgR3PFcsWjjBTHJYBesKrh-Q_pQ@mail.gmail.com> (raw)
In-Reply-To: <ec5a3690-a8c2-0329-66c0-ed7dda5db958@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

On Tue, Nov 7, 2017 at 3:36 PM, Laura Abbott <labbott@redhat.com> wrote:
>
> I'd probably put /proc/kallsyms and /proc/modules on the omit list
> since those are designed to leak addresses to userspace.

Well, they are indeed designed to leak addresses, but not a lot of
people should care.

So I think we could tighten them up.

For example, maybe /proc/kallsyms could just default to not showing
values to non-root users.

We *did* originally try to use "kptr_restrict" with a default value of
1, it's just that it was never fixable on a case-by-case basis as
people started saying "that breaks my flow, because xyz".

But if we do it for one file at a time, we probably *can* try to fix complaints.

Something like the attached TOTALLY UNTESTED patch. It's meant more as
an RFC, not for application, but it's also meant to show how we can
tailor the behavior for specific workflow issues.

So take that "kallsyms_for_perf()" thing as an example of how we can
say "hey, if you already have access to kernel profiling anyway,
there's no point in hiding kallsyms".

And there may be other similar things we can do.

The situation with /proc/modules should be similar. Using
kptr_restrict was a big hammer and might have broken something
unrelated, but did anybody actually care about the particular case of
/proc/modules not showing the module address to normal users? probably
not. "lsmod" certainly doesn't care, and that's what people really
want.

Both /proc/kallsyms and /proc/modules _used_ to be really important
for oops reporting, but that was long ago when the kernel didn't
report symbol information of its own. So we have historical reasons
for people to be able to read those files, but those are mainly things
that aren't relevant (or even possible) on modern kernels anyway.

So I don'r think we should omit /proc/kallsyms and /proc/modules - we
should just fix them.

The attached patch may not be good enough as is, but maybe something
_like_ it will work well enough that people won't care?

(And do note the "TOTALLY UNTESTED". It seems to compile. But maybe I
got some test exactly the wrong way around and it doesn't actually
_work_. Caveat testor).

                     Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 2543 bytes --]

 kernel/kallsyms.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 127e7cfafa55..5b1299c1e4b0 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -480,6 +480,7 @@ struct kallsym_iter {
 	char name[KSYM_NAME_LEN];
 	char module_name[MODULE_NAME_LEN];
 	int exported;
+	int show_value;
 };
 
 static int get_ksymbol_mod(struct kallsym_iter *iter)
@@ -580,14 +581,23 @@ static void s_stop(struct seq_file *m, void *p)
 {
 }
 
+#ifndef CONFIG_64BIT
+# define KALLSYM_FMT "%08lx"
+#else
+# define KALLSYM_FMT "%016lx"
+#endif
+
 static int s_show(struct seq_file *m, void *p)
 {
+	unsigned long value;
 	struct kallsym_iter *iter = m->private;
 
 	/* Some debugging symbols have no name.  Ignore them. */
 	if (!iter->name[0])
 		return 0;
 
+	value = iter->show_value ? iter->value : 0;
+
 	if (iter->module_name[0]) {
 		char type;
 
@@ -597,10 +607,10 @@ static int s_show(struct seq_file *m, void *p)
 		 */
 		type = iter->exported ? toupper(iter->type) :
 					tolower(iter->type);
-		seq_printf(m, "%pK %c %s\t[%s]\n", (void *)iter->value,
+		seq_printf(m, KALLSYM_FMT " %c %s\t[%s]\n", value,
 			   type, iter->name, iter->module_name);
 	} else
-		seq_printf(m, "%pK %c %s\n", (void *)iter->value,
+		seq_printf(m, KALLSYM_FMT " %c %s\n", value,
 			   iter->type, iter->name);
 	return 0;
 }
@@ -612,6 +622,40 @@ static const struct seq_operations kallsyms_op = {
 	.show = s_show
 };
 
+static inline int kallsyms_for_perf(void)
+{
+#ifdef CONFIG_PERF_EVENTS
+	extern int sysctl_perf_event_paranoid;
+	if (sysctl_perf_event_paranoid <= 0)
+		return 1;
+#endif
+	return 0;
+}
+
+/*
+ * We show kallsyms information even to normal users if we've enabled
+ * kernel profiling and are explicitly not paranoid (so kptr_restrict
+ * is clear, and sysctl_perf_event_paranoid isn't set).
+ *
+ * Otherwise, require CAP_SYSLOG (assuming kptr_restrict isn't set to
+ * block even that).
+ */
+static int kallsyms_show_value(void)
+{
+	switch (kptr_restrict) {
+	case 0:
+		if (kallsyms_for_perf())
+			return 1;
+	/* fallthrough */
+	case 1:
+		if (has_capability_noaudit(current, CAP_SYSLOG))
+			return 1;
+	/* fallthrough */
+	default:
+		return 0;
+	}
+}
+
 static int kallsyms_open(struct inode *inode, struct file *file)
 {
 	/*
@@ -625,6 +669,7 @@ static int kallsyms_open(struct inode *inode, struct file *file)
 		return -ENOMEM;
 	reset_iter(iter, 0);
 
+	iter->show_value = kallsyms_show_value();
 	return 0;
 }
 

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Laura Abbott <labbott@redhat.com>
Cc: "Tobin C. Harding" <me@tobin.cc>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Kees Cook <keescook@chromium.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Tycho Andersen <tycho@docker.com>,
	"Roberts, William C" <william.c.roberts@intel.com>,
	Tejun Heo <tj@kernel.org>,
	Jordan Glover <Golden_Miller83@protonmail.ch>,
	Greg KH <gregkh@linuxfoundation.org>,
	Petr Mladek <pmladek@suse.com>, Joe Perches <joe@perches.com>,
	Ian Campbell <ijc@hellion.org.uk>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <wilal.deacon@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Chris Fries <cfries@google.com>,
Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl
Date: Tue, 7 Nov 2017 16:59:56 -0800	[thread overview]
Message-ID: <CA+55aFwiaQezaPi2nzmyuFZNgR3PFcsWjjBTHJYBesKrh-Q_pQ@mail.gmail.com> (raw)
In-Reply-To: <ec5a3690-a8c2-0329-66c0-ed7dda5db958@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

On Tue, Nov 7, 2017 at 3:36 PM, Laura Abbott <labbott@redhat.com> wrote:
>
> I'd probably put /proc/kallsyms and /proc/modules on the omit list
> since those are designed to leak addresses to userspace.

Well, they are indeed designed to leak addresses, but not a lot of
people should care.

So I think we could tighten them up.

For example, maybe /proc/kallsyms could just default to not showing
values to non-root users.

We *did* originally try to use "kptr_restrict" with a default value of
1, it's just that it was never fixable on a case-by-case basis as
people started saying "that breaks my flow, because xyz".

But if we do it for one file at a time, we probably *can* try to fix complaints.

Something like the attached TOTALLY UNTESTED patch. It's meant more as
an RFC, not for application, but it's also meant to show how we can
tailor the behavior for specific workflow issues.

So take that "kallsyms_for_perf()" thing as an example of how we can
say "hey, if you already have access to kernel profiling anyway,
there's no point in hiding kallsyms".

And there may be other similar things we can do.

The situation with /proc/modules should be similar. Using
kptr_restrict was a big hammer and might have broken something
unrelated, but did anybody actually care about the particular case of
/proc/modules not showing the module address to normal users? probably
not. "lsmod" certainly doesn't care, and that's what people really
want.

Both /proc/kallsyms and /proc/modules _used_ to be really important
for oops reporting, but that was long ago when the kernel didn't
report symbol information of its own. So we have historical reasons
for people to be able to read those files, but those are mainly things
that aren't relevant (or even possible) on modern kernels anyway.

So I don'r think we should omit /proc/kallsyms and /proc/modules - we
should just fix them.

The attached patch may not be good enough as is, but maybe something
_like_ it will work well enough that people won't care?

(And do note the "TOTALLY UNTESTED". It seems to compile. But maybe I
got some test exactly the wrong way around and it doesn't actually
_work_. Caveat testor).

                     Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 2543 bytes --]

 kernel/kallsyms.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 127e7cfafa55..5b1299c1e4b0 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -480,6 +480,7 @@ struct kallsym_iter {
 	char name[KSYM_NAME_LEN];
 	char module_name[MODULE_NAME_LEN];
 	int exported;
+	int show_value;
 };
 
 static int get_ksymbol_mod(struct kallsym_iter *iter)
@@ -580,14 +581,23 @@ static void s_stop(struct seq_file *m, void *p)
 {
 }
 
+#ifndef CONFIG_64BIT
+# define KALLSYM_FMT "%08lx"
+#else
+# define KALLSYM_FMT "%016lx"
+#endif
+
 static int s_show(struct seq_file *m, void *p)
 {
+	unsigned long value;
 	struct kallsym_iter *iter = m->private;
 
 	/* Some debugging symbols have no name.  Ignore them. */
 	if (!iter->name[0])
 		return 0;
 
+	value = iter->show_value ? iter->value : 0;
+
 	if (iter->module_name[0]) {
 		char type;
 
@@ -597,10 +607,10 @@ static int s_show(struct seq_file *m, void *p)
 		 */
 		type = iter->exported ? toupper(iter->type) :
 					tolower(iter->type);
-		seq_printf(m, "%pK %c %s\t[%s]\n", (void *)iter->value,
+		seq_printf(m, KALLSYM_FMT " %c %s\t[%s]\n", value,
 			   type, iter->name, iter->module_name);
 	} else
-		seq_printf(m, "%pK %c %s\n", (void *)iter->value,
+		seq_printf(m, KALLSYM_FMT " %c %s\n", value,
 			   iter->type, iter->name);
 	return 0;
 }
@@ -612,6 +622,40 @@ static const struct seq_operations kallsyms_op = {
 	.show = s_show
 };
 
+static inline int kallsyms_for_perf(void)
+{
+#ifdef CONFIG_PERF_EVENTS
+	extern int sysctl_perf_event_paranoid;
+	if (sysctl_perf_event_paranoid <= 0)
+		return 1;
+#endif
+	return 0;
+}
+
+/*
+ * We show kallsyms information even to normal users if we've enabled
+ * kernel profiling and are explicitly not paranoid (so kptr_restrict
+ * is clear, and sysctl_perf_event_paranoid isn't set).
+ *
+ * Otherwise, require CAP_SYSLOG (assuming kptr_restrict isn't set to
+ * block even that).
+ */
+static int kallsyms_show_value(void)
+{
+	switch (kptr_restrict) {
+	case 0:
+		if (kallsyms_for_perf())
+			return 1;
+	/* fallthrough */
+	case 1:
+		if (has_capability_noaudit(current, CAP_SYSLOG))
+			return 1;
+	/* fallthrough */
+	default:
+		return 0;
+	}
+}
+
 static int kallsyms_open(struct inode *inode, struct file *file)
 {
 	/*
@@ -625,6 +669,7 @@ static int kallsyms_open(struct inode *inode, struct file *file)
 		return -ENOMEM;
 	reset_iter(iter, 0);
 
+	iter->show_value = kallsyms_show_value();
 	return 0;
 }
 

  reply	other threads:[~2017-11-08  1:00 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07 10:32 [PATCH v4] scripts: add leaking_addresses.pl Tobin C. Harding
2017-11-07 10:32 ` [kernel-hardening] " Tobin C. Harding
2017-11-07 10:32 ` Tobin C. Harding
2017-11-07 10:50 ` Greg KH
2017-11-07 10:50   ` [kernel-hardening] " Greg KH
2017-11-07 10:50   ` Greg KH
2017-11-07 20:51   ` Tobin C. Harding
2017-11-07 20:51     ` [kernel-hardening] " Tobin C. Harding
2017-11-07 20:51     ` Tobin C. Harding
2017-11-07 13:56 ` David Laight
2017-11-07 13:56   ` [kernel-hardening] " David Laight
2017-11-07 13:56   ` David Laight
2017-11-07 20:58   ` Tobin C. Harding
2017-11-07 20:58     ` [kernel-hardening] " Tobin C. Harding
2017-11-07 20:58     ` Tobin C. Harding
2017-11-07 21:11     ` Linus Torvalds
2017-11-07 21:11       ` [kernel-hardening] " Linus Torvalds
2017-11-07 21:11       ` Linus Torvalds
2017-11-07 15:51 ` Petr Mladek
2017-11-07 15:51   ` [kernel-hardening] " Petr Mladek
2017-11-07 15:51   ` Petr Mladek
2017-11-07 20:39   ` Tobin C. Harding
2017-11-07 20:39     ` [kernel-hardening] " Tobin C. Harding
2017-11-07 20:39     ` Tobin C. Harding
2017-11-07 23:36 ` [kernel-hardening] " Laura Abbott
2017-11-07 23:36   ` Laura Abbott
2017-11-08  0:59   ` Linus Torvalds [this message]
2017-11-08  0:59     ` Linus Torvalds
2017-11-08  0:59     ` Linus Torvalds
2017-11-08 20:39     ` Linus Torvalds
2017-11-08 20:39       ` Linus Torvalds
2017-11-08 20:39       ` Linus Torvalds
2017-11-09  4:43       ` Kaiwan N Billimoria
2017-11-09  4:43         ` Kaiwan N Billimoria
2017-11-09  4:43         ` Kaiwan N Billimoria
2017-11-09  4:54         ` Kaiwan N Billimoria
2017-11-09  4:54           ` Kaiwan N Billimoria
2017-11-09  4:54           ` Kaiwan N Billimoria
2017-11-09 18:11           ` Steven Rostedt
2017-11-09 18:11             ` Steven Rostedt
2017-11-09 18:11             ` Steven Rostedt
2017-11-10  3:03             ` Kaiwan N Billimoria
2017-11-10  3:03               ` Kaiwan N Billimoria
2017-11-10  3:03               ` Kaiwan N Billimoria
2017-11-08  1:13   ` Tobin C. Harding
2017-11-08  1:13     ` Tobin C. Harding
2017-11-08 12:10 ` [kernel-hardening] " Michael Ellerman
2017-11-08 12:10   ` Michael Ellerman
2017-11-08 12:10   ` Michael Ellerman
2017-11-08 21:16   ` Tobin C. Harding
2017-11-08 21:16     ` Tobin C. Harding
2017-11-08 22:48   ` Tobin C. Harding
2017-11-08 22:48     ` Tobin C. Harding
2017-11-09  0:49     ` Michael Ellerman
2017-11-09  0:49       ` Michael Ellerman
2017-11-09  0:49       ` Michael Ellerman
2017-11-09  2:08       ` Tobin C. Harding
2017-11-09  2:08         ` Tobin C. Harding
2017-11-10 22:12   ` [kernel-hardening] " Frank Rowand
2017-11-10 22:12     ` Frank Rowand
2017-11-12 11:49     ` Michael Ellerman
2017-11-12 11:49       ` Michael Ellerman
2017-11-12 11:49       ` Michael Ellerman
2017-11-12 18:02       ` Frank Rowand
2017-11-12 18:02         ` Frank Rowand
2017-11-12 21:18         ` Tobin C. Harding
2017-11-12 21:18           ` Tobin C. Harding
2017-11-13  1:06         ` Michael Ellerman
2017-11-13  1:06           ` Michael Ellerman
2017-11-13  1:06           ` Michael Ellerman
2017-11-10 13:56 ` kaiwan.billimoria
2017-11-10 13:56   ` kaiwan.billimoria
2017-11-12 22:21   ` Tobin C. Harding
2017-11-12 22:21     ` Tobin C. Harding
2017-11-13  5:46     ` kaiwan.billimoria
2017-11-13  5:46       ` kaiwan.billimoria
2017-11-13  6:08       ` Tobin C. Harding
2017-11-13  6:08         ` Tobin C. Harding
2017-11-13  6:52         ` Kaiwan N Billimoria
2017-11-13  6:52           ` Kaiwan N Billimoria
2017-11-20 15:39       ` [kernel-hardening] " Petr Mladek
2017-11-20 15:39         ` Petr Mladek
2017-11-19 23:56   ` [kernel-hardening] " Tobin C. Harding
2017-11-19 23:56     ` Tobin C. Harding
2017-11-11 23:10 ` Kirill A. Shutemov
2017-11-11 23:10   ` [kernel-hardening] " Kirill A. Shutemov
2017-11-11 23:10   ` Kirill A. Shutemov
2017-11-12 23:06   ` Tobin C. Harding
2017-11-12 23:06     ` [kernel-hardening] " Tobin C. Harding
2017-11-12 23:06     ` Tobin C. Harding
2017-11-13  3:37     ` Kirill A. Shutemov
2017-11-13  3:37       ` [kernel-hardening] " Kirill A. Shutemov
2017-11-13  3:37       ` Kirill A. Shutemov
2017-11-13  4:35       ` Tobin C. Harding
2017-11-13  4:35         ` [kernel-hardening] " Tobin C. Harding
2017-11-13  4:35         ` Tobin C. Harding
2017-11-13  5:27         ` [kernel-hardening] " Kaiwan N Billimoria
2017-11-13  5:27           ` Kaiwan N Billimoria

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=CA+55aFwiaQezaPi2nzmyuFZNgR3PFcsWjjBTHJYBesKrh-Q_pQ@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=Golden_Miller83@protonmail.ch \
    --cc=Jason@zx2c4.com \
    --cc=catalin.marinas@arm.com \
    --cc=cfries@google.com \
    --cc=danielmicay@gmail.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=ijc@hellion.org.uk \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@tobin.cc \
    --cc=netdev@vger.kernel.org \
    --cc=olorin@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tixxdz@gmail.com \
    --cc=tj@kernel.org \
    --cc=tycho@docker.com \
    --cc=tytso@mit.edu \
    --cc=wilal.deacon@arm.com \
    --cc=william.c.roberts@intel.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.