Re: BPF LSM prevent program unload

[Frederick Lawler <fred@cloudflare.com>]

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@cloudflare.com> 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