On Wed, Apr 23, 2025 at 7:12 AM James Bottomley
<james.bottom...@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.
