Re: [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks
From: Mickaël Salaün <mic@digikod.net>
Date: 2019-11-06 16:59:50
Also in:
bpf, linux-api, linux-security-module, lkml
On 06/11/2019 11:15, KP Singh wrote:
On 05-Nov 19:01, Mickaël Salaün wrote:quoted
On 05/11/2019 18:18, Alexei Starovoitov wrote:
[...]
quoted
quoted
I think the only way bpf-based LSM can land is both landlock and KRSI developers work together on a design that solves all use cases.As I said in a previous cover letter [1], that would be great. I think that the current Landlock bases (almost everything from this series except the seccomp interface) should meet both needs, but I would like to have the point of view of the KRSI developers.As I mentioned we are willing to collaborate but the current landlock patches does not meet the needs for KRSI: * One program type per use-case (eg. LANDLOCK_PROG_PTRACE) as opposed to a single program type. This is something that KRSI proposed in it's initial design [1] and the new common "eBPF + LSM" based approach [2] would maintain as well.
As ask in my previous email [1], I don't see how KRSI would efficiently deal with other LSM hooks with a unique program (attach) type. [1] https://lore.kernel.org/lkml/813cedde-8ed7-2d3b-883d-909efa978d41@digikod.net/ (local)
* Landlock chooses to have multiple LSM hooks per landlock hook which is more restrictive. It's not easy to write precise MAC and Audit policies for a privileged LSM based on this and this ends up bloating the context that needs to be maintained and requires avoidable boilerplate work in the kernel.
Why do you think it is more restrictive or it adds boilerplate work? How does KRSI will deal with more complex hooks than execve-like with multiple kernel objects?
[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=410101 [2] https://lore.kernel.org/bpf/20191106100655.GA18815@chromium.org/T/#u (local) - KP Singh