linux-kernel - Re: [PATCH bpf-next v9 0/8] MAC and Audit policy using eBPF (KRSI)

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]

Message-ID: <0165887d-e9d0-c03e-18b9-72e74a0cbd59@linux.intel.com>
Date:   Wed, 29 Apr 2020 15:31:47 +0300
From:   Mikko Ylinen <mikko.ylinen@...ux.intel.com>
To:     KP Singh <kpsingh@...omium.org>, linux-kernel@...r.kernel.org,
        bpf@...r.kernel.org, linux-security-module@...r.kernel.org
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        James Morris <jmorris@...ei.org>,
        Kees Cook <keescook@...omium.org>,
        Paul Turner <pjt@...gle.com>, Jann Horn <jannh@...gle.com>,
        Florent Revest <revest@...omium.org>,
        Brendan Jackman <jackmanb@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH bpf-next v9 0/8] MAC and Audit policy using eBPF (KRSI)

Hi,

On 29/03/2020 02:43, KP Singh wrote:
> # How does it work?
> 
> The patchset introduces a new eBPF (https://docs.cilium.io/en/v1.6/bpf/)
> program type BPF_PROG_TYPE_LSM which can only be attached to LSM hooks.
> Loading and attachment of BPF programs requires CAP_SYS_ADMIN.
> 
> The new LSM registers nop functions (bpf_lsm_<hook_name>) as LSM hook
> callbacks. Their purpose is to provide a definite point where BPF
> programs can be attached as BPF_TRAMP_MODIFY_RETURN trampoline programs
> for hooks that return an int, and BPF_TRAMP_FEXIT trampoline programs
> for void LSM hooks.

I have two systems (a NUC and a qemu VM) that fail to boot if I enable
the BPF LSM without enabling SELinux first. Anything I might be missing
or are you able to trigger it too?

For instance, the following additional cmdline args: "lsm.debug=1
lsm="capability,apparmor,bpf" results in:

[    1.251889] Call Trace:
[    1.252344]  dump_stack+0x57/0x7a
[    1.252951]  panic+0xe6/0x2a4
[    1.253497]  ? printk+0x43/0x45
[    1.254075]  mount_block_root+0x30c/0x31b
[    1.254798]  mount_root+0x78/0x7b
[    1.255417]  prepare_namespace+0x13a/0x16b
[    1.256168]  kernel_init_freeable+0x210/0x222
[    1.257021]  ? rest_init+0xa5/0xa5
[    1.257639]  kernel_init+0x9/0xfb
[    1.258074]  ret_from_fork+0x35/0x40
[    1.258885] Kernel Offset: 0x11000000 from 0xffffffff81000000 
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    1.264046] ---[ end Kernel panic - not syncing: VFS: Unable to mount 
root fs on unknown-block(253,3)

Taking out "bpf" or adding "selinux" before it boots OK. I've tried
with both 5.7-rc2 and -rc3.

LSM logs:

[    0.267219] LSM: Security Framework initializing
[    0.267844] LSM: first ordering: capability (enabled)
[    0.267870] LSM: cmdline ignored: capability
[    0.268869] LSM: cmdline ordering: apparmor (enabled)
[    0.269508] LSM: cmdline ordering: bpf (enabled)
[    0.269869] LSM: cmdline disabled: selinux
[    0.270377] LSM: cmdline disabled: integrity
[    0.270869] LSM: exclusive chosen: apparmor
[    0.271869] LSM: cred blob size     = 8
[    0.272354] LSM: file blob size     = 24
[    0.272869] LSM: inode blob size    = 0
[    0.273362] LSM: ipc blob size      = 0
[    0.273869] LSM: msg_msg blob size  = 0
[    0.274352] LSM: task blob size     = 32
[    0.274873] LSM: initializing capability
[    0.275381] LSM: initializing apparmor
[    0.275880] AppArmor: AppArmor initialized
[    0.276437] LSM: initializing bpf
[    0.276871] LSM support for eBPF active

-- Regards, Mikko