On Thu, Aug 25, 2016 at 7:44 AM, Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > > On 25/08/2016 13:09, Andy Lutomirski wrote: >> On Thu, Aug 25, 2016 at 3:32 AM, Mickaël Salaün <mic@xxxxxxxxxxx> 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. This seems like a bit of a dubious use case to me. The landlock mechanism should be flexible enough to do this kind of thing even without cgroups, and "spawn a process, wait a while, and then confine it by fiddling with cgroups" seems a lot dicier than just loading the right policy in the first place, especially since eBPF policies can be stateful. > >> >> 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) As far as I can tell, Tejun and systemd both actively discourage doing this. Maybe I misunderstand. But in any event, the admin giving you a cgroup hierarchy you can use for this means that the admin has to cooperate with your policy, and it further requires (with cgroup v2 or similar, which is most likely the future) that your lockdown policy be compatible with your resource control policy. I would suggest dropping this lockdown feature until a use case emerges that really can't be addressed adequately without it. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
