netdev - Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode

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:   Wed, 26 Jun 2019 17:57:12 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     James Morris <jmorris@...ei.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Matthew Garrett <matthewgarrett@...gle.com>,
        linux-security@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Network Development <netdev@...r.kernel.org>,
        Chun-Yi Lee <jlee@...e.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        linux-security-module@...r.kernel.org
Subject: Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode



> On Jun 26, 2019, at 1:22 PM, James Morris <jmorris@...ei.org> wrote:
> 
> [Adding the LSM mailing list: missed this patchset initially]
> 
>> On Thu, 20 Jun 2019, Andy Lutomirski wrote:
>> 
>> This patch exemplifies why I don't like this approach:
>> 
>>> @@ -97,6 +97,7 @@ enum lockdown_reason {
>>>        LOCKDOWN_INTEGRITY_MAX,
>>>        LOCKDOWN_KCORE,
>>>        LOCKDOWN_KPROBES,
>>> +       LOCKDOWN_BPF,
>>>        LOCKDOWN_CONFIDENTIALITY_MAX,
>> 
>>> --- a/security/lockdown/lockdown.c
>>> +++ b/security/lockdown/lockdown.c
>>> @@ -33,6 +33,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
>>>        [LOCKDOWN_INTEGRITY_MAX] = "integrity",
>>>        [LOCKDOWN_KCORE] = "/proc/kcore access",
>>>        [LOCKDOWN_KPROBES] = "use of kprobes",
>>> +       [LOCKDOWN_BPF] = "use of bpf",
>>>        [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
>> 
>> The text here says "use of bpf", but what this patch is *really* doing
>> is locking down use of BPF to read kernel memory.  If the details
>> change, then every LSM needs to get updated, and we risk breaking user
>> policies that are based on LSMs that offer excessively fine
>> granularity.
> 
> Can you give an example of how the details might change?
> 
>> I'd be more comfortable if the LSM only got to see "confidentiality"
>> or "integrity".
> 
> These are not sufficient for creating a useful policy for the SELinux 
> case.
> 
> 

I may have misunderstood, but I thought that SELinux mainly needed to allow certain privileged programs to bypass the policy.  Is there a real example of what SELinux wants to do that can’t be done in the simplified model?

The think that specifically makes me uneasy about exposing all of these precise actions to LSMs is that they will get exposed to userspace in a way that forces us to treat them as stable ABIs.