BPF LSM prevent program unload

[Tetsuo Handa]

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@I-love.SAKURA.ne.jp ,
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.