Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Nov 2019 17:58:46 +0100
From: Mickaël Salaün <>
To: KP Singh <>
Cc: Alexei Starovoitov <>,, Alexei Starovoitov <>,
        Andy Lutomirski <>,
        Casey Schaufler <>,
        Daniel Borkmann <>,
        David Drysdale
        Florent Revest <>, James Morris <>,
        Jann Horn <>,
        John Johansen <>,
        Jonathan Corbet
 <>, Kees Cook <>,
        Michael Kerrisk <>,
        Mickaël Salaün <>,
        Paul Moore <>, Sargun Dhillon <>,
        "Serge E . Hallyn" <>, Shuah Khan <>,
        Stephen Smalley <>, Tejun Heo <>,
        Tetsuo Handa <>,
        Tycho Andersen <>, Will Drewry <>,,,,,
Subject: Re: [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks

On 06/11/2019 11:15, KP Singh wrote:
> On 05-Nov 19:01, Mickaël Salaün wrote:
>> On 05/11/2019 18:18, Alexei Starovoitov wrote:


>>> 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.


> * 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]
> [2]
> - KP Singh

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.