On Mon, Nov 04, 2019 at 06:21:43PM +0100, Mickaël Salaün wrote:
> Add a first Landlock hook that can be used to enforce a security policy
> or to audit some process activities. For a sandboxing use-case, it is
> needed to inform the kernel if a task can legitimately debug another.
> ptrace(2) can also be used by an attacker to impersonate another task
> and remain undetected while performing malicious activities.
>
> Using ptrace(2) and related features on a target process can lead to a
> privilege escalation. A sandboxed task must then be able to tell the
> kernel if another task is more privileged, via ptrace_may_access().
>
> Signed-off-by: Mickaël Salaün <mic@xxxxxxxxxxx>
...
> +static int check_ptrace(struct landlock_domain *domain,
> + struct task_struct *tracer, struct task_struct *tracee)
> +{
> + struct landlock_hook_ctx_ptrace ctx_ptrace = {
> + .prog_ctx = {
> + .tracer = (uintptr_t)tracer,
> + .tracee = (uintptr_t)tracee,
> + },
> + };
So you're passing two kernel pointers obfuscated as u64 into bpf program
yet claiming that the end goal is to make landlock unprivileged?!
The most basic security hole in the tool that is aiming to provide security.
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. BPF is capable
to be a superset of all existing LSMs whereas landlock and KRSI propsals today
are custom solutions to specific security concerns. BPF subsystem was extended
with custom things in the past. In networking we have lwt, skb, tc, xdp, sk
program types with a lot of overlapping functionality. We couldn't figure out
how to generalize them into single 'networking' program. Now we can and we
should. Accepting two partially overlapping bpf-based LSMs would be repeating
the same mistake again.
