On Wed, Apr 23, 2025 at 7:12 AM James Bottomley James.Bottomley@hansenpartnership.com wrote:
On Mon, 2025-04-21 at 13:12 -0700, Alexei Starovoitov wrote: [...]
Calling bpf_map_get() and map->ops->map_lookup_elem() from a module is not ok either.
I don't understand this objection.
Consider an LSM that hooks into security_bprm_*(bprm), parses something in linux_binprm, then struct file *file = fd_file(fdget(some_random_file_descriptor_in_current)); file->f_op->read(..);
Would VFS maintainers approve such usage ?
More so, your LSM does file = get_task_exe_file(current); kernel_read_file(file, ...);
This is even worse. You've corrupted the ELF binary with extra garbage at the end. objdump/elfutils will choke on it and you're lucky that binfmt_elf still loads it. The whole approach is a non-starter.
The program just got passed in to bpf_prog_load() as a set of attributes which, for a light skeleton, directly contain the code as a blob and have the various BTF relocations as a blob in a single element array map. I think everyone agrees that the integrity of the program would be compromised by modifications to the relocations, so the security_bpf_prog_load() hook can't make an integrity determination without examining both. If the hook can't use the bpf_maps.. APIs directly is there some other API it should be using to get the relocations, or are you saying that the security_bpf_prog_load() hook isn't fit for purpose and it should be called after the bpf core has loaded the relocations so they can be provided to the hook as an argument?
No. As I said twice already the only place to verify program signature is a bpf subsystem itself. Hacking into bpf internals from LSM, BPF-LSM program, or any other kernel subsystem is a no go.
The above, by the way, is independent of signing, because it applies to any determination that might be made in the security_bpf_prog_load() hook regardless of purpose.
security_bpf_prog_load() should not access bpf internals. That LSM hook sees the following: security_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *attr, struct bpf_token *token, bool kernel);
LSM can look into uapi things there. Like prog->sleepable, prog->tag, prog->aux->name, but things like prog->aux->jit_data or prog->aux->used_maps are not ok to access. If in doubt, ask on the mailing list.