linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jlee@suse.com (joeyli)
To: linux-security-module@vger.kernel.org
Subject: Draft manpage explaining kernel lockdown
Date: Fri, 6 Oct 2017 15:46:49 +0800	[thread overview]
Message-ID: <20171006074649.GB3789@linux-l9pv.suse> (raw)
In-Reply-To: <7969.1507201224@warthog.procyon.org.uk>

Hi David,

On Thu, Oct 05, 2017 at 12:00:24PM +0100, David Howells wrote:
> Hi Ard, Michael,
> 
> Attached is a draft for a manual page (kernel_lockdown.7) that I intend to
> point at from messages emitted when the kernel prohibits something because the
> kernel is in 'lockdown' mode, typically triggered by EFI secure boot.
> 
> Let me know what you think.
> 
> David
> ---
[...snip]
> When lockdown is in effect, a number of things are disabled or restricted in
> use.  This includes special device files and kernel services that allow direct
> access of the kernel image:
> .P
> .RS
> /dev/mem
> .br
> /dev/kmem
> .br
> /dev/kcore
> .br
> /dev/ioports
> .br
> BPF memory access functions

Some information for note...

The BPF functions bpf_probe_read(), bpf_trace_printk() and
bpf_probe_write_user() need to be lockdown to avoid accessing
arbitrary addess.

Our original idea is trying to filter out senstivie data address
at runtime by eBPF verifier. But it can not be success. Gary Lin has
investigated and comment:

  Although eBPF verifier can stop the reading from the hard-coded address, 
  it's not able to stop reading arguments in the probed functions. So if 
  the malicious user attaches a eBPF program to a function that is used to 
  process the sensitive data, the eBPF program can print those arguments 
  easily and this might leak the passwords or private keys.

If we readlly want to allow eBPF code to access memory, then I think that the
bpf bytecode should be signed by trused key in system keyring.

> .RE
> .P

Another function may needs to be restrictred:

- The perf_event_open() with PERF_SAMPLE_REGS_INTR

  Jann Horn raised this concern. The tool can be used to grab register
  to peep sensitive data. We may need to block this tracing function.

Regards
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2017-10-06  7:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-05 11:00 Draft manpage explaining kernel lockdown David Howells
2017-10-05 11:07 ` Johannes Berg
2017-10-05 18:29   ` Randy Dunlap
2017-10-05 12:33 ` Florian Weimer
2017-10-05 13:16 ` David Howells
2017-10-05 13:20 ` David Howells
2017-10-05 13:53 ` Ard Biesheuvel
2017-10-06  7:46 ` joeyli [this message]
2017-10-18  8:21 ` Michael Kerrisk (man-pages)

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=20171006074649.GB3789@linux-l9pv.suse \
    --to=jlee@suse.com \
    --cc=linux-security-module@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).