> From: Casey Schaufler [mailto:casey@xxxxxxxxxxxxxxxx] > Sent: Tuesday, April 5, 2022 4:50 PM > On 4/4/2022 10:20 AM, Roberto Sassu wrote: > >> From: Djalal Harouni [mailto:tixxdz@xxxxxxxxx] > >> Sent: Monday, April 4, 2022 9:45 AM > >> On Sun, Apr 3, 2022 at 5:42 PM KP Singh <kpsingh@xxxxxxxxxx> wrote: > >>> On Sat, Apr 2, 2022 at 1:55 AM Alexei Starovoitov > >>> <alexei.starovoitov@xxxxxxxxx> wrote: > >> ... > >>>>> Pinning > >>>>> them to unreachable inodes intuitively looked the > >>>>> way to go for achieving the stated goal. > >>>> We can consider inodes in bpffs that are not unlinkable by root > >>>> in the future, but certainly not for this use case. > >>> Can this not be already done by adding a BPF_LSM program to the > >>> inode_unlink LSM hook? > >>> > >> Also, beside of the inode_unlink... and out of curiosity: making > sysfs/bpffs/ > >> readonly after pinning, then using bpf LSM hooks > >> sb_mount|remount|unmount... > >> family combining bpf() LSM hook... isn't this enough to: > >> 1. Restrict who can pin to bpffs without using a full MAC > >> 2. Restrict who can delete or unmount bpf filesystem > >> > >> ? > > I'm thinking to implement something like this. > > > > First, I add a new program flag called > > BPF_F_STOP_ONCONFIRM, which causes the ref count > > of the link to increase twice at creation time. In this way, > > user space cannot make the link disappear, unless a > > confirmation is explicitly sent via the bpf() system call. > > > > Another advantage is that other LSMs can decide > > whether or not they allow a program with this flag > > (in the bpf security hook). > > > > This would work regardless of the method used to > > load the eBPF program (user space or kernel space). > > > > Second, I extend the bpf() system call with a new > > subcommand, BPF_LINK_CONFIRM_STOP, which > > decreasres the ref count for the link of the programs > > with the BPF_F_STOP_ONCONFIRM flag. I will also > > introduce a new security hook (something like > > security_link_confirm_stop), so that an LSM has the > > opportunity to deny the stop (the bpf security hook > > would not be sufficient to determine exactly for > > which link the confirmation is given, an LSM should > > be able to deny the stop for its own programs). > > Would you please stop referring to a set of eBPF programs > loaded into the BPF LSM as an LSM? Call it a BPF security > module (BSM) if you must use an abbreviation. An LSM is a > provider of security_ hooks. In your case that is BPF. When > you call the set of eBPF programs an LSM it is like calling > an SELinux policy an LSM. An eBPF program could be a provider of security_ hooks too. The bpf LSM is an aggregator, similarly to your infrastructure to manage built-in LSMs. Maybe, calling it second-level LSM or secondary LSM would better represent this new class. The only differences are the registration method, (SEC directive instead of DEFINE_LSM), and what the hook implementation can access. The implementation of a security_ hook via eBPF can follow the same structure of built-in LSMs, i.e. it can be uniquely responsible for enforcing and be policy-agnostic, and can retrieve the decisions based on a policy from a component implemented somewhere else. Hopefully, I understood the basic principles correctly. I let the eBPF maintainers comment on this. Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > > What do you think? > > > > Thanks > > > > Roberto > > > > HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > > Managing Director: Li Peng, Zhong Ronghua
