linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Andy Lutomirski <luto@kernel.org>, Matthew Garrett <mjg59@google.com>
Cc: James Morris <jmorris@namei.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Network Development <netdev@vger.kernel.org>,
	Chun-Yi Lee <jlee@suse.com>, Jann Horn <jannh@google.com>,
	bpf@vger.kernel.org
Subject: Re: [PATCH V34 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
Date: Mon, 24 Jun 2019 22:59:57 +0200	[thread overview]
Message-ID: <7f36edf7-3120-975e-b643-3c0fa470bafd@iogearbox.net> (raw)
In-Reply-To: <CALCETrWmZX3R1L88Gz9vLY68gcK8zSXL4cA4GqAzQoyqSR7rRQ@mail.gmail.com>

On 06/24/2019 10:08 PM, Andy Lutomirski wrote:
> On Mon, Jun 24, 2019 at 12:54 PM Matthew Garrett <mjg59@google.com> wrote:
>> On Mon, Jun 24, 2019 at 8:37 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>> On 06/22/2019 02:03 AM, Matthew Garrett wrote:
>>>> From: David Howells <dhowells@redhat.com>
>>>>
>>>> There are some bpf functions can be used to read kernel memory:
>>>
>>> Nit: that
>>
>> Fixed.
>>
>>>> bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.  These allow
>>>
>>> Please explain how bpf_probe_write_user reads kernel memory ... ?!
>>
>> Ha.
>>
>>>> private keys in kernel memory (e.g. the hibernation image signing key) to
>>>> be read by an eBPF program and kernel memory to be altered without
>>>
>>> ... and while we're at it, also how they allow "kernel memory to be
>>> altered without restriction". I've been pointing this false statement
>>> out long ago.
>>
>> Yup. How's the following description:
>>
>>     bpf: Restrict bpf when kernel lockdown is in confidentiality mode
>>
>>     There are some bpf functions that can be used to read kernel memory and
>>     exfiltrate it to userland: bpf_probe_read, bpf_probe_write_user and
>>     bpf_trace_printk.  These could be abused to (eg) allow private
>> keys in kernel
>>     memory to be leaked. Disable them if the kernel has been locked
>> down in confidentiality
>>     mode.
> 
> I'm confused.  I understand why we're restricting bpf_probe_read().
> Why are we restricting bpf_probe_write_user() and bpf_trace_printk(),
> though?

Agree, for example, bpf_probe_write_user() can never write into
kernel memory (only user one). Just thinking out loud, wouldn't it
be cleaner and more generic to perform this check at the actual function
which performs the kernel memory without faulting? All three of these
are in mm/maccess.c, and the very few occasions that override the
probe_kernel_read symbol are calling eventually into __probe_kernel_read(),
so this would catch all of them wrt lockdown restrictions. Otherwise
you'd need to keep tracking every bit of new code being merged that
calls into one of these, no? That way you only need to do it once like
below and are guaranteed that the check catches these in future as well.

Thanks,
Daniel

diff --git a/mm/maccess.c b/mm/maccess.c
index 482d4d6..2c8220f 100644
--- a/mm/maccess.c
+++ b/mm/maccess.c
@@ -29,6 +29,9 @@ long __probe_kernel_read(void *dst, const void *src, size_t size)
 	long ret;
 	mm_segment_t old_fs = get_fs();

+	if (security_locked_down(LOCKDOWN_KERNEL_READ))
+		return -EFAULT;
+
 	set_fs(KERNEL_DS);
 	pagefault_disable();
 	ret = __copy_from_user_inatomic(dst,
@@ -57,6 +60,9 @@ long __probe_kernel_write(void *dst, const void *src, size_t size)
 	long ret;
 	mm_segment_t old_fs = get_fs();

+	if (security_locked_down(LOCKDOWN_KERNEL_WRITE))
+		return -EFAULT;
+
 	set_fs(KERNEL_DS);
 	pagefault_disable();
 	ret = __copy_to_user_inatomic((__force void __user *)dst, src, size);
@@ -90,6 +96,9 @@ long strncpy_from_unsafe(char *dst, const void *unsafe_addr, long count)
 	const void *src = unsafe_addr;
 	long ret;

+	if (security_locked_down(LOCKDOWN_KERNEL_READ))
+		return -EFAULT;
+
 	if (unlikely(count <= 0))
 		return 0;


  parent reply	other threads:[~2019-06-24 21:22 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-22  0:03 [PATCH V34 00/29] Lockdown as an LSM Matthew Garrett
2019-06-22  0:03 ` [PATCH V34 01/29] security: Support early LSMs Matthew Garrett
2019-06-22 23:36   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 02/29] security: Add a "locked down" LSM hook Matthew Garrett
2019-06-22 23:37   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 03/29] security: Add a static lockdown policy LSM Matthew Garrett
2019-06-22 23:37   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 04/29] Enforce module signatures if the kernel is locked down Matthew Garrett
2019-06-22 23:48   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 05/29] Restrict /dev/{mem,kmem,port} when " Matthew Garrett
2019-06-22 23:52   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 06/29] kexec_load: Disable at runtime if " Matthew Garrett
2019-06-22 23:52   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 07/29] Copy secure_boot flag in boot params across kexec reboot Matthew Garrett
2019-06-22 23:53   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 08/29] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE Matthew Garrett
2019-06-24  2:01   ` Dave Young
2019-06-25  2:35     ` Dave Young
2019-06-22  0:03 ` [PATCH V34 09/29] kexec_file: Restrict at runtime if the kernel is locked down Matthew Garrett
2019-06-22 23:54   ` Kees Cook
2019-06-27  4:59   ` James Morris
2019-06-27 15:28     ` Matthew Garrett
2019-06-27 18:14       ` James Morris
2019-06-27 23:17         ` Matthew Garrett
2019-06-22  0:03 ` [PATCH V34 10/29] hibernate: Disable when " Matthew Garrett
2019-06-22 17:52   ` Pavel Machek
2019-06-24 13:21     ` Jiri Kosina
2019-07-10 15:26       ` Joey Lee
2019-07-11  4:11       ` joeyli
2019-06-22 23:55   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 11/29] PCI: Lock down BAR access " Matthew Garrett
2019-06-22 23:55   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 12/29] x86: Lock down IO port " Matthew Garrett
2019-06-22 23:58   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 13/29] x86/msr: Restrict MSR " Matthew Garrett
2019-06-22  0:03 ` [PATCH V34 14/29] ACPI: Limit access to custom_method " Matthew Garrett
2019-06-22 23:59   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 15/29] acpi: Ignore acpi_rsdp kernel param when the kernel has been " Matthew Garrett
2019-06-22 23:59   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 16/29] acpi: Disable ACPI table override if the kernel is " Matthew Garrett
2019-06-23  0:00   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 17/29] Prohibit PCMCIA CIS storage when " Matthew Garrett
2019-06-23  0:00   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 18/29] Lock down TIOCSSERIAL Matthew Garrett
2019-06-23  0:01   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 19/29] Lock down module params that specify hardware parameters (eg. ioport) Matthew Garrett
2019-06-23  0:04   ` Kees Cook
2019-06-27  1:49   ` Daniel Axtens
2019-06-27 15:30     ` Matthew Garrett
2019-06-22  0:03 ` [PATCH V34 20/29] x86/mmiotrace: Lock down the testmmiotrace module Matthew Garrett
2019-06-23  0:04   ` Kees Cook
2019-06-23 11:08   ` Thomas Gleixner
2019-06-22  0:03 ` [PATCH V34 21/29] Lock down /proc/kcore Matthew Garrett
2019-06-23  0:05   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 22/29] Lock down tracing and perf kprobes when in confidentiality mode Matthew Garrett
2019-06-23  0:09   ` Kees Cook
2019-06-23  1:57   ` Masami Hiramatsu
2019-06-22  0:03 ` [PATCH V34 23/29] bpf: Restrict bpf when kernel lockdown is " Matthew Garrett
2019-06-23  0:09   ` Kees Cook
2019-06-24 15:15   ` Daniel Borkmann
2019-06-24 19:54     ` Matthew Garrett
2019-06-24 20:08       ` Andy Lutomirski
2019-06-24 20:15         ` Matthew Garrett
2019-06-24 20:59         ` Daniel Borkmann [this message]
2019-06-24 21:30           ` Matthew Garrett
2019-06-22  0:03 ` [PATCH V34 24/29] Lock down perf when " Matthew Garrett
2019-06-23  0:12   ` Kees Cook
2019-06-22  0:03 ` [PATCH V34 25/29] kexec: Allow kexec_file() with appropriate IMA policy when locked down Matthew Garrett
2019-06-22  0:03 ` [PATCH V34 26/29] debugfs: Restrict debugfs when the kernel is " Matthew Garrett
2019-06-22  0:03 ` [PATCH V34 27/29] tracefs: Restrict tracefs " Matthew Garrett
2019-06-22  0:03 ` [PATCH V34 28/29] efi: Restrict efivar_ssdt_load " Matthew Garrett
2019-06-23  0:14   ` Kees Cook
2019-06-25 15:00   ` Ard Biesheuvel
2019-06-22  0:03 ` [PATCH V34 29/29] lockdown: Print current->comm in restriction messages Matthew Garrett
2019-06-23  0:25   ` Kees Cook
2019-06-24 23:01 ` [PATCH V34 00/29] Lockdown as an LSM James Morris
2019-06-24 23:47   ` Casey Schaufler
2019-06-24 23:56   ` Matthew Garrett
2019-06-25  6:04     ` James Morris
2019-06-25  8:16   ` John Johansen

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=7f36edf7-3120-975e-b643-3c0fa470bafd@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=jannh@google.com \
    --cc=jlee@suse.com \
    --cc=jmorris@namei.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mjg59@google.com \
    --cc=netdev@vger.kernel.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).