On 2023/12/07 11:28, Yafang Shao wrote: >>>> 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. That is what I thought at https://lkml.kernel.org/r/c588ca5d-c343-4ea2-a1f1-4efe67ebb8e3@xxxxxxxxxxxxxxxxxxx , though I didn't try it because the conclusion was that trying to re-implement TOMOYO LSM module using BPF is not realistic. While hooking security_sb_umount() from LSM modules will be possible, unconditionally rejecting umount operation might confuse userspace programs (e.g. retry until umount operation succeeds). Therefore, maybe introducing a kernel thread who holds a refcount using a file descriptor ownded by that kernel thread is better than trying to manage individual mount namepsaces and inodes... Letting a kernel code to intentionally leak that refcount instead of storing into somewhere might be possible, but that is considered as a kernel bug.
