On Thu, Dec 07, 2023 at 03:42:49PM -0800, Song Liu wrote: > Hi Frederick, > > On Thu, Dec 7, 2023 at 3:30 PM Frederick Lawler <fred@xxxxxxxxxxxxxx> wrote: > > > [...] > > > While, I think this may be doable with existing LSM hooks but we need > > > to probably have to cover multiple hook points needed to prevent one > > > action which makes a good case for another LSM hook, perhaps something > > > in the link->ops->detach path like > > > https://elixir.bootlin.com/linux/latest/source/kernel/bpf/syscall.c#L5074 > > > > > > What do you think? > > > > That's what I was thinking for option (4) "introduce a > > security_bpf_prog_unload()". Anyway, I agree. Paul brought up a good > > point that he'd like to see more discussion around this idea [1]. > > Mucking with the mounts (see below) is a bit of a mess, and there could > > still exist other methods for unloading I'm not aware of yet. > > > > Yesterday I whipped up a hack such that: > > > > mkdir -p /run/fs/bpf-lsm > > mount -t bpf none /run/fs/bpf-lsm > > ./load-policies /run/fs/bpf-lsm > > Trying to understand the solution here. Does load-policies add multiple > policies to stop different ways to unload the LSM BPF program (unpin, > umount, etc.)? So the only way to unload these policies is reboot. If this > is the case, could you please share the list of hooks needed to achieve a > secure result? ./load-policies loads multiple BPF object files (policy) each containing N programs. Then for each program, pin it to the bpffs and terminate. There's more there for atomic loads etc... but not relevant for answering the question. For this hack, I created a bpf object file with two programs: - lsm/sb_umount - lsm/inode_unlink More could be added to this list as necessary depending on finding other ways to unload. I've only found the filesystem to be the most consistent way so far. libbpf's unpin functions seem to be also trapped by the inode_unlink program, but more exploration syscalls is on my TODO list. And added the object file along with the rest to load in. > If the list is really long, we should probably add an option to > permanently load and attach a program (until reboot). This is an interesting thought as well. I think that would fall under idea (5) [1]. But the list isn't that long, and lonterm, I'd like the loader to have permission to load/unload BPF LSM progs. But, this won't help folks that leverage BPF's skeleton loading methods and users that rely on anon inodes tied to the task. I think KP offered some ideas there [2]. [1] https://lore.kernel.org/all/ZW+KYViDT3HWtKI1@CMGLRV3/ [2] https://lore.kernel.org/all/CACYkzJ4QpQZ8JmdNXKWeSh8oc=jAyRh4Zj98Z+TG37Ce=cfE0w@xxxxxxxxxxxxxx/ > > Thanks, > Song
