From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: <20160915021940.GA65119@ast-mbp.thefacebook.com> References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-19-mic@digikod.net> <57D9CB25.1010103@digikod.net> <20160915021940.GA65119@ast-mbp.thefacebook.com> From: Andy Lutomirski Date: Wed, 14 Sep 2016 19:27:08 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [kernel-hardening] Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks To: Alexei Starovoitov Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , "linux-kernel@vger.kernel.org" , Alexei Starovoitov , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , "kernel-hardening@lists.openwall.com" , Linux API , LSM List , Network Development , "open list:CONTROL GROUP (CGROUP)" List-ID: On Wed, Sep 14, 2016 at 7:19 PM, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 06:25:07PM -0700, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 3:11 PM, Micka=C3=ABl Sala=C3=BCn wrote: >> > >> > On 14/09/2016 20:27, Andy Lutomirski wrote: >> >> On Wed, Sep 14, 2016 at 12:24 AM, Micka=C3=ABl Sala=C3=BCn wrote: >> >>> Add a new flag CGRP_NO_NEW_PRIVS for each cgroup. This flag is initi= ally >> >>> set for all cgroup except the root. The flag is clear when a new pro= cess >> >>> without the no_new_privs flags is attached to the cgroup. >> >>> >> >>> If a cgroup is landlocked, then any new attempt, from an unprivilege= d >> >>> process, to attach a process without no_new_privs to this cgroup wil= l >> >>> 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 acce= ss >> > the no_new_privs property of *tasks* in a cgroup. The semantic is unch= anged. >> > >> > 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 be clear: I'm not arguing at all that there shouldn't be bpf+lsm+cgroup integration. I'm arguing that the unprivileged landlock interface shouldn't expose any cgroup integration, at least until the cgroup situation settles down a lot. --Andy