lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20180408074409.GD7362@linux-l9pv.suse> Date: Sun, 8 Apr 2018 15:44:09 +0800 From: joeyli <jlee@...e.com> To: Matthew Garrett <mjg59@...gle.com> Cc: alexei.starovoitov@...il.com, luto@...nel.org, David Howells <dhowells@...hat.com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, jmorris@...ei.org, Alan Cox <gnomes@...rguk.ukuu.org.uk>, Linus Torvalds <torvalds@...ux-foundation.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, jforbes@...hat.com, linux-man@...r.kernel.org, LSM List <linux-security-module@...r.kernel.org>, linux-api@...r.kernel.org, Kees Cook <keescook@...omium.org>, linux-efi <linux-efi@...r.kernel.org> Subject: Re: [GIT PULL] Kernel lockdown for secure boot On Wed, Apr 04, 2018 at 04:31:46AM +0000, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 7:34 PM Alexei Starovoitov < > alexei.starovoitov@...il.com> wrote: > > If the only thing that folks are paranoid about is reading > > arbitrary kernel memory with bpf_probe_read() helper > > then preferred patch would be to disable it during verification > > when in lockdown mode. > > No run-time overhead and android folks will be happy > > that lockdown doesn't break their work. > > They converted out-of-tree networking accounting > > module and corresponding user daemon to use bpf: > > https://www.linuxplumbersconf.org/2017/ocw/system/presentations/4791/original/eBPF%20cgroup%20filters%20for%20data%20usage%20accounting%20on%20Android.pdf > > An alternative would be to only disable kernel reads if the kernel contains > secrets that aren't supposed to be readable by root. If the keyring is > configured such that root can read everything, it seems like less of a > concern? Currently the KMK (kernel master key) can be a trusted key (TPM sealed) or a user key (plaintext). The EVM keeps a key (plaintext) in memory that it is decrypted from a KMK encrypted key. Those kernel reads functions should be disabled when the KMK be loaded to keyring. You idea is good that kernel can keep those reads functions enabled until KMK be loaded. Which means those functions are still available before user enables KMK and EVM. There have another idea is using a tree to register all sensitive data then blanking them when reading. Here is a very early developing version: https://github.com/joeyli/linux-sensitive_data/commits/sensitive-data-tree-v0.1-v4.15 But this approach causes runtime overhead and all sensitive data address must be found and registered (e.g. plaintext in encryption module) Thanks a lot! Joey Lee
Powered by blists - more mailing lists