From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-19-mic@digikod.net> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <57D9CB25.1010103@digikod.net> Date: Thu, 15 Sep 2016 00:11:49 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lKO74CA2sD0XCTUj2vFvWVHClJOn6KPVV" Subject: [kernel-hardening] Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks To: Andy Lutomirski Cc: "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: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lKO74CA2sD0XCTUj2vFvWVHClJOn6KPVV Content-Type: multipart/mixed; boundary="h0i5Tiho5jhQa6e43DaduaK6qDfkgMPKC"; protected-headers="v1" From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= To: Andy Lutomirski Cc: "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)" Message-ID: <57D9CB25.1010103@digikod.net> Subject: Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-19-mic@digikod.net> In-Reply-To: --h0i5Tiho5jhQa6e43DaduaK6qDfkgMPKC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 initial= ly >> set for all cgroup except the root. The flag is clear when a new proce= ss >> 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. >=20 > 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 unchang= ed. 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? >=20 > 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? >=20 > I have no problem with looking at prototypes for how landlock + > cgroups would work, but I can't imagine the result being mergeable. >=20 --h0i5Tiho5jhQa6e43DaduaK6qDfkgMPKC-- --lKO74CA2sD0XCTUj2vFvWVHClJOn6KPVV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJX2cslAAoJECLe/t9zvWqVj64IAI/+y5aONgOczHHPyTrbK0vE +XlLgZTxyvxhuPNGpFwANj8F/sp1YDmzUxtqkgcLUoGjjQ8FZ/47xxr5JpfJbC1v AMhUajW+adtCq/fzwQ1/MswyuhNURjEEPK0E8XCmub8aPVWHi8vnRbYswFjsWLHh BNjLVyVYI2gyTea+luJ/xstp2vXRhDNNejBs/f4BvuG/Q/sav8B5Ra6U2egejrkX rEa7qf+NbS53RDFtpiJvW3dsu9JM/NYQrcGEdasstBOyBG8CEsgFIHwKxi1PAdev rfTCZoD90eTfz7nJ8lxt1DdVTk4v5/DB2F2YO2W1QSNGOWBCHpD6lAr37uj2ELI= =nVk/ -----END PGP SIGNATURE----- --lKO74CA2sD0XCTUj2vFvWVHClJOn6KPVV--