Hi Frederick, On Thu, Dec 7, 2023 at 4:21 PM Frederick Lawler <fred@xxxxxxxxxxxxxx> wrote: > > 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: > > > [...] > > 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 Thanks for the information. This seems easy enough. > 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 Agreed this falls under idea (5). > 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]. Thanks, Song
