On 25/08/2016 13:09, Andy Lutomirski wrote: > On Thu, Aug 25, 2016 at 3:32 AM, Mickaël Salaün wrote: >> Add an eBPF function bpf_landlock_cmp_cgroup_beneath(opt, map, map_op) >> to compare the current process cgroup with a cgroup handle, The handle >> can match the current cgroup if it is the same or a child. This allows >> to make conditional rules according to the current cgroup. >> >> A cgroup handle is a map entry created from a file descriptor referring >> a cgroup directory (e.g. by opening /sys/fs/cgroup/X). In this case, the >> map entry is of type BPF_MAP_HANDLE_TYPE_LANDLOCK_CGROUP_FD and the >> inferred array map is of type BPF_MAP_ARRAY_TYPE_LANDLOCK_CGROUP. > > Can you elaborate on why this is useful? I.e. why not just supply > different policies to different subtrees. The main use case I see is to load the security policies at the start of a user session for all processes but not enforce them right away. The user can then keep a shell for Landlock administration tasks and lock the other processes with a dedicated cgroup on the fly. This allows the user to make unremovable Landlock security policies but only activate them when needed for specific processes. > > Also, how does this interact with the current cgroup v1 vs v2 mess? > As far as I can tell, no one can even really agree on what "what > cgroup am I in" means right now. I tested with cgroup-v2 but indeed, it seems a bit different with cgroup-v1 :) Does anyone know how to handle both cases? > >> >> An unprivileged process can create and manipulate cgroups thanks to >> cgroup delegation. > > What is cgroup delegation? This is simply the action of changing the owner of cgroup sysfs files to allow an unprivileged user to handle them (cf. Documentation/cgroup-v2.txt) Mickaël