> > > > IMHO this is the best option. Here: > > > > * BPF LSM Program = MAC Policy > > * Removing / detaching / updating programs = Updating MAC policy > > What happens if a privileged user terminates the BPF LSM task and > deletes any pinned BPF files that might exist? The LSM program is pinned, so it does not matter if the task is terminated. > We can apply specific capabilities to restrict access, but it's > important to note that privileged users might also possess these That depends on how you implement your restriction logic. If your LSM program says, check CAP_MAC_ADMIN -> Allow removal, then your logic explicitly grants the privilege. If your LSM hook denies all privileged users the ability to remove the program, then no privileged user can remove the LSM program. The whole point here is to restrict privileged users from doing stuff. - KP > capabilities. > > > > > The decision around who can update MAC policy can be governed by the > > policy itself a.k.a. implemented with BPF LSM programs. So we can > > update hooks (as suggested here inode_unlink, sb_unmount, path_unlink) > > to only allow this action for a subset of users (e.g. CAP_MAC_ADMIN or > > even further restricted) > > > > 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? > > > > - KP > > > -- > Regards > Yafang
