On 26/10/2016 18:56, Mickaël Salaün wrote:
> 
> On 26/10/2016 16:52, Jann Horn wrote:
>> On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
>>> The loaded Landlock eBPF programs can be triggered by a seccomp filter
>>> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed from
>>> a seccomp filter to eBPF programs. This allow flexible security policies
>>> between seccomp and Landlock.
>>
>> Is this still up to date, or was that removed in v3?
>>
> 
> I forgot to remove this part. In this v4 series, as describe in the
> (small) patch 11/18, a Landlock rule cannot be triggered by a seccomp
> filter. So there is no more RET_LANDLOCK nor cookie.
> 

Here is an up-to-date version:

# Use case scenario

First, a process needs to create a new dedicated eBPF map containing handles.
This handles are references to system resources (e.g. file or directory). They
are grouped in one or multiple maps to be efficiently managed and checked in
batches. This kind of map can be passed to Landlock eBPF functions to compare,
for example, with a file access request.

First, a task need to create or receive a Landlock rule. This rule is a
dedicated eBPF program tied to one of the Landlock hooks, which are a subset of
LSM hooks. Once loaded, a Landlock rule can be enforced through the seccomp(2)
syscall for the current thread and its (future) children, like a seccomp
filter.

Another way to enforce a Landlock security policy is to attach Landlock rules
to a cgroup. All the processes in this cgroup will then be subject to this
policy.

A triggered Landlock eBPF program can allow or deny an access, according to
its subtype (i.e. LSM hook), thanks to errno return values.