BPF LSM Meta Tracker

[daemon1024]

We introduced BPF LSM enforcement in v0.5, which has an initial implementation and has bugs and lacks some features. This issue thread is a tracker for all these pending work items and bug reports.

• BPF LSM Enhance File/Path based Security #1115
• does bprm check sec block memfd executions?
• KubeArmor policy with readOnly flag not working with BPFLSM #959
  • feat(enforcer): enforce read only policies in bpflsm #971
• Network - add LSM Socket Accept Enforcement
• Lenient Whitelisting Support
• Unorchestrated Workloads Enforcement Support BPF-LSM enforcement in containerized workloads #838
• BPF LSM Host Policy Enforcement #1158
• BPF LSM Performance #1152
• Hashing to optimise map resources
• Pattern Matching Support
  • Initial support for prefix and postfix
  • dynamically generate hooks based on DFA

[daemon1024]

To secure file operations with BPF LSM we need to expand on the hooks we use.
Like we don't restrict touch (file create) or rm (unlink).
AppArmor relies on SECURITY_PATH hooks to enforce file rules.
SECURITY_PATH hooks helps us enforce path based access control. They need the same flag enabled in the Kernel. It would be quickl to implement them since we already have the path struct. Issue is RHEL for some reason doesn't enable it by default ( why do they choose to be different always ;). AppArmor being a kernel module can add a dependency on this flag but we can't.
The alternate is to use inode based hooks. Based on this answer, Tomoyo maintainers added path hooks because they couldn't construct absolute paths from inode hooks. because inodes don't provide vfsmount but need both vfsmount and dentry to construct full path.

I found this https://stackoverflow.com/a/33078711 but will have to experiment and check. Or should we just enforce rules using PATH hooks and mark it a requirement? for full enforcement.

[nyrahul]

To secure file operations with BPF LSM we need to expand on the hooks we use. Like we don't restrict touch (file create) or rm (unlink). AppArmor relies on SECURITY_PATH hooks to enforce file rules. SECURITY_PATH hooks helps us enforce path based access control. They need the same flag enabled in the Kernel. It would be quickl to implement them since we already have the path struct. Issue is RHEL for some reason doesn't enable it by default ( why do they choose to be different always ;). AppArmor being a kernel module can add a dependency on this flag but we can't. The alternate is to use inode based hooks. Based on this answer, Tomoyo maintainers added path hooks because they couldn't construct absolute paths from inode hooks. because inodes don't provide vfsmount but need both vfsmount and dentry to construct full path.

I found this https://stackoverflow.com/a/33078711 but will have to experiment and check. Or should we just enforce rules using PATH hooks and mark it a requirement? for full enforcement.

So as I understand:
If we use PATH hooks, we cannot support RHEL. But the other option of using inode based hooks is still not fully clear.
I feel we can take a decision only once it is clear whether inode based hooks approach works.

Btw, taking a step back, is it possible to block unlink/file create access using seccomp-bpf? If it is possible then we can think of an alt strategy.

[daemon1024]

If we use PATH hooks, we cannot support RHEL. But the other option of using inode based hooks is still not fully clear.

Right

I feel we can take a decision only once it is clear whether inode based hooks approach works.

Makes sense. I will look into it and try to execute things.

Btw, taking a step back, is it possible to block unlink/file create access using seccomp-bpf? If it is possible then we can think of an alt strategy.

I was under the assumption that we can only have seccomp filters per container but not entity specific inside the container? Like we have the capability list, we have a syscall list as seccomp profile. That would mean we will enforce create/unlink per container not based on directories inside container. Is it not the case 🤔

[daemon1024]

Inode hooks should work fine,
Need some work but this commit showcases how it can be possibly achieved daemon1024/bpf-scratchpad@bbf5cd1. Basically taking mount point from task struct and combining it with the dentry from LSM hook args.

Parking the implementation and further research for later.