On Wed, Dec 06, 2023 at 10:42:50AM +0800, Yafang Shao wrote: > On Wed, Dec 6, 2023 at 4:39 AM Frederick Lawler <fred@xxxxxxxxxxxxxx> wrote: > > > > Hi, > > > > IIUC, LSMs are supposed to give us the ability to design policy around > > unprivileged users and in addition to privileged users. As we expand > > our usage of BPF LSM's, there are cases where we want to restrict > > privileged users from unloading our progs. For instance, any privileged > > user that wants to remove restrictions we've placed on privileged users. > > > > We currently have a loader application doesn't leverage BPF skeletons. We > > instead load BPF object files, and then pin the progs to a mount point that > > is a bpf filesystem. On next run, if we have new policies, load in new > > policies, and finally unload the old. > > > > Here are some conditions a privileged user may unload programs: > > > > umount /sys/fs/bpf > > rm -rf /sys/fs/bpf/lsm > > rm /sys/fs/bpf/lsm/some_prog > > unlink /sys/fs/bpf/lsm/some_prog > > > > This works because once we remove the last reference, the programs and > > pinned maps are cleaned up. > > > > Moving individual pins or moving the mount entirely with mount --move > > do not perform any clean up operations. Lastly, bpftool doesn't currently > > have the ability to unload LSM's AFAIK. > > > > The few ideas I have floating around are: > > > > 1. Leverage some LSM hooks (BPF or otherwise) to restrict on the functions > > security_sb_umount(), security_path_unlink(), security_inode_unlink(). > > > > Both security_path_unlink() and security_inode_unlink() handle the > > unlink/remove case, but not the umount case. > > > > 3. Leverage SELinux/Apparmor to possibly handle these cases. > > > > 4. Introduce a security_bpf_prog_unload() to target hopefully the > > umount and unlink cases at the same time. > > > > All the above programs can also be removed by privileged users. > I should probably clarify the "BPF or otherwise" a bit better. Even a compiled in LSM module? If so, where can I find a bit more information about that? We are aware of some of the shortcomings of policy cfg for the AppArmor & SELinux case. > > 5. Possible moonshot idea: introduce a interface to pin _specifically_ > > BPF LSM's to the kernel, and avoid the bpf sysfs problems all > > together. > > Introducing non-auto-detachable lsm programs seems like a workable > solution. That said, we can't remove the lsm program before it has > been detached explicitly by the task which attaches it. > > > > > We're making the assumption this problem has been thought about before, > > and are wondering if there's anything obvious we're missing here. > > > > Fred > > > > > -- > Regards > Yafang Fred
