On 4/5/2022 8:29 AM, Roberto Sassu wrote:
From: Casey Schaufler [mailto:casey@schaufler-ca.com] Sent: Tuesday, April 5, 2022 4:50 PM On 4/4/2022 10:20 AM, Roberto Sassu wrote:
From: Djalal Harouni [mailto:tixxdz@gmail.com] Sent: Monday, April 4, 2022 9:45 AM On Sun, Apr 3, 2022 at 5:42 PM KP Singh kpsingh@kernel.org wrote:
On Sat, Apr 2, 2022 at 1:55 AM Alexei Starovoitov alexei.starovoitov@gmail.com 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:
- Restrict who can pin to bpffs without using a full MAC
- 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.
No, it can't. If I look in /sys/kernel/security/lsm what you see is "bpf". The LSM is BPF. What BPF does in its hooks is up to it and its responsibility.
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.
It isn't an LSM, and adding a qualifier doesn't make it one and only adds to the confusion.
The only differences are the registration method, (SEC directive instead of DEFINE_LSM), and what the hook implementation can access.
Those two things pretty well define what an LSM is.
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.
The BPF LSM provides mechanism. The eBPF programs provide policy.
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