netdev - Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 20 Oct 2017 16:00:42 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     jlee@...e.com
Cc:     David Howells <dhowells@...hat.com>, linux-kernel@...r.kernel.org,
        jforbes@...hat.com, Daniel Borkmann <daniel@...earbox.net>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Gary Lin <GLin@...e.com>
Subject: Re: [PATCH 18/27] bpf: Restrict kernel image access functions when
 the kernel is locked down

On Fri, Oct 20, 2017 at 11:57:48PM +0800, jlee@...e.com wrote:
> On Fri, Oct 20, 2017 at 09:08:48AM +0100, David Howells wrote:
> > Hi Joey,
> > 
> > Should I just lock down sys_bpf() entirely for now?  We can always free it up
> > somewhat later.
> > 
> > David
> 
> OK~~ Please just remove my patch until we find out a way to
> verify bpf code or protect sensitive data in memory.
> 
> I think that we don't need to lock down sys_bpf() now because
> we didn't lock down other interfaces for reading arbitrary
> address like /dev/mem and /dev/kmem.

If you want to lock down read access you'd need to disable
not only bpf, but all of kprobe and likey ftrace, since
untrusted root can infer kernel data by observing function
execution even if it cannot load modules and bpf progs.