On Thu, Dec 7, 2023 at 3:56 PM Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > 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? Again, it depends on how you implement the logic in the LSM hook, few ideas: * Layout xattr based policy that allows one particular binary running as one particular user to remove the program * Come up with your own rules that, e.g. say allows the system to boot in a "privileged / un-enforced mode" which allows CAP_MAC_ADMIN to update the policy. * A really terrible way. All odd user IDs with MAC_ADMIN are allowed to remove the program. The point here is to further fine grain the concept of administrative "privilege" for accessing specific resources, LSM programs being a resource and BPF LSM programs is one way. What I would encourage you to look at is how other LSM programs allow dynamic updates to their LSM policy and the same mechanisms should be usable in BPF. > 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
