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

On Thu, Jun 20, 2019 at 10:22 PM Andy Lutomirski [off-list ref] wrote:

On Thu, Jun 20, 2019 at 6:21 PM Matthew Garrett
[off-list ref] wrote:

quoted

--- 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.

The text is descriptive rather than normative, and no changes should
be made that alter the semantics of a reason - it makes more sense to
just add another reason.

I'd be more comfortable if the LSM only got to see "confidentiality"
or "integrity".

If LSM authors can be trusted to do the right thing here, then I see
no problem in providing additional data. I'm happy to defer to James
on that.