On 14/09/2016 20:27, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: >> Add a new flag CGRP_NO_NEW_PRIVS for each cgroup. This flag is initially >> set for all cgroup except the root. The flag is clear when a new process >> without the no_new_privs flags is attached to the cgroup. >> >> If a cgroup is landlocked, then any new attempt, from an unprivileged >> process, to attach a process without no_new_privs to this cgroup will >> be denied. > > Until and unless everyone can agree on a way to properly namespace, > delegate, etc cgroups, I think that trying to add unprivileged > semantics to cgroups is nuts. Given the big thread about cgroup v2, > no-internal-tasks, etc, I just don't see how this approach can be > viable. As far as I can tell, the no_new_privs flag of at task is not related to namespaces. The CGRP_NO_NEW_PRIVS flag is only a cache to quickly access the no_new_privs property of *tasks* in a cgroup. The semantic is unchanged. Using cgroup is optional, any task could use the seccomp-based landlocking instead. However, for those that want/need to manage a security policy in a more dynamic way, using cgroups may make sense. I though cgroup delegation was OK in the v2, isn't it the case? Do you have some links? > > Can we try to make landlock work completely independently of cgroups > so that it doesn't get stuck and so that programs can use it without > worrying about cgroup v1 vs v2, interactions with cgroup managers, > cgroup managers that (supposedly?) will start migrating processes > around piecemeal and almost certainly blowing up landlock in the > process, etc? This RFC handle both cgroup and seccomp approaches in a similar way. I don't see why building on top of cgroup v2 is a problem. Is there security issues with delegation? > > I have no problem with looking at prototypes for how landlock + > cgroups would work, but I can't imagine the result being mergeable. >