On Wed, Sep 14, 2016 at 06:25:07PM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 3:11 PM, Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > > > > On 14/09/2016 20:27, Andy Lutomirski wrote: > >> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün <mic@xxxxxxxxxxx> 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? > > What I mean is: cgroup v2 delegation has a functionality problem. > Tejun says [1]: > > We haven't had to face this decision because cgroup has never properly > supported delegating to applications and the in-use setups where this > happens are custom configurations where there is no boundary between > system and applications and adhoc trial-and-error is good enough a way > to find a working solution. That wiggle room goes away once we > officially open this up to individual applications. > > Unless and until that changes, I think that landlock should stay away > from cgroups. Others could reasonably disagree with me. Ours and Sargun's use cases for cgroup+lsm+bpf is not for security and not for sandboxing. So the above doesn't matter in such contexts. lsm hooks + cgroups provide convenient scope and existing entry points. Please see checmate examples how it's used. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
