Re: BPF LSM prevent program unload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 7, 2023 at 10:39 PM KP Singh <kpsingh@xxxxxxxxxx> wrote:
>
> > >
> > > 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.

If it's impossible for any privileged user to remove the LSM program,
this brings up another question: how can we stop this program?
However, if a privileged user does have the capability to remove it,
then the individual capable of doing so might possess these
privileges.

>
> 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



-- 
Regards
Yafang





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux