linux-kernel - Re: [PATCH 20/24] 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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 6 Apr 2017 13:40:20 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     David Howells <dhowells@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
        "<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
        Chun-Yi Lee <jlee@...e.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        keyrings@...r.kernel.org,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Matthew Garrett <matthew.garrett@...ula.com>
Subject: Re: [PATCH 20/24] bpf: Restrict kernel image access functions when
 the kernel is locked down

On 6 April 2017 at 13:29, Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
> On Wed, Apr 05, 2017 at 09:17:25PM +0100, David Howells wrote:
>> From: Chun-Yi Lee <jlee@...e.com>
>>
>> There are some bpf functions can be used to read kernel memory:
>> bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.  These allow
>> private keys in kernel memory (e.g. the hibernation image signing key) to
>> be read by an eBPF program.  Prohibit those functions when the kernel is
>> locked down.
>>
>> Signed-off-by: Chun-Yi Lee <jlee@...e.com>
>> Signed-off-by: David Howells <dhowells@...hat.com>
>> cc: netdev@...r.kernel.org
>> ---
>>
>>  kernel/trace/bpf_trace.c |   11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
>> index cee9802cf3e0..7fde851f207b 100644
>> --- a/kernel/trace/bpf_trace.c
>> +++ b/kernel/trace/bpf_trace.c
>> @@ -65,6 +65,11 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size, const void *, unsafe_ptr)
>>  {
>>       int ret;
>>
>> +     if (kernel_is_locked_down()) {
>> +             memset(dst, 0, size);
>> +             return -EPERM;
>> +     }
>
> this will obviously break the program. How about disabling loading tracing
> programs during the lockdown completely?
>
> Also is there a description of what this lockdown trying to accomplish?
> The cover letter is scarce in details.
>

This is a very good point, and this is actually feedback that was
given (by Alan Cox, iirc) the last time this series was circulated.

This series is a mixed bag of patches that all look like they improve
'security' in one way or the other. But what is lacking is a coherent
view on the threat model, and to what extent all these patches reduce
the vulnerability to such threats. Without that, these patches do very
little beyond giving a false sense of security, imo.